Ting Ting 
  • Quick notes
    • ISC having internal conversation about revision control systems; Michael & Evan's research into git & Mercurial used as input

Michael: ISC is doing some review of requirements to make sure that we don't miss something important. Overall tone was that either git or Mercurial would be better than what we have now.

Shane: I'd like to do this conversion after the next release, but not too much later.

Jinmei: I'm not sure about the schedule for BIND 10. We are discussing a unified revision for ISC. Are we expecting this to happen after the entire company decides a unified version for the tool?

Shane: If requirements & analysis takes more than a month, then we are not actually doing requirements but we are scared.

Jinmei: One-month deadline sounds like a nice idea. I don't have a strong preference for changing the tool myself, so I don't mind. I'm okay with that. But if we switch, sooner is better because we don't have much history and the conversion overhead should be relatively lower. What I'm afraid about is the generic research about requirements takes longer than we expect and we miss the oportunitity of a relatively low-overhead conversion.

Michael: If we wait a month or two months it won't make much of a difference. If we wait one more sprint it won't hurt. If we don't get it by then, it is another matter entirely.

Jeremy: Will ops be running the new repo once the decision is made?

Michael: They won't be running it. They will be backing up the data and installing the components on some machines at ISC.

  • Action point discussion
  1. Make a page on the Wiki which captures these
  2. Put this as an item in everyone's weekly update e-mail

[ general agreement ]

*AP* Shane to make a page on the Wiki for AP

Jinmei: The idea of a wiki page is good. Based on that I think we should briefly check the overall progress and if we have any delay we need to assign someone eles to a particular task. I'd like to have that kind of session in the action point part of the call.

Shane: Instead of an action point review, we will have a check of overall progress, starting next week.

  • Jinmei: I'd like to get feedback on the proposed changelog format (if any).

Jinmei: Not many developers responded to e-mails about Changelog.

Evan: I think silence equals assent. I didn't see a point to answering because I thought it was fine.

Jelte: <aol>Me too</aol>

  • Jinmei: I guess we need to assign reviewers to some open review requests.

Jinmei: I sent a review request yesterday or the day before so maybe it would make sense to assign someone to the review this call.

Shane: Jeremy and I have scheduled ticket review, which will be Monday this week.

  • Architectural discussions
  • Likun discussed xfrin architecture with Feng & Shane, will send mail

Likun: one process receives NOTIFY, another process replies, xfrin will get file descriptor. xfrin will also do zone maintenance. When xfrin finishes transfer, it will need to send out NOTIFY. At end of discussion we got a new name for xfrin: ZoneRefresher?. We plan to change the name.

Likun: Zone configuration is another part. Each zone has many configurations... in dicussion we plan on storing all the configuration settings in the data source.

Michael: Configuration in the data source?

Likun: Maybe we have more than 1 million zones, maybe it is not perfect to store it in the configuration manager.

Michael: If the 3rd thing written bypasses the configuration manager, maybe we have missed the mark. Maybe it should be a library call and not a c-channel message. I'm concerned about splitting up the data source.

Jelte: What I am thinking of is some sort of system call which checks if the system is running and if it is asks, otherwise digs in directly.

Michael: Or you could give a token.

Likun: What is the plan for the config manager... currently all config data is in a file. What is the plan in the future if the configuration detail is too big?

Michael: Why are you worried about large numbers of zones right now?

[ some discussion about the wisdom of putting stuff into data source ]

Jinmei: I think thinking about scalability makes sense, even at an early stage. Whether or not we do that depends on how complicated it is, and how many things we need to consider about interactions.

Michael: We shouldn't have this as the *only* way to store this information.

Jelte: There are no plans on changing the way configuration is stored right now, but it shouldn't be hard to do that.

Michael: I suspect we'll need to make is SQLite eventually...

Jelte: We could even make it configurable.

Likun: Another small question I want to ask Jinmei. Currently in the auth srv process we receive a NOTIFY message. Should the auth srv process reply to these messages?

Jinmei: I'm not sure. I quickly looked at how BIND 9 does it. It would depend on how many things a process should do before answering a notify request. If it needs to do many things about a zone content, it might make sense to invoke another process. But if it's a relatively lightweight process then it may be better for the authoritative server process to handle that.

Likun: My only concern is if we receive the message in TCP it's a little hard for xfrin to handle this.

Shane: We could do a trick like we do in xfrout, but...

