Changes between Version 1 and Version 2 of WeeklyMinutes20100520

May 20, 2010, 4:26:36 PM (8 years ago)



  • WeeklyMinutes20100520

    v1 v2  
    3       * Roll call (10 minutes)
    4       * Action point issues (10 minutes)
    5       * Change to meeting day (10 minutes)
    6       * Date of next face to face meeting (5 minutes)
    7       * Issues for next release (15 minutes)
    8               * Hotspot cache
    9               * Select address/port to listen on
    10       * Architectural discussions (15 minutes)
    11       * "Too Hard" topic: Multiple Auth servers (25 minutes)
    141== Attendees ==
    18 Ting Ting
    27 Jeremy
    28 Jelte
    29 Fujiwara
    30 Kambe
    31 Jinmei
    3420== Action Point Issues ==
     22Shane put up the ActionPoints page, but put no actions in it.
     24'''AP''' Shane to populate the ActionPoints page!
    3626== Change to Meeting Day ==
     28No problems with moving raised, preference was for Tuesday.
     30Starting next week (2010-05-25) weekly call will be on Tuesday.
    3832== Date of Next Face to Face Meeting ==
     34Will be 2010-08-30 to 2010-09-03 (2010-w35).
     36'''AP''' Shane to send e-mail confirming this date.
    4038== Issues for Next Release ==
    42 Hotspot cache
    44 ----
    46 Select address/port to listen on
     40'''Hotspot cache'''
     42Shane: Michael has no time.
     44Evan: Done with Boost ASIO thing now. How much time do you think it will take? I could take a wack at if you don't think it will take a huge amount of time.
     46Michael: I probably think it will take a couple days, but I think your write up of the recursive processing will take a couple months. :) It will take far longer than you think.
     48Shane: Can continue work on write-up after code freeze.
     50Evan: Michael and I will talk after this and see if we can get it done.
     52Jelte: It does not matter who does not finish it. :)
     56'''Select address/port to listen on'''
     58Evan: I was surprised it was assigned to me. I had thought it was cfgmgr stuff, which I have not touched yet, although it is probably time I got my feet wet at that. What I had done in the previous release was make it so you could select the port on the command line.
     60Jinmei: This is one from Jeremy, and he said it was important for the next release.
     62Jelte: I thought if this was configuration manager stuff that we needed the port rebinding daemon stuff.
     64Jinmei: My understanding was that for this release is that this should be something intermediate. But Jeremy can explain that probably...
     66Jeremy: IIRC just add a switch to the IP address or port to listen on.
     68Evan: You mean command line option?
     70Jeremy: Yeah, okay!
     72Jinmei: Why is this crucial?
     74Jeremy: Shane had to manually hack the code to listen on one of his interfaces.
     76Shane: That's right.
     78Michael: We actually can't do it with the wildcard address, since you need to send a UDP packet back from the proper interface.
     80Shane: It's a common, non-standard extension.
     82Michael: It is standard in IPv6, but not in IPv4 and not supported in Windows for example.
     84Shane: Eventually we need better management, but for now I really just need to set the IP address. So that's why it's only a 2 day task.
     86Jinmei: The implementation should be simple.
     88Shane: Yes, but the information isn't passed down through the various layers now. But it's not rocket science.
     90Shane: Is this more important than the hotspot cache?
     92Jinmei: I think this is a kind of optional feature.
     94Jelte: The cache is, you mean?
     96Jinmei: Ah yeah.
     98Shane: I tend to agree. Evan, can you do this before the hotspot caching stuff? A command line option to specify the IP address to listen on.
     100Jeremy: Can we also create a ticket to listen on different IPs to send answer on the correct IP?
     102Shane: I think it's a good idea, and we can put it in the backlog.
    48104== Architectural Discussions ==
     106zone manager will be designed as one daemon process, though it only serves
     107for xfrin. Any better advice?
     109Shane: Michael had a suggestion about calling the process something to indicate that it is for managing secondaries.
     111Jelte: I think xfrin is a better name than "zone manager".
     113Michael: 'xfrin' handles the transfer in.
     115Likun: If xfrin process crash the zone manager keeps the zone timers. We don't need to start the timers, so separate the zone manager as a single process.
     117Shane: We can write it in a way to make it easy to write as multiple processes or multiple threads, right?
     119Likun: Right.
     121Michael: The reason I'm against threads is they add needless complication to the first cut. I would rather see it developed cleanly without threads. As long as we do it in a good model we're okay. No transfer needs to talk to another transfer.
     123Jinmei: Yeah but that also means the complexity wouldn't be so different with threads or processes.
     125Michael: You're right.
     127Jinmei: In that sense I don't have a strong opinion. I have some opinions. The first is that while I reviewed the xfrin code, I noticed that you would not be able to shutdown quickly even if we issued a shutdown command because xfrin handles the xfrin in blocking mode. So if one of the connection stalls it waits for timeout and cannot shutdown. If we use threads we need to introduce some communication from the boss to transaction thread. OTOH, if we use processes we can use signals.
     129Shane: Or just kill it.
     131Jelte: Be careful about killing an incoming transfer.
     133Jelte: I already have an open task about "alive" messages. Perhaps we should add a feature there to say "I am running, but shutting down, please don't kill me yet."
     135Jinmei: We will send a query for responding to NOTIFY... I'm not really sure which process or thread does that.
     137Shane: We were thinking that b10-auth would reply to a NOTIFY.
     139Jinmei: What about the SOA query?
     141Feng: The xfrin process would create the query.
     143Jinmei: The SOA query will be more frequent than the XFR transaction itself. I don't know if it matters, but in the context of processes versus threads, this affects the design decision.
     145Feng: For XFRIN the NOTIFY comes through auth... zone manager will send SOA query, this kind of logic. Based on this feedback the zone manager will tell the XFRIN.
     147Jinmei: Even without NOTIFY we have to check SOA.
     149Feng: Yes, there is a timer in the zone manager.
     151Jinmei: So the zone manager does the periodical SOA queries.
     153Feng: Yes, there are two scenarios to send SOA requests. 1) when we get a NOTIFY, 2) according to the refresh time.
     155Shane: In all cases the zone manager does the SOA check.
     157Jinmei: This is another point. Ideally I would make the zone manager free from transaction with external IP, so we don't have to worry about offending packets. I do not necessarily say this is bad.
     159Michael: I propose something slightly different, which is compatible with both our goals. Write a simple library function which does send a packet & get a packet, and make it very safe. I'm sure we'll have to send queries from other places.
     161Jinmei: That may be an option....
     163Michael: In BIND 9 we only put the dangerous parts in the dangerous parts... we don't want everyone writing their own packet processing.
     165Shane: It sounds like we don't have a model yet.
     167Michael: I think everyone has a model in their head.
     169Jinmei: I don't have a particular model in my mind, I just have issues about possible models. I am judging what these issues are.
     171Michael: My model is that notify is handled by the front end (authority server perhaps). The control channel is used to tell the zone manager, which then does the SOA query. If necessary, it then starts the transfer via the xfrin process - and maybe checks that it worked! Seems simplest and most logical separation of concerns.
     173Feng: I think we're going to use this model and modify the authsrv. We can get the serial from the NOTIFY query, which may include the SOA record. The auth server will check the current zone serial number and see if the SOA is later than the zone in the data source.
     175Michael: You have to do an SOA query regardless. I think the zone manager does the SOA query only. We should always send a message to the zone manager. We don't need to pass the SOA information - the spec says that you should not rely on this information because you have no reason to trust it. We could have the zone manager look at that and compress a set of updates into one...
     177Shane: We could also say we trust it if is TSIG...
     179Michael: It's a Paul Vixie "add something in the packet and then tell you not to use it".
     181Feng: In BIND 9 we can see the SOA in the answer section.
     183Shane: Sounds like we have a model, we just need to write that up.
     185Feng: I'll do that.
     187Likun: Ignore the SOA record in the NOTIFY?
     189Feng: Yes.
     191Feng: The list of masters will be in the cfgmgr?
     193Shane: Yes, we decided that last week when my bad ideas were corrected.
     195Michael: At the next code sprint it would be good to back up configuration externally. Having a way to back it up means you have a way to find it all...
     199Python logging framework?
     201Jerry: Discuss on mailing list.
     205Evan: I'm doing Boost ASIO to ASIO thing. It works fine until I do "test", one unit test needed Pthread. Are we supporting any platforms that will not have pthread?
     207Michael: Windows eventually.
     209Evan: Should I be adding something for this?
     211Shane: There's at least an automake rule for this....
     213Evan: Somewhere down in the guts of ASIO there is a constructor which requires pthread_mumble()
     215Jelte: This sounds familiar.
     217Evan: Just required for a session unit test.
     219Jeremy: Sounds like the issue I've had where I only needed pthread for test...
     221Jinmei: May be that boost version of python requires boost thread support implicitly. So if we use Boost python maybe we are hiding the problem...
     223Shane: Did your fix turn on pthread for everything.
     225Evan: No.
     227Shane: If it's the test not working, we can disable the test on a non-pthread system.
    50229== "Too Hard" topic: Multiple Auth Servers ==
     231Shane: Not sure about how to interact with config stuff.
     233Jelte: Not too much. Some could be for a group, but certainly some are for one specific one. So I'm not sure how to do that.
     235Shane: We at least need the way to have everything respond to a command in the same way.
     237Jelte: Can just get the first response and drop the other. What if you configure it and want to remove one, how will you tell that specific process to shutdown and not the other one. And maybe people think about having specific configurations for each one.
     239Shane: You mean like listening on different ports or something like that.
     241Jelte: Maybe an internal auth and an external auth.
     243Likun: Maybe the configure manager will talk with the parent process of the auth server. So make sub processes. So the father process send command to the sub processes.
     245Shane: I thought about having a "mini boss" but for some reason I liked the idea of having just the workers. But maybe that is more difficult.
     247Likun: At first one process listen on a port. Now you want to listen on another port. So the first will create a new sub-process.
     249Shane: I think I didn't like having to add process management logic to the auth server.
     251Jelte: Essentially you are reproducing the boss and moving it one level lower.
     255Jinmei: Is it also related to how to use multiple processors or multiple cores?
     257Shane: It's the same.
     259Shane: Ultimately for the best performance we may need to look at other techniques for multiprocessing, like Apple's co-routines, but I think it's a good starting point.
     261== AOB ==
     263I'd like to see if anyone has opinion about open points of trac#49
     266The major points are:
     2671. if we need to have both two (createAncestor and createSuffix) types
     268   of "split" or one is enough
     2692. member function vs non member function, especially when we choose
     270   "only one" for the first point
     272Jinmei: We want to look at and then or com. What I implemented was I found that we might need 2 different versions of the convenience wrappers. One gets ancestor, the other suffix. These are very similar. Jelte pointed out that we only probably need just one. After thinking about it again I tend to agree with him. I'm going to kill one of them.
     274Jinmei: Original suggestion was to add a member function to the name class. But in the initial implementation I implemented as a public non-member function, but we could implement it as a member function. Difference in this case is very subtle. I could go either way.
     276Evan: This is the new name::split()? The original suggestion was to take 2 arguments instead of 1. It does not seem simpler to do that as a non-member function rather than have a split with a single argument.
     278Evan: What we suggested was that instead of createAncestor(), you have a version which takes "what is the first label you want" and runs to the end of the name.
     280Jinmei: I expect that you would say that! I have a particular reason why I did not do that. In this case I am also fine with that.
     282Evan: I will read the ticket and see what your reasoning is.
     284Jinmei: That would be helpful, but I will probably just use your suggestion. But read in case you are interested in that.