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