Likun: I don't want to make it too complicated.

Michael: I think answering it directly there is the best way.

Michael: Should we wait until we get an acknowledgement internally?

Shane: No...

Jinmei: I don't think so either.

Michael: I don't think the name describes the process well. I think something like "secondary zone maintenace" or something like that.

Jinmei: A possibly related question. In the proposal the xfrin process (which may be renamed). I wondered whether it makes sense to separate zone management and process for handling xfr.

Likun: Yeah we discussed it today. If we make zone manager as a single process, it just does xfrin so we merged it in.

Michael: I would argue not to merge that.

Jinmei: Assuming we handle notify in the auth serv process, the zone manager doesn't have to handle handle message format. So it will be simpler and safer. Also we can kill any xfr in process if a particular transaction goes wrong while keeping zone manager processing. I didn't think about other details, but separating these two tasks seems to make more sense.

Jinmei: There are two possibilities: one for zone management and one for xfr, where the xfr has multiple threads. Or we have one zone management and one per transfer, so many xfr processes. I didn't have a particular idea about these two choices. What I mainly focused on is having a single process to do everything.

  • Writable data sources (please read Jelte's mails if you have not yet)

Shane: I noticed that there is a lot of weird stuff for RRset operations.

Jelte: This comes from the RFCs.

Michael: Ruby works with RRset but you can work with RR if you want to.

Jelte: No RDATA in an RRest is used a lot. Is this allowed?

Jinmei: This is implicitly supported right?

Michael: If the RTYPE is A doesn't it require that RDATA length be 4?

Jinmei: I guess there may be a confusion. I thought Jelte means the number of RDATA in an RRSET, rather than RDLENGTH is 0. That is not possible now.

Jelte: We'll get a FORMERR if we try to parse one of these packets.

Likun: I want to delete an RRset, just using the RNAME but no RTYPE.

Michael: I suggest the API probably wants to have a "delete entry". ... I'm not sure about the API three.

Jelte: It's also used for prerequisites.

Shane: We'll need zone enumeration at some point.

Shane: API proposes both locking and transactions. Do we want both? Do we need both?

Michael: Locking was "I can't think of all possible transactions, so I'll add locking"

Jelte: Sort of.

Michael: I suggest we remove it then.

Jinmei: Maybe related to this point, I am not sure how we insure that we use the same version of a zone in the previous checked state. We need a conceptual notion of a giant lock. From a quick look at this proposal it seems to only consider transaction or locking for adding/deleting.

Jelte: No serialization.

Michael: Part of what I have to ask is "do we care?"

Jelte: Some of this is out of scope for the data source API. It can be run from different processes, and there would have to be some other global thingy there.

Michael: BIND 9 data source model is extremely complicated and it guarantees a lot of things. We thought DNS needed those guarantees. I'm not 100% convinced that everything we need are hard guarantees. Maybe we should try to figure out why it does these things?

Hankins: You mean things like RRSET order?

Michael: No, these are pretty easy. What I'm thinking of is: the process to query BIND 9 is... 1) open database to get a token, 2) data will be consistent when you open that database. In the current data source model, there may have been an update that occurred between those two. We don't have a BEGIN TRANSACTION syntax for reading. I'm not 100% certain that we care about that. The short answer is Paul Vixie will say you MUST do it that way because that is what is expected.

Evan: Matters more in the case of xfrout.

Michael: Not every backend has transactions...

Shane: So we need locking?

Michael: We need to lock to a particular view of the data.

Evan: We talked about data sources have capablities.

[ some conversation ]

Michael: I don't think we need versioning except for XFR.

Evan: What about DDNS?

Michael: I consider this 99% the same as XFR.

Evan: Agreed.

Jelte: Jinmei suggested we may want to refactor the whole data source stuff.

Evan: I'm fine with that, but too close to the original design to have much to say about it.

Michael: Someone else has to start the discussion, since I haven't thought about it.

Evan: I think Jinmei's suggestion to break it into smaller classes makes sense, but I can't see where to break it.

Jinmei: I'm not indicating this is the only correct model.

Evan: I'm not comfortable enough yet with C++ to see the obvious places where this would break.

Jinmei: I think this is a relatively middle-term refactor, and does not affect the currently on-going writable data source model.

Michael: There are probably tests that we don't have in the code, which may cause us to refactor sooner.

Last modified 8 years ago Last modified on May 20, 2010, 3:02:49 PM