Changes between Version 1 and Version 2 of WeeklyMinutes20100713

Jul 13, 2010, 4:16:11 PM (8 years ago)



  • WeeklyMinutes20100713

    v1 v2  
    31== Attendees ==
    6 }}}
    10 Shane
    11 Fujiwara-san
    12 Jelte
    14 Jeremy
    16 Shawn
    17 Hankins
    18 Jinmei
    2219== Action point issues (if any) ==
     21Jeremy reports his done.
    2423== Architectural issues ==
    2625'''Receptionist model'''
     27Stephen describes his work.
     29Stephen suggests with asynchronous work the differences will not be so high.
     31Jinmei: How do these processes pass the packet?
     33Stephen: Straight UDP call to `send()`/`recv()` packets. There is a Boost message queue to pass between processes.
     35Jinmei: Did you mean BIND 10 msgq?
     37Stephen: I used the Boost message queue.
     39Jinmei: Right now I have not looked into it, but I plan to take a closer look at it.
     41Stephen: What is the motivation for breaking the name server down into multiple processes?
     43[ Shane describes the motivations - scaling and fault isolation ]
     45Jinmei: One of the main motivations is to run authoritative and recursive on the same machine, but not to have a single process. 
     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.
     49Shane: We can start with that and refactor later if needed for performance.
     51Stephen: If nothing else, it breaks the system down into simpler parts.
     53Stephen: Trying to run async on my home network, but need modifications to handle packet loss.
    2855== 2010-08-12 release ==
    3057'''Writable data source + IXFR'''
     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.
    3463'''Secondary manager'''
     65Shane: Goal to have in next release?
     67Likun: Plan is to include in next release.
     69Shane: Want to make sure we have enough time for review.
     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.
     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.
     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.
     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.
     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.
     81Likun: At least we should at least check for the IP in "allow-notify:" or the server is master for the zones.
     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.
     85Likun: Maybe we can discuss on the e-mails.
     87All: Okay.
    3891'''Recursion: algorithm'''
     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.
     95Shane: I think it may be blocking if we wait too much longer on this...
    4299'''Recursion: architecture & design'''
     101Shane: ''Almost'' ready for implementation.
     103Jinmei: Architecture & design sounds vague.
     105Evan: I think BIND 10 face-to-face is ambitious... I'd enjoy working on it, but...
     107Shane: Maybe we should make that the output of the next face to face meeting?
     109Evan: We could take the first day or two hammering out technical details, then spend the rest of the time implementing.
     111Shane: Can you do the cache before this?
     113Michael: I think the cache is the most important part of the whole process, learning from what BIND 9 has had problems with...
     115Jelte: I think I agree.
     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.
     119Michael: I suggest just making something and getting it to work, since we'll throw it away anyway.
     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.
     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.
     127'''Recursion: dispatch (BIND 9 style)?'''
     129Shane: Straightforward & unambiguous.
     131Michael: Anyone looking at Windows?
     133Shane: Stephen has been volunteered.
     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.
     137Evan: We are relying on that at an abstracted level.
    46141'''Recursion: benchmarking?'''
     143Shane: We need to have this.
     145Michael: Are you talking about calling functions or network?
     147Shane: I was thinking like DNS Cucumber, but with performance not functionality testing.
     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.
     151Michael: These are 8 years old now...
     153Jeremy: We have another new server that we got last fall.
     155Hankins: As long as we're interested in relative performance instead of numbers, it doesn't matter what you use.
    50159'''Recursion: cache?'''
    52 ----
    54 '''Recursion: dispatch (BIND 9 style)?'''
     161[ see above ]
    56163== Mascot contest status ==
     165Contest closed. Selection committee picking finalists, then open vote.
    58167== Command-line tool ==
     169Shane: Jerry Scharf doing this work. Will introduce to bind10-dev soon.
     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.
    60173== IETF head's up ==
    62175=== BIND 10 at BIND Forum ===
     177Shane: BIND 10 will be presented at the BIND Forum.
     179Larissa: Sunday night at 20:00. ISC staff should attend.
     181Hankins: Will the DHCP folks be invited?
     183Larissa: We should talk about this.
    64185=== Various ISC staff there ===
     187Shane: Not sure if we will have a call during the IETF meeting. Probably!
    66189== Regular Benchmarks (authoritative) ==
     191[ Shane will send mail ]
     193== Architectural Discussion ==
     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.
     197Shane: What conclusion did you come to?
     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.
     201Jinmei: There was no conclusion.
     203Stephen: I played around with C++ templates a bit.
     205Evan: Perhaps Stephen should take that on for now. I would like to know it better.
     207Jinmei: There are several points to discuss at various levels.
     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.
     212Jinmei: If Stephen can do that, that would be great.
     214Shane: So look at the complexity too?
     216Jinmei: Not necessarily complexity, but language features.
     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.