Changes between Version 1 and Version 2 of WeeklyMinutes20100713


Ignore:
Timestamp:
Jul 13, 2010, 4:16:11 PM (7 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WeeklyMinutes20100713

    v1 v2  
    1 = MINUTES NOT DONE - WILL BE INCOHERENT =
    2 
    31== Attendees ==
    42
    53{{{
    6 }}}
    7 
     4Hankins
     5Shawn
     6Jelte
     7Shane
    88Likun
    99Jerry
    10 Shane
    11 Fujiwara-san
    12 Jelte
     10Fujiwara
     11Jeremy
    1312Stephen
    14 Jeremy
     13Jinmei
    1514Larissa
    16 Shawn
    17 Hankins
    18 Jinmei
    1915Evan
    2016Michael
     17}}}
    2118
    2219== Action point issues (if any) ==
    2320
     21Jeremy reports his done.
     22
    2423== Architectural issues ==
    2524
    2625'''Receptionist model'''
    2726
     27Stephen describes his work.
     28
     29Stephen suggests with asynchronous work the differences will not be so high.
     30
     31Jinmei: How do these processes pass the packet?
     32
     33Stephen: Straight UDP call to `send()`/`recv()` packets. There is a Boost message queue to pass between processes.
     34
     35Jinmei: Did you mean BIND 10 msgq?
     36
     37Stephen: I used the Boost message queue.
     38
     39Jinmei: Right now I have not looked into it, but I plan to take a closer look at it.
     40
     41Stephen: What is the motivation for breaking the name server down into multiple processes?
     42
     43[ Shane describes the motivations - scaling and fault isolation ]
     44
     45Jinmei: One of the main motivations is to run authoritative and recursive on the same machine, but not to have a single process. 
     46
     47Stephen: I think a receptionist would work in a recursive server. One part has cache, and if it is not there it passes it off.
     48
     49Shane: We can start with that and refactor later if needed for performance.
     50
     51Stephen: If nothing else, it breaks the system down into simpler parts.
     52
     53Stephen: Trying to run async on my home network, but need modifications to handle packet loss.
     54
    2855== 2010-08-12 release ==
    2956
    3057'''Writable data source + IXFR'''
    3158
     59Jelte: IXFR stuff is part of the writable data source. There has been a little discussion between Likun and me about whether this should be in the data source or the IXFR module. I think it should be in the data source because it might shortcuts specific to that data source. So I did stuff to add/remove RRSET, then moved on to IXFR, and now moving on to dynamic updates. The original did IXFR out support. I have ideas about that but we might want to move to a separate task because this is already very big. Still a lot of work on it, there is progress, certainly not done yet.
     60
    3261----
    3362
    3463'''Secondary manager'''
    3564
     65Shane: Goal to have in next release?
     66
     67Likun: Plan is to include in next release.
     68
     69Shane: Want to make sure we have enough time for review.
     70
     71Jinmei: I read document. It looked basically pretty nice. I have some minor comments but I didn't have time to write up in an e-mail style; I'll do that. Basically it looks fine.
     72
     73Likun: Jerry working on implementation of this. If there any big changes in design, the plan is to finish the code in 2 weeks. I think we can have at least 1 or 2 weeks for review.
     74
     75Jinmei: On a related note. I don't think we can enable incoming notify processing until we have the secondary zone manager stuff, because we cannot validate the source of the NOTIFY until then.
     76
     77Likun: I think the checking should be left to the secondary manager. If auth server receives all the NOTIFY from anyone and don't do checking I think we'll mix too many messages between auth server and secondary manager. I think auth server should do some checking first.
     78
     79Jinmei: I think the authoritative server needs to do some minimal checks, but I am not sure what kind of checks the authoritative server needs to do. My current impression is that it can validate the zone name to see if the server has authority for the zones. But I am not really sure if the authoritative server can realistically do checks on the addresses of the messages. But I am not sure. It is not a strong impression.
     80
     81Likun: At least we should at least check for the IP in "allow-notify:" or the server is master for the zones.
     82
     83Jinmei: My point at this point is that even though we have some workaround for the xfrin implementation so we can accept incoming notify, I now think we should wait for the secondary zone manager.
     84
     85Likun: Maybe we can discuss on the e-mails.
     86
     87All: Okay.
     88
    3689----
    3790
    3891'''Recursion: algorithm'''
    3992
     93Evan: I don't expect it to take me all that long. Except for release engineering I don't have too much more to do for BIND 9.
     94
     95Shane: I think it may be blocking if we wait too much longer on this...
     96
    4097----
    4198
    4299'''Recursion: architecture & design'''
    43100
     101Shane: ''Almost'' ready for implementation.
     102
     103Jinmei: Architecture & design sounds vague.
     104
     105Evan: I think BIND 10 face-to-face is ambitious... I'd enjoy working on it, but...
     106
     107Shane: Maybe we should make that the output of the next face to face meeting?
     108
     109Evan: We could take the first day or two hammering out technical details, then spend the rest of the time implementing.
     110
     111Shane: Can you do the cache before this?
     112
     113Michael: I think the cache is the most important part of the whole process, learning from what BIND 9 has had problems with...
     114
     115Jelte: I think I agree.
     116
     117Evan: There are some initial design decisions that can be made. We discussed the idea of an external, shared cache vs. having each recursor having it's own cache.
     118
     119Michael: I suggest just making something and getting it to work, since we'll throw it away anyway.
     120
     121Evan: Maybe this is something we want to look at anyway? At least have some general idea of where we think we want to go and then design the API for that, rather than just flail something together.
     122
     123Michael: You really can't design it for all the ifs/ands/possibles. If you plan too far ahead you'll end up doing busywork and throwing it away anyway.
     124
     125----
     126
     127'''Recursion: dispatch (BIND 9 style)?'''
     128
     129Shane: Straightforward & unambiguous.
     130
     131Michael: Anyone looking at Windows?
     132
     133Shane: Stephen has been volunteered.
     134
     135Jinmei: I think we are relying on many Unix-specific features like file descriptor passing. It should be better to do similar things in Windows.
     136
     137Evan: We are relying on that at an abstracted level.
     138
    44139----
    45140
    46141'''Recursion: benchmarking?'''
    47142
     143Shane: We need to have this.
     144
     145Michael: Are you talking about calling functions or network?
     146
     147Shane: I was thinking like DNS Cucumber, but with performance not functionality testing.
     148
     149Hankins: We have the 3 Jinmei's... so you could put client load on one machine, recursive server on another, and then authoritative on another.
     150
     151Michael: These are 8 years old now...
     152
     153Jeremy: We have another new server that we got last fall.
     154
     155Hankins: As long as we're interested in relative performance instead of numbers, it doesn't matter what you use.
     156
    48157----
    49158
    50159'''Recursion: cache?'''
    51160
    52 ----
    53 
    54 '''Recursion: dispatch (BIND 9 style)?'''
     161[ see above ]
    55162
    56163== Mascot contest status ==
    57164
     165Contest closed. Selection committee picking finalists, then open vote.
     166
    58167== Command-line tool ==
     168
     169Shane: Jerry Scharf doing this work. Will introduce to bind10-dev soon.
     170
     171Jelte: I don't disagree having someone else doing this. Want to make sure it doesn't veer too far from what we do. We are designing a very different system from what all the others are doing.
    59172
    60173== IETF head's up ==
     
    62175=== BIND 10 at BIND Forum ===
    63176
     177Shane: BIND 10 will be presented at the BIND Forum.
     178
     179Larissa: Sunday night at 20:00. ISC staff should attend.
     180
     181Hankins: Will the DHCP folks be invited?
     182
     183Larissa: We should talk about this.
     184
    64185=== Various ISC staff there ===
    65186
     187Shane: Not sure if we will have a call during the IETF meeting. Probably!
     188
    66189== Regular Benchmarks (authoritative) ==
     190
     191[ Shane will send mail ]
     192
     193== Architectural Discussion ==
     194
     195Evan: Jinmei's work repairing base32 and base16 encodings. I wrote from scratch using BIND 9 as a base. For base64 we used the Boost implementation. Jinmei extended this to base32 and base16. I looked and I don't know enough C++ to review. We had a high-level theoretical discussion about what to do in those circumstances.
     196
     197Shane: What conclusion did you come to?
     198
     199Evan: Left it hanging! Should we go into areas of C++ that we have 0 or 1 experts in? In that specific case there are probably other approaches. I think it is good to have all 3 encodings handled by the same code base. I can satisfy myself that what he is doing is probably alright, but I don't know. For example the Boost reviewers could tell him if it as good code. Is there anybody else who knows C++ templates well enough to be the reviewer.
     200
     201Jinmei: There was no conclusion.
     202
     203Stephen: I played around with C++ templates a bit.
     204
     205Evan: Perhaps Stephen should take that on for now. I would like to know it better.
     206
     207Jinmei: There are several points to discuss at various levels.
     208
     209  1. How to move forward with this particular ticket? #256 If someone can review it that would be great.
     210  1. The other thing is high-level development process work. In this ticket we use some C++ syntax and features. Maybe someone who knows templates pretty well can review it and make comments on whether this style is reasonable or too tricky to share. Then we can discuss the acceptable level of language features. A form of coding guidelines.
     211
     212Jinmei: If Stephen can do that, that would be great.
     213
     214Shane: So look at the complexity too?
     215
     216Jinmei: Not necessarily complexity, but language features.
     217
     218----
     219
     220Jinmei: Another small ticket, #241. C++ micro-benchmark framework. I'd like to get it reviewed. I would like to know whether this is useful or not in the first place. I'd like someone to look at the documentation and general understanding of how to use it, and then make feedback on that. If someone can look at the documentation and provide feedback whether this is useful that would be great.