Changes between Version 1 and Version 2 of WeeklyMinutes20100520


Ignore:
Timestamp:
May 20, 2010, 4:26:36 PM (8 years ago)
Author:
shane
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WeeklyMinutes20100520

    v1 v2  
    1 WARNING: MEETING IN PROGRESS - NOTES ARE WONKY
    2 
    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)
    12 
    13 
    141== Attendees ==
    152
    163{{{
    174Shane
    18 Ting Ting
    195Likun
    206Jerry
    217Feng
    22 
    238Hankins
    249Michael
     10Fujiwara
     11Jelte
     12Jeremy
    2513Larissa
     14Jinmei
     15Kambe
     16Shawn
    2617Evan
    27 Jeremy
    28 Jelte
    29 Fujiwara
    30 Kambe
    31 Jinmei
    3218}}}
    3319
    3420== Action Point Issues ==
    3521
     22Shane put up the ActionPoints page, but put no actions in it.
     23
     24'''AP''' Shane to populate the ActionPoints page!
     25
    3626== Change to Meeting Day ==
    3727
     28No problems with moving raised, preference was for Tuesday.
     29
     30Starting next week (2010-05-25) weekly call will be on Tuesday.
     31
    3832== Date of Next Face to Face Meeting ==
    3933
     34Will be 2010-08-30 to 2010-09-03 (2010-w35).
     35
     36'''AP''' Shane to send e-mail confirming this date.
     37
    4038== Issues for Next Release ==
    4139
    42 Hotspot cache
    43 
    44 ----
    45 
    46 Select address/port to listen on
     40'''Hotspot cache'''
     41
     42Shane: Michael has no time.
     43
     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.
     45
     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.
     47
     48Shane: Can continue work on write-up after code freeze.
     49
     50Evan: Michael and I will talk after this and see if we can get it done.
     51
     52Jelte: It does not matter who does not finish it. :)
     53
     54----
     55
     56'''Select address/port to listen on'''
     57
     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.
     59
     60Jinmei: This is one from Jeremy, and he said it was important for the next release.
     61
     62Jelte: I thought if this was configuration manager stuff that we needed the port rebinding daemon stuff.
     63
     64Jinmei: My understanding was that for this release is that this should be something intermediate. But Jeremy can explain that probably...
     65
     66Jeremy: IIRC just add a switch to the IP address or port to listen on.
     67
     68Evan: You mean command line option?
     69
     70Jeremy: Yeah, okay!
     71
     72Jinmei: Why is this crucial?
     73
     74Jeremy: Shane had to manually hack the code to listen on one of his interfaces.
     75
     76Shane: That's right.
     77
     78Michael: We actually can't do it with the wildcard address, since you need to send a UDP packet back from the proper interface.
     79
     80Shane: It's a common, non-standard extension.
     81
     82Michael: It is standard in IPv6, but not in IPv4 and not supported in Windows for example.
     83
     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.
     85
     86Jinmei: The implementation should be simple.
     87
     88Shane: Yes, but the information isn't passed down through the various layers now. But it's not rocket science.
     89
     90Shane: Is this more important than the hotspot cache?
     91
     92Jinmei: I think this is a kind of optional feature.
     93
     94Jelte: The cache is, you mean?
     95
     96Jinmei: Ah yeah.
     97
     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.
     99
     100Jeremy: Can we also create a ticket to listen on different IPs to send answer on the correct IP?
     101
     102Shane: I think it's a good idea, and we can put it in the backlog.
    47103
    48104== Architectural Discussions ==
    49105
     106zone manager will be designed as one daemon process, though it only serves
     107for xfrin. Any better advice?
     108
     109Shane: Michael had a suggestion about calling the process something to indicate that it is for managing secondaries.
     110
     111Jelte: I think xfrin is a better name than "zone manager".
     112
     113Michael: 'xfrin' handles the transfer in.
     114
     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.
     116
     117Shane: We can write it in a way to make it easy to write as multiple processes or multiple threads, right?
     118
     119Likun: Right.
     120
     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.
     122
     123Jinmei: Yeah but that also means the complexity wouldn't be so different with threads or processes.
     124
     125Michael: You're right.
     126
     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.
     128
     129Shane: Or just kill it.
     130
     131Jelte: Be careful about killing an incoming transfer.
     132
     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."
     134
     135Jinmei: We will send a query for responding to NOTIFY... I'm not really sure which process or thread does that.
     136
     137Shane: We were thinking that b10-auth would reply to a NOTIFY.
     138
     139Jinmei: What about the SOA query?
     140
     141Feng: The xfrin process would create the query.
     142
     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.
     144
     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.
     146
     147Jinmei: Even without NOTIFY we have to check SOA.
     148
     149Feng: Yes, there is a timer in the zone manager.
     150
     151Jinmei: So the zone manager does the periodical SOA queries.
     152
     153Feng: Yes, there are two scenarios to send SOA requests. 1) when we get a NOTIFY, 2) according to the refresh time.
     154
     155Shane: In all cases the zone manager does the SOA check.
     156
     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.
     158
     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.
     160
     161Jinmei: That may be an option....
     162
     163Michael: In BIND 9 we only put the dangerous parts in the dangerous parts... we don't want everyone writing their own packet processing.
     164
     165Shane: It sounds like we don't have a model yet.
     166
     167Michael: I think everyone has a model in their head.
     168
     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.
     170
     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.
     172
     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.
     174
     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...
     176
     177Shane: We could also say we trust it if is TSIG...
     178
     179Michael: It's a Paul Vixie "add something in the packet and then tell you not to use it".
     180
     181Feng: In BIND 9 we can see the SOA in the answer section.
     182
     183Shane: Sounds like we have a model, we just need to write that up.
     184
     185Feng: I'll do that.
     186
     187Likun: Ignore the SOA record in the NOTIFY?
     188
     189Feng: Yes.
     190
     191Feng: The list of masters will be in the cfgmgr?
     192
     193Shane: Yes, we decided that last week when my bad ideas were corrected.
     194
     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...
     196
     197----
     198
     199Python logging framework?
     200
     201Jerry: Discuss on mailing list.
     202
     203----
     204
     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?
     206
     207Michael: Windows eventually.
     208
     209Evan: Should I be adding something for this?
     210
     211Shane: There's at least an automake rule for this....
     212
     213Evan: Somewhere down in the guts of ASIO there is a constructor which requires pthread_mumble()
     214
     215Jelte: This sounds familiar.
     216
     217Evan: Just required for a session unit test.
     218
     219Jeremy: Sounds like the issue I've had where I only needed pthread for test...
     220
     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...
     222
     223Shane: Did your fix turn on pthread for everything.
     224
     225Evan: No.
     226
     227Shane: If it's the test not working, we can disable the test on a non-pthread system.
     228
    50229== "Too Hard" topic: Multiple Auth Servers ==
    51230
     231Shane: Not sure about how to interact with config stuff.
     232
     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.
     234
     235Shane: We at least need the way to have everything respond to a command in the same way.
     236
     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.
     238
     239Shane: You mean like listening on different ports or something like that.
     240
     241Jelte: Maybe an internal auth and an external auth.
     242
     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.
     244
     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.
     246
     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.
     248
     249Shane: I think I didn't like having to add process management logic to the auth server.
     250
     251Jelte: Essentially you are reproducing the boss and moving it one level lower.
     252
     253----
     254
     255Jinmei: Is it also related to how to use multiple processors or multiple cores?
     256
     257Shane: It's the same.
     258
     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.
     260
     261== AOB ==
     262
     263I'd like to see if anyone has opinion about open points of trac#49
     264(name::split). https://bind10.isc.org/ticket/49
     265
     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
     271
     272Jinmei: We want to look at www.example.com and then example.com 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.
     273
     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.
     275
     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.
     277
     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.
     279
     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.
     281
     282Evan: I will read the ticket and see what your reasoning is.
     283
     284Jinmei: That would be helpful, but I will probably just use your suggestion. But read in case you are interested in that.