17:03:03 #startmeeting designate 17:03:05 Meeting started Wed Feb 5 17:03:03 2014 UTC and is due to finish in 60 minutes. The chair is vinod. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:08 The meeting name has been set to 'designate' 17:03:21 Who's here today? 17:03:28 Rich 17:03:47 Joe and Betsy will be joining the meeting shortly 17:03:50 I'm here 17:04:23 #topic Review action items from last week 17:05:02 kiall had an action item to write a mini-dns spec ahead of the summit 17:05:23 I would consider that done 17:05:48 really? do you have a link to the spec? 17:05:58 here 17:05:58 eankutse 17:06:03 The action item here was creating the spec just for the summit 17:06:10 and not a detailed mini-dns spec 17:06:51 I see, so you are referring to the doc he prepared for last week's workshop. 17:07:24 #link https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS 17:07:50 Moving onto the next topic 17:07:55 #topic Recap on Designate Mini-Summit in Austin 17:08:31 If memory serves me right, vinod and richm were going to get something together for the dev list. 17:08:37 Anybody have things to share from the summit 17:09:01 I think Rich posted some notes internally in RedHat 17:09:03 I sent email to openstack-dev with summit summary 17:09:11 and sent to our internal rhos list 17:09:27 cool (I missed it) 17:09:42 I put [designate] in the Subject 17:09:57 That seems to be the convention 17:10:40 Yes. I saw it last week. Thanks richm 17:10:59 #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/026023.html 17:11:46 Thanks Joe for the link - I was trying to search for it 17:11:59 my google foo is high today ;) 17:12:20 Anybody have anything else to add 17:12:36 #topic Action items from the summit 17:12:56 Tim had one action item - What is current average commit size? 17:13:18 He Wrote a script that sort of works (counts merge commits twice) 17:13:59 If memory serves right, based on that the average commit size has ~ 194 adds and ~134 deletes 17:14:06 Tim is not around now to verify 17:14:24 But the average commit size for the last year for use seems to be ~ 350 lines 17:14:39 #link https://github.com/Squab/commit-stats 17:15:34 By comparision Solum seemed to average ~ 100 lines per commit 17:15:34 Seems like we need to ratify the original intent of that action item: agree to limit commit sizes to less than 350 lines. 17:16:17 but without kiall and mugsie, I don't think we can establish that just yet. 17:16:25 Do we actually need a hard upper limit? 17:16:33 Or a goal to shoot for? 17:16:38 I think that seems reasonable for now - once we start having a few other committers and reviewers, we can adjust 17:16:44 I'd call it a guideline or goal 17:16:49 Okay 17:17:01 yeah, I don't think we want to have gerrit outright reject large patches 17:17:04 I would vote for it to be a guideline rather than a hard upper limit 17:17:17 vinod: agree 17:17:24 guideline is good 17:17:30 The reviewer can say "hey, can you split this commit?" 17:17:31 We could add it to the documentation in the Getting Involved section 17:17:32 that's what solum does too 17:17:37 On second thought, I think kiall and mugsie were cool with 350. 17:17:52 In that note, we probably need to make the blueprints smaller -- maybe subdivide them 17:18:05 vinod: that sounds like an action item to me! 17:18:07 jmcbride: that's my memory, too 17:18:19 betsy: good point 17:19:39 I think the action is: notify designate devs via the email list about this proposed change. Then update the documentation. 17:19:39 #action vinod update the Getting Involved Section in the documentation for suggested lines of code / commit 17:20:16 vinod: cool, make sure you update the openstack dev list too. 17:20:38 betsy: regarding splitting the blueprints - yes that would be ideal 17:20:53 vinod: Might add that to the documentation, too 17:21:09 The blueprint owners should probably spend some time and split their existing blueprints into smaller ones 17:21:24 vinod: I agree 17:21:39 or rather add new blueprints for smaller work items and track it to the main blueprint 17:21:50 vinod: lets address this as we review/start on new blueprints 17:22:56 #action (all) review/add new blueprints as needed to track smaller work items 17:23:40 The next action item from the summit was "Atlanta summit abstracts on talks/workshop." 17:24:06 I updated the abstract for workshop 17:24:17 #link https://wiki.openstack.org/wiki/Designate/Atlanta#Workshop 17:24:43 Feel free to update the wiki page with your comments/suggestions or send them to me and I will update the page 17:25:42 Tim wrote an abstract for the talk about new features 17:25:47 #link https://docs.google.com/document/d/1xIprT3xEzujFPWJhVGnIKRdsB7gkmpgTgo0DfG3Ml4s/edit?pli=1 17:26:44 I don't have any updates from mugsie and kiall on the abstract for the other 2 talks 17:27:26 Next action item from the summit - "Get feedback from TC on major architectural reworks and Designates chances of incubation." 17:27:27 I think they are still on vacation - probably nothing until next week, I'm guessing 17:27:43 richm: That is right 17:27:56 We still have time until next Fri to submit the abstracts 17:28:51 rich I think you mentioned that Designate's chances for incubation are bright. Do you have any other feedback to share? 17:28:57 I emailed Mark McLoughlin - he said designate looks very good for incubation status - the only real problem last time was too few committers 17:29:28 Also, about the term "Registered Program" - 17:29:50 Mark says: "I haven't heard the term "registered program", but programs are essentially OpenStack's sub-projects except we use the term "program" to recognize that sub-projects can consist of multiple repos (even projects like Nova have nova and python-novaclient) and that not all sub-projects are like the "service" projects we typically think of (e.g. infra, docs, oslo, release management). However, only "service" sub-pro 17:30:30 We also agreed that it would be best to finish the miniDNS architecture changes in preparation for incubation 17:30:59 richm: so is a "program" about the service and related tools (e.g. testing, deploy and cli repos)? 17:31:19 That's what it seems to me, yes 17:31:30 Or is a "program" a group of related services (Nuetron, other networking services)? 17:32:00 Looks like there could be some judgement by the TC involved with that 17:32:15 betsy: do you have any more information on the incubation status? 17:32:50 vinod: Haven't gotten a chance to follow up with Anne Gentle yet 17:32:58 Will give feedback next week 17:33:08 It seems to me that, if designate is incubated, that would include python-designateclient too 17:33:24 richm: yep 17:33:41 richm: I would hope so 17:33:53 Regarding incubation, I would like to know from the TC folks what impact having v2 and mini-dns looming over the project will have on incubation. 17:33:58 * artom always considered the client part of designate... 17:33:59 Not sure if there are currently any other "sub-projects" of designate 17:34:05 richm and betsy: can you guys inquire about those items? 17:34:19 jmcbride: Will do 17:34:56 jmcbride: Ok, will ask 17:34:59 #action Betsy and Rich to followup on incubation status wrt v2 and mini-dns 17:35:24 thanks 17:35:56 There were a bunch of other action items from the summit relating to adding/updating blueprints 17:36:27 I did not specifically add them to the agenda 17:36:49 Anybody have anything to share here - I noticed that some of the items are marked as done in etherpad 17:37:04 yes, there was quite a bit there. I finished mine and simply added a bolded "DONE" next to them. 17:37:44 #topic Open Discussion 17:38:32 Anything on people's mind at this point - here is your chance 17:38:55 richm, out of curiosity, what do you think your team will focus on for development? 17:39:20 First thing will be to do an ipa (bind+ldap) backend 17:39:42 I have some concerns about minidns 17:39:55 yep, seems like that could be a bit of a blocker for you getting started. 17:40:06 One is that we have customers that will refuse to allow any other service to "master" the dns data 17:40:17 including minidns 17:40:19 richm: regarding your concerns about miniDNS 17:40:35 Another is latency - writing an update over LDAP to bind+ldap is very, very fast 17:40:35 would you like to document them under the propoal? 17:40:56 eankutse: Yes 17:41:17 #link https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS 17:41:27 From the perspective of Rackspace and the other folks here, are either of those issues a concern? 17:41:44 I have a few things that I think will guide implementation 17:41:52 I should add them to the wiki as well 17:41:52 richm: what use case do those customers have? Are they tracking their user's desktops or do they track servers in app (for example)? 17:42:48 richm: at the moment, no) 17:43:05 but understanding your use case may make us realize it is a problem. 17:43:06 When a new machine is created in openstack (e.g. nova), you may need to immediately issue ssl certs and/or kerberos keytabs 17:43:19 e.g. keystone 17:43:34 in order to do that, you need a fqdn for the machine 17:44:28 if a client wants to connect to that machine, the client will need that fqdn to resolve forward and reverse in DNS 17:44:28 so how does ldap fit into nova? 17:44:47 richm, not necessarily reverse, but go on ;) 17:45:21 by reverse, I mean that the client and server may only know the ip address of its peer 17:46:04 the client or server will also have the ssl cert or kerberos credentials from the peer 17:46:19 the cert or credentials will usually have the fqdn of the peer 17:46:53 for security, the client or server will want to verify that the ip address resolves to that fqdn 17:47:28 Ah! 17:48:35 basically, ssl and kerberos depend on having fqdn and dns working 17:49:28 what system issues and manages the certificates? 17:50:04 keystone will, at some point 17:51:17 not sure what the current status is 17:51:18 richm: why don't we add an action item for you to document these points so that we can address them at the next IRC (that will give people an opportunity to research a bit too). 17:51:58 We have customers that use Windows Active Directory Domain Controller as their authoritative DNS for their enterprise 17:52:12 They will _not_ want to migrate their data to minidns 17:52:31 seems to me that minidns is an internal implementation of desigante 17:52:35 Won't they *have* to migrate to Designate^ 17:52:38 ? 17:52:41 Why? 17:53:08 If they want to use the REST API to manage their DNS... 17:54:00 So designate _is_ the DNS, not just a _frontend_ to the DNS? 17:54:05 Heya - Just realize the time! Apologies :) 17:54:18 Fundamentally, Designate is the REST API + backend DNS + a databased for all zones/records 17:54:18 Now, it could be that they would be more comfortable using the current backend model and getting a backend for AD... 17:54:19 :-) 17:54:21 kiall: heya 17:54:34 kiall: shouldn't you be on vacation? 17:54:39 But if they use Designate, storage comes with it ;) 17:54:53 Waiting around in the hotel room to head to the airport ;) 17:54:58 artom: Yes - that is what some of our customers will want - they will just want to use designate as a restful + mq aware frontend to their DNS 17:55:20 Hrmm, yeah, I can see how minidns would not work in that case... 17:55:28 and use a backend provided by designate, or provide a backend of their own to tie designate to their master DNS 17:56:14 Essentially by using minidns we're forcing all users to give up any DNS servers that can't operate in slave move. 17:56:16 *mode 17:56:23 richm: (only read half the logs..) I think we'll always have users who want to have something like MS AD as their auth nameservers. I'm skeptical of the value of that other than making the politics easier... 17:56:37 kiall: It is almost always politics 17:57:04 The Q is, is that in scope for designate? I'd argue that it's not, but others may have different opinions.\ 17:57:30 kiall: agree 17:57:32 Designate has always had a "Designate owns the nameserver, all of it" policy .. MS AD DNS doesn't fit that model 17:57:35 kiall: I don't understand - was the purpose of designate always to be the authoritative DNS? 17:57:53 Then designate will shut out a lot of our customers 17:58:20 richm: yes, it's intended to be authoritative and the single point of control over the nameservers it manages.. Long term, things like integrating with MS AD are doable with inbound AXFR 17:58:52 So - MS AD controls the various AD specific (sub-)zones, and designate would AXFR those from the AD DNS's into the queryable DNS servers 17:58:56 Is this written down somewhere? 17:59:23 richm: no, and I'm still working on half context here.. Missed a lot of the start of this conversation! 18:00:05 #action Rich to document the minidns concerns on the wiki spec 18:00:17 To me, looking at the current state of the designate design, was that designate was basically a rest + mq frontend to whatever backend DNS you wanted to use 18:00:22 We could talk about this again in the irc and follow up in the next meeting 18:00:39 As we are out of time 18:00:48 Given that it is 12:00 and trove will have a meeting here now 18:00:50 Ok - moving over to #designate 18:00:50 Another team starts now 18:00:56 bye folks 18:00:58 richm: yes, technically is is.. And it still will be, just the mechanics are changing a bit 18:00:59 Anyway - hub_cap is about to rage if whoever started this meeting doesn't #endmeeting soon :) 18:01:03 #endmeeting