BIND10 Sprint Planning 2011-10-11

2011-10-11 @ 15:00 UTC




Stephen to create a page on the Wiki for standards conformance.

Past Sprint Review

Goals at were:

  • IXFR-in completed
  • Boss process flexibility added
  • Ability to save/load configuration to/from a file, including ability to

check configuration files like named-checkconf

Stephen: Missing stuff from RFC 1995.

Stephen: Any problems with interdependencies in tickets?

Jinmei: In a technical sense we could have done it a little better, but I don't know how we could have done that with planning.

Jelte: For the work that needed additional work we created a set of additional tickets (#1251 to #1253 for instance)

Stephen: We're still overloading the sprints with tickets. Far more than we are likely to do. Partially because we are a distributed team. But OTOH maybe it does mean we have difficulty in estimating in deciding if we can complete something in a given sprint. We had the aims (above), but we have loads of tickets in that were not related to that.

Jelte: Another approach would be to estimate on the lower end, and only do things we know we can finish, and then pick new work out of the backlog for instance.

Stephen: That might be a good idea. I would not say "do it now", but planning for next time.... we have features we wanted in the previous sprint and features that we want in the next sprint. We should decide what the priorities are rather than put everything in and hope that we can do it.

Jelte: I want to make better use of next-sprint-proposed and make estimates before the meeting.

Stephen: I think that's right. Maybe we should be using next-sprint-proposed as a list of things that we are 90% sure will be in the next sprint.

Jelte: Or at least have everything estimated in there, so we can beter chose tasks in there. I'll try to come up with a new model

Did we reach our goals? Any issues the could have been handled better? Were the estimates accurate?

Jinmei: Considering we did not know all of the tasks, #1212 was not too bad.

We added a lot of tickets during the sprint this time. A number of them were expected (as subtickets of 1212), but there were also others. Was this a problem? Was this good?

What did we miss, forgot, or simply skip to reach the sprint goals.

Stephen: The question was about IXFR, although reading the comments we are not doing IXFR over UDP - which is in the specification. Also, if you receive a notify, it won't do an IXFR, it will do an AXFR?

Jinmei: It's configuration.

Stephen: So you can configure it. Also, you execute IXFR by triggering a retransfer command, but I would have thought a retransfer would do an AXFR (for example if you have a corrupt zone).

Stephen: The main thing is IXFR over UDP.

Jinmei: I think even BIND 9 does not do it.

Stephen: Are we trying to do a reference implementation or what?

Jinmei: My understanding is that we are trying to make a reference implementation. But in some cases we make a decision about which part of the specification we really want to implement.

Jelte: Regarding the retansfer, I think we need a set of commands. One would do "act like I got a notify" and another one is even more. (What? - do a complete zone transfer)

Jinmei: The big missing point is we do not fall back from IXFR to AXFR.

Shane: I agree.

Jelte: That's one of the important ones right now.

Stephen: Perhaps we can start a document which says "these are the specifications we support and these are the bits of the specifications we support". If we have an implementation that meets what we committed to for year 3, then there are other things that we need to get on with.

Jelte: Yesterday Jinmei updated the tool so that IXFR will work if the zone does not exist. (But using old API.)

Jinmei: maybe we should solve this when we think about configuration things from the data source.

Jelte: it is related.

Stephen: Should we open a page on the Wiki that says "standards conformance" that says what we support and not?

Jelte: If we do then we need to keep it up to date, which is usually the problem with such things.

Jeremy: I think we do, and keeping it up to date is just testing each bullet point.

Jelte: Stephen worked on IXFR tests, right?

Stephen: I was thinking slightly more general.

A lot of requirements are for one feature. The standards page is likely to be a much more general, overview of what bits of the standard we support. Jeremy is right and we need tests, and then we need to go through the standard in some detail to find out what we are testing.

Jelte: Such a test page can be derived from the test plan.

Stephen: Shall I create such a page from RFC 1995?

Jelte: Yes please.

Jeremy: Different from the existing system test page?

Stephen: Yes, a lot of tests can be collapsed down, for example "IXFR over UDP". Feature demo will be done, but not sure when. (Shane would like it before the release, so on Thursday.) Jelte will do this, and Shane will work with him.

Next Sprint

Initially, we probably need to do release cleanups and finishing touches for the better part of this week. But that should not keep us from having some goals for the rest of the sprint. For the next release we want to try and get ddns and xfrout working. So we should be doing some design work with high priority in this sprint. Proposed new goals:

  • Design for data source differences
  • (design for) handling of DDNS commands
  • Depending on whether the current state is advanced enough, we may want to finish boss configuration.

Stephen: Isn't the differences more or less settled? The latest version of the zone plus a linear list of differences.

Jelte: Yes, but we need documented design.

Michal: And we probably need an API.

Jinmei: I have some ongoing progress about this area. It does not seem tricky although we may want to discuss some details. So my feeling is that we can complete the design task in this sprint and based on that we can at least complete IXFR-out before the next release. I'm not so sure about the Dynamic DNS part though.

Jelte: Regarding DDNS, the bigger problem would be where to handle the incoming DDNS pakcet. When I did an earlier version of DDNS, I found that DDNS is mostly a subset of IXFR.

Jinmei: For DDNS we also need to provide some access control probably. In the case of DDNS we cannot assume that the difference makes sense. For example BIND 9 performs a lot more checks before trying the diff - not only about the prerequisites. For example, looking at the existing zone. It kind of normalizes the existing zone before applying it. Thinking about these corner cases I think it will be a much larger task than IXFR.

Michal: Should we check ...?

Stephen: There is the case of what happens when a server receives an IXFR which asks the server to delete a record not in its zone.

Jinmei: We don't currently do anything. We can discuss this, but 1) in practice its more trustworthy, and 2) even if it is kind of broken, the secondary kind of has to accept anything. So the check will be different from the case of DDNS.

Stephen: Maybe it should reject the updates. Maybe we should fail over to AXFR. To be raised on the list!

Jelte: Task for the next sprint of trying to get an overview of what to do and a design. Stephen: An overview for IXFR-out as well?

Jelte: Yes.

Jelte: How far on boss configuration stuff?

Michal: Working in spare time, but already have most of the guts are there. Now need to connect it in. Probably have a follow up ticket for corner cases. Also can't really change the configuration, so I will be creating a ticket for that later on.

Jelte: So the initial version would be something we can add to this sprint as well?

Michal: I'd like to. Do we want to put the things we missed or skipped in the next sprint? If so, which? review of the completeness of the IXFR implementation. We were under a lot of time pressure to get IXFR into the release and I think we did extremely well to get as far as we did. But what did we leave out and and do we want to include it in the next sprint?

Jinmei: Some IXFR missing things are already in next-sprint-proposed. I don't know if we want to solve all of them in the next sprint, but these follow up tasks will definitely be part of the next sprint.


Current sprint:

  • #1045... will remove from sprint, Jelte will contact Carsten
  • #1194... easy?

Stephen: Gives different results on my system.

Jelte: Also buggy on Debian-derived systems.

Put on next sprint. #1207 & #1208

Jelte: Missing some details, but I would still like to remove the old implementation.

Michal: Still need NSEC and NSEC3 support, so we cannot do it yet.

Jinmei: We cannot do this yet, realistically.


Stephen: How important is it since we have a lot of untested systems?

Shane: Why do we have this?

Stephen: Because we were doing IXFR tests, so we got carried away.

Stephen: Maybe we should switch to something like Cucumber before we write too many more tests?

Jelte: Should we have a task about that?

Jinmei: If the plan is to move to something more modern than shell-script based system tests, then it would be better to do it sooner. I don't know which sprint is the best timing to do this.

Shane: It's possible that it is lightweight.

Jelte: So add a smallish exploratory task to see how much work it is?

Stephen: Had we made any determination as to which package to use?

Jeremy: No. Also we should not necessarily worry about waiting for BIND 9 but we will make sure it is compatible with BIND 9. Cucumber itself is Ruby, there are 3 Python implementations. My suggestion is to use a Python one and try starting/stopping/queries and see from there.

Jeremy: We had also mentioned a separate Git repo and asked others to participate.

Michal: That can be done later. Git can take differences on a subdirectory and extract to a different repository so we don't need to worry about it right now.

Jinmei: I think we need to explicitly find a volunteer.

Jelte: We will force this on someone. (see #611)

#1244 - we need #1162 - add #1178

Jinmei: This needs to be divided. I guess this will be out of scope for this sprint.

Michal: Need this for NSEC3 support, so should have this before the release when we switch.

Jinmei: Maybe we can put this on at a lower level of priority, so maybe someone can at least divide the tasks. #1198

Jinmei: Question is whether NSEC3 support or this one should be done first. Will improve readability of the code. Knowing the complexity of the code I think we should do this relatively sooner.

Michal: We have a 200-line function which will go when we do NSEC3.

Jinmei: Realistically refactoring is not a heavyweight task, so my suggestion is to include it for the next sprint. Will add.


Jelte: If we are going to the simple version I think we can do it in this sprint.

Jinmei: Whether or not we include it, I think we should focus on the easy part rather than solving everything in one ticket.

Michal: There will be a little bit of validation because we need to propegate the changes to the component, so there will be some validation, but the problem is when the validation breaks the system is in a strange state.

Jelte: It is certainly not trivial.

Jeremy: When we load a configuration we have to consider what state each component is in. Are they all pushed to a default state?

Michal: if we push to multiple components, we push to the first, then it works, but we push to the 2nd, then it fails, then we load half of the configuration. This is a problem with our usual commit in bindctl. The would solve the bigger problem and have the loading use that.

Stephen: Are we in danger of starting off with a very complicated package? The whole lot live in one single file. Wouldn't it be simpler to export the current configuration (where bindctl just copies the configuration), and load a configuration (bindctl loads the specified file).

Michal: That's a problem because you don't do it at runtime.

Stephen: We can save to a backup, "last known good". Do we need something complicated?

Jelte: I think we can have something simple but not trivial.

Jinmei: My question is... how urgent is it? Whether we want to solve this in the next sprint?

Shane: I'd like to have it in the next release, but perhaps we should try to focus on tasks that are more planning oriented.

Jelte: Perhaps we can defer it. Though if we are going to have the same discussion next sprint planning then it was a wasted few minutes!

Jinmei: When we decide this is one of the urgent tasks, we can divide it into several tasks that can be done at the same time and completed in that sprint.

Move away!


Jeremy: Very minor patch. I've been using for 11 days. I'll just push it to master.

Other tasks?

#917 (statistics ticket) #1271 #1246 #1272 #1180 Shane suggest as a quick fix

IXFR followup

#1278 #1279

Jinmei: #1288 would be nice

Jelte: Will depend on #1217

Jelte: Will add both, but not sure because we don't have estimates! :(

Jinmei: #1288 depends on #1287... I don't insist it be included.

Jelte: If we include #1288 we'll also include #1287.

Shane: propose #1275 and #1286 since those are in reviewing

Jeremy: I can put #1286 in today.

Jinmei: Might be dangerous... it affects the build system.

Jeremy: I'll run the branch against the autobuilder.

Jinmei: I personally wouldn't do that, but I will leave it to you!

Any other business

Jeremy: Validation beginning? Views documented?

Jeremy: Multiple cores on the auth server?

Jeremy: We had "updating NSD prototype to allow prototypes".

Michal: Update to boss will allow starting the same process multiple times.

Jelte: We may run into communication problems then...

Michal: yes that's the other thing we need!

Jinmei: Do we have enough bug fix tickets?

Michal: At least 4 from next-sprint-proposed...

Jinmei: I suggest #869

Jeremy: We discussed November release as production ready for auth server. We discussed an entire sprint for fixes leading up to that.

Jelte: I do want feature/feature/reinforcement as a model at some point.

Jinmei: Sufficient statistics-related tasks?

Jelte: We added one. I'm not sure what JPRS's plans are for this.

Jinmei: Maybe not in the context of sprint planning... I wonder when we can close #509?

Stephen: I made suggestions and passed it back to Aharen-san. I thought a number were useful to discuss, but when that was done we should close the ticket. We can raise another ticket later.

Kambe reports that Aharen is checking the feedback.

Jinmei: Suggest giving this the highest priority and close it. If we want more then we will create focused tickets rather than leaving this in the queue forever.

Michal: FYI I'll be missing work next Tuesday, because they want me in the office for testing.

Last modified 7 years ago Last modified on Oct 19, 2011, 2:13:45 PM