17:03:12 <Kiall> #startmeeting designate
17:03:13 <openstack> Meeting started Wed Jun  4 17:03:12 2014 UTC and is due to finish in 60 minutes.  The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:17 <openstack> The meeting name has been set to 'designate'
17:03:24 <Kiall> Heya - WHo's about?
17:03:27 <timfreund> hello
17:03:29 <jmcbride1> o/
17:03:29 <betsy> o/
17:03:30 <vinod1> o/
17:03:31 <rjrjr_> here
17:03:34 <eankutse> here
17:03:39 <tsimmons> o/
17:03:46 <dtx00ff> here
17:03:50 <mugsie> o/
17:04:18 <Kiall> Okay - So, there's only 1 agenda item today:
17:04:25 <Kiall> #topic How does our dependency tree get updated based on our Atlanta sessions?
17:04:38 <Kiall> #link https://blueprints.launchpad.net/designate/+spec/server-pools#deptree
17:04:42 <Kiall> #link https://etherpad.openstack.org/p/juno-design-summit-designate-session-2
17:04:42 <vinod1> how about action items from last week?
17:05:04 <Kiall> Crap! Forgot about those. U-Turn
17:05:05 <shakamunyi> hello team
17:05:12 <Kiall> #topic Review action items from last week
17:05:35 <Kiall> So - 4 actions from last week, first was: eankutse to get initial answers to jbrattons questions
17:05:41 <Kiall> second was similar, eankutse to pick Jbratton's brain on ops side of things for minidns/pools
17:05:52 <eankutse> not much progress this week
17:06:14 <Kiall> Okay - We'll leave them to next week?
17:06:17 <eankutse> yes
17:06:31 <Kiall> Okay, next two were:
17:06:46 <Kiall> kiall to write our various initial load scenarios and kiall to file BP on exposing the NS (and SOA?) record in the V2 API
17:06:58 <Kiall> As eankutse says, not much progress this week
17:07:05 <eankutse> :-)
17:07:09 <Kiall> Other duties have kept me from them.
17:07:16 <Kiall> #action Carry forward all actions from previous week.
17:07:20 <shakamunyi> ok
17:07:39 <Kiall> Apologies for that :)
17:07:43 <Kiall> #topic How does our dependency tree get updated based on our Atlanta sessions?
17:08:00 <jmcbride1> I posted that agenda item and can speak to it.
17:08:01 <Kiall> I'm not sure who filed this one?
17:08:12 <Kiall> (As a note - can we add names next to agenda items please? :))
17:08:24 <jmcbride1> no prob, will do next time.
17:08:28 <jmcbride1> We did a lot of good work in the etherpad at the summit
17:08:34 <Kiall> jmcbride1: was there a specific concern/question etc? or general discussion?
17:08:54 <jmcbride1> I want to be that info gets translated to blueprints so that anyone who works on them knows what to expect.
17:09:11 <mugsie> yeah - afik, the basic break down is the same
17:09:25 <mugsie> (aka the actual bp's)
17:09:39 <mugsie> we just need to reflect the decissions in the bluerpints
17:09:43 <Kiall> Ah - Okay, so I think the tree itself remains the same (or at the least, very similar). But - Yes - Notes from the etherpad's should be moved into the BPs for reference
17:09:43 <jmcbride1> mugsie: good, I wanted to get the validation.
17:10:07 <mugsie> from a quick look, I don't see any glaring issues with the current tree
17:10:28 <mugsie> I can take an action to update (or in some cases fill in) the blueprints
17:10:41 <Kiall> mugsie: thank you - that would be great.
17:10:49 <jmcbride1> Sweet, thanks mugsie
17:10:51 <mugsie> I should have a good start for the next meeting
17:10:56 <Kiall> #action mugsie to translate etherpads over to launchpad blueprints.
17:11:42 <Kiall> Once done, we should probably review them and agree the translation is correct + what we agreed etc
17:11:46 <mugsie> yup
17:12:27 <Kiall> Okay - Since there was only 1 agenda item, and it seems we're OK with it, we can move to Open Discussion - I have a few bits for that section :)
17:12:29 <richm> o/
17:12:35 <Kiall> #topic Open Discussion
17:12:43 <mugsie> Kiall: missed one?
17:12:54 <Kiall> GRR -_-
17:12:57 <mugsie> BIND9? or is that from last week?
17:12:59 <Kiall> #topic Status of BIND9 backend driver (Ron)
17:12:59 <Kiall> ;)
17:13:08 <rjrjr_> thanks!
17:13:09 <Kiall> It was de-indented, I missed it :(
17:13:42 <rjrjr_> i just wanted to give a status on what is going on with the BIND9 driver.  i have been working on it on and off since the summit.
17:13:57 <Kiall> I've noticed :) It's nice to see it getting some attention
17:14:03 <rjrjr_> so, after talking to kiall, it seems like the BIND9 driver as written shouldn't work.
17:14:22 <Kiall> But - It does. Which is little offputting :/
17:14:33 <rjrjr_> but since it does, we think there might be an underlying issue with storage.
17:14:34 <betsy> except for the delete bug :)
17:14:51 <Kiall> betsy: well, the fix for that highlighted something.. weird.. is going on :)
17:14:53 <rjrjr_> even an add shouldn't work, but it does. 8^)
17:15:26 <rjrjr_> in a nutshell, there is reason to believe commits are happening that are not explicit in the code.
17:15:58 <Kiall> So - Central wraps the storage changes in a TX, that TX will not be committed until after the backend operation succeeds. The problem is - the BIND9 backend is calling back out to central for info, which shouldn't be able to "see" the uncommitted DB changes.
17:16:04 <rjrjr_> i'm tracking down the problem to see if it is a general issue or an issue specific to a database (i'm using mysql).  i have reason to believe it is specific to mysql.
17:16:43 <rjrjr_> mysql does autocommits and i've read enough to believe sqlachemy has some magic to perform to bypass mysql's autocommits.
17:16:44 <mugsie> have you run mysql with full query logging on to see what happens?
17:17:20 <mugsie> afik you can force mysql NOT to auto commit - can't remember how though
17:17:21 <rjrjr_> anyway, i wanted everyone to know i'm looking at it.  regardless, the BIND9 driver will be rewritten to not use syncs to the backend database once i understand the underlying issue.
17:17:27 <mugsie> cool
17:17:33 <richm> If you are running code inside a transaction, shouldn't that code see what's happening inside the transaction?
17:18:11 <mugsie> if it shares the same connection it might actually
17:18:15 <Kiall> richm: Oooo - Wait. How are you deploying the BIND backend? Inside central, or in the agent?
17:18:40 <Kiall> richm: Oooo - Wait. rjrjr_: How are you deploying the BIND backend? Inside central, or in the agent?*
17:18:48 <rjrjr_> richm: i'm looking at it.  BIND9 backend is in central.  but you bring up a good way for me to test this some more.
17:19:15 <Kiall> I assumed agent - which means it would be separate DB TX, while if running inside central, it will be inside the same DB TX
17:20:06 <richm> I don't understand - all backends run inside central?
17:20:07 <rjrjr_> but, as you can imagine, that just shows the issue.  if someone uses the agent, things shouldn't work.
17:20:34 <rjrjr_> but, they are. 8^)
17:20:39 <Kiall> rjrjr_: exactly.. The fact that there is a different is an issue. If the issue is worth fixing is another matter, as mdns is coming in.
17:21:02 <mugsie> richm: you can run backend in designate-agent
17:21:07 <mugsie> backends*
17:21:23 <Kiall> richm: They can run inside central, or, inside the remote agent. The behavior is going to differ between the two I think.
17:21:34 <rjrjr_> that brings up a good question, is it worth my pursuing a rewrite of the BIND9 backend or do we wait for Juno?  regardless, i am still going to track down if we have an issue here.
17:22:01 <rjrjr_> kiall: unless mysql autocommit is occurring.
17:22:12 <rjrjr_> http://stackoverflow.com/questions/23256128/cannot-defeat-mysql-autocommit-via-sqlalchemy
17:22:24 <jmcbride1> rjrjr_ We are not looking to adopt designate/bind before juno.
17:22:25 <Kiall> autocommit should be disabled once you issue a BEGIN
17:23:07 <Kiall> rjrjr_: I think it's valuable to continue, considering the issue it's identified.
17:23:28 <rjrjr_> i will.  i'll have an update at the next meeting.
17:23:56 <Kiall> Great - Let's chat after the meet re the embedded in central vs external agent if you want?
17:24:18 <rjrjr_> sure.
17:24:25 <Kiall> #topic Open Discussion
17:24:27 <rjrjr_> so, rewrite BIND9 driver or not?
17:25:19 <jmcbride1> Is it something the TC will care about for incubation? If not, I would wait.
17:25:28 <Kiall> rjrjr_: well, I think we should identify the issues external to bind9 driver, and fix the BIND9 driver assuming it's not a massive endeavour. Even if the only value is hardening the other components in the process
17:25:44 <richm> +1
17:25:48 <mugsie> jmcbride1: not an issue
17:25:52 <mugsie> Kiall: +1
17:26:02 <rjrjr_> it won't be that easy because of how the serial number is updated right after the add/delete.
17:26:15 <mugsie> it will also give us a heads up for the juno cycle
17:26:21 <rjrjr_> delete then serial number, both sync.  add then serial number, both sync.
17:26:34 <Kiall> rjrjr_: well, I wonder if we can re-use some of the import/export code.. Load up the zonefile, make the change, write it out. Same as powerdns etc
17:26:42 <Kiall> instead of calling back out to central for everything
17:27:08 <Kiall> In theory, that should be pretty easy (theory often differs from reality though)
17:27:42 <jmcbride1> kiall: why not focus all our time on BIND in server pools/minidns?
17:27:42 <rjrjr_> okay, we can move on.
17:28:01 <jmcbride1> ^instead of fixing the current implementation
17:28:19 <richm> I would like to get bind9 working for "legacy" clients/customers
17:28:31 <rjrjr_> jmcbride1: we'd be waiting 6 months for BIND9 support.  remember, we though most people are going to be interested in BIND.
17:28:36 <Kiall> jmcbride1: Because in fixing the driver, we seem to have identified some issues external to the driver, I think ensuring we have a good way to handle these issues is a good thing.
17:28:43 <Kiall> rjrjr_: ++
17:28:48 <jmcbride1> richm: OK, that is a great reason
17:29:12 <Kiall> Okay .. So .. Open Discussion.. I have one: http://git.openstack.org/cgit/stackforge/designate-specs/
17:29:30 <Kiall> All the OpenStack projects are moving from writing blueprints on the Wiki, to doing them in a specs repo.
17:29:42 <Kiall> Ours has been setup, and is ready to go for newly written blueprints.
17:30:01 <Kiall> An example from nova is http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno
17:30:20 <betsy> I knew that Heat had started doing that, but I didn’t know it was all of openstack
17:30:34 <Kiall> Yep - Everything is slowly migrating
17:30:42 <Kiall> Once rendered, the specs look like this:
17:30:43 <betsy> What’s the advantage?
17:30:43 <Kiall> http://docs-draft.openstack.org/99/97499/6/gate/gate-designate-specs-docs/7b3ae45/doc/build/html/
17:30:58 <Kiall> betsy: code review etc of the specs similar to actual code
17:30:59 <rjrjr_> history maybe?
17:31:03 <Kiall> ^ too
17:31:10 <mugsie> betsy: it is clear when a blueprint is aprroved
17:31:24 <Kiall> Sorry - Example rendered spec: http://docs-draft.openstack.org/99/97499/6/gate/gate-designate-specs-docs/7b3ae45/doc/build/html/specs/juno/example.html
17:31:30 <tsimmons> So more of an official process for writing/reviewing blueprints.
17:31:37 <mugsie> tsimmons: yup
17:31:41 <Kiall> tsimmons: exactly, and no horrible wiki markup :D
17:31:54 <Kiall> (I'm an oddball who likes RST format ;))
17:31:54 <rjrjr_> so, the core team will +2 the blueprints?
17:31:55 <tsimmons> Kiall: That I can get behind.
17:31:57 <mugsie> and it is much easier to leave feedback
17:32:04 <mugsie> rjrjr_: yes
17:32:06 <betsy> The wiki markup sucks
17:32:16 <Kiall> rjrjr_: Yes, the designate-core team have the +2/+A rights on the repo
17:32:35 <Kiall> Now - launchpad blueprints should still be filed.
17:32:43 <mugsie> but link to the review
17:32:45 <Kiall> The name of the BP on LP should match the filename in the repo
17:33:00 <mugsie> Kiall: it might be worth writing this up
17:33:13 <Kiall> The openstack-infra folks are working on some automation to manage the LP side, similar to what happens when you reference a bug in a commit message
17:33:18 <mugsie> (or ripping it from another projects wiki)
17:33:32 <Kiall> mugsie: Yea, I've not see anything on the other projects wiki yet
17:33:35 <eankutse> Are dependency graphs auto generated here as well?
17:33:53 <rjrjr_> i notice Gerrit has some sort of time limit on how long things are shown on the list without activity.
17:33:56 <Kiall> eankutse: no, Launchpad will still be used for that kinda thing. The specs repo replaces the use of the Wiki
17:34:05 <Kiall> e.g. we used to have LP+Wiki, now we have LP+Specs
17:34:07 <eankutse> thx
17:34:29 <mugsie> rjrjr_: that only kicks in after a negitve review
17:34:42 <mugsie> aka a -1 or a failed build test
17:34:43 <Kiall> rjrjr_: I actually think that's been disabled now
17:35:02 <rjrjr_> cool.
17:35:16 <rjrjr_> was troubling to see my WIP disappear.
17:35:23 <betsy> So should we change to this for any open blueprints?
17:35:31 <mugsie> pools
17:35:36 <betsy> Or just new ones in the future
17:35:44 <mugsie> i will move them to this anyway
17:35:49 <Kiall> betsy: If a wiki page already exists, I'd say no. Otherwise, yes.
17:35:59 <betsy> kiall: cool
17:36:23 <Kiall> Cool :)
17:36:40 <Kiall> Next one I had was - https://review.openstack.org/#/c/97348/ - Add Designate DevStack/Requirements/Docs Jobs
17:36:51 <Kiall> Just an FYI these jobs will be coming in real soon now.
17:37:03 <mugsie> :D
17:37:13 <Kiall> DevStack is obvious - same thing we had before, just as part of OpenStack CI directly.
17:37:16 <mugsie> real soon - we need them for incubation ;)
17:37:24 <Kiall> The docs job validates the docs don't fail to build.
17:37:44 <Kiall> and the requirements jobs validates our requirements align with https://github.com/openstack/requirements
17:37:57 <Kiall> All are requirements for incubation and/or gradutation.
17:38:38 <Kiall> To start - There all non voting, i.e. a fail won't prevent a merge, after we're happy they are stable, we'll switch them to voting.
17:38:41 <Kiall> Any Q's?
17:38:55 <richm> sounds good
17:39:00 <betsy> +1
17:39:14 <eankutse> +1
17:39:34 <Kiall> Cool .. That was all I ad to add..  :)
17:39:38 <Kiall> Anyone else?
17:39:39 <mugsie> i have one
17:39:40 <betsy> I have something
17:39:40 <mugsie> https://review.openstack.org/#/c/97609/
17:39:45 <mugsie> #link https://review.openstack.org/#/c/97609/
17:39:46 <betsy> go ahead
17:39:54 <mugsie> voting is underway for incubation
17:40:02 <mugsie> so keep an eye on that link above
17:40:17 <eankutse> Yay!
17:40:19 <mugsie> once that reaches a consensous - we will be incubated
17:40:31 <richm> how to configure gerrit to email any time there is any activity in a review?
17:40:36 <Kiall> mikal has given us an -1.. Hopefully we can convince him to change his mind after updating the incubation application :P
17:40:39 <mugsie> add yourself as a reviewer
17:40:41 <Kiall> richm: you can Star it
17:40:47 <Kiall> or do that
17:41:04 * mugsie did not know about staring in gerrit
17:41:08 <betsy> James Blair made a comment that he wants devstack running first
17:41:22 <Kiall> Yep - I'm pushing to get that devstack change merged :)
17:41:24 <mugsie> yeah - so Kiall's last link has to merge
17:41:44 <Kiall> I've asked infra to review it as a priority, not that they don't have enough to do already ;)
17:41:48 <mugsie> that was a pretty much universal req from them
17:42:01 <richm> star - how do I "star" a review?
17:42:13 <mugsie> at the top beside the title
17:42:54 <richm> Ah - I see - to the left of the text "Commit Message" there is a "hollow" star
17:42:58 <Kiall> Yep
17:43:04 <richm> If you click on it, it gets filled in with yellow
17:43:17 <vinod1> What happens after you "star" the review?
17:43:26 <richm> Then if you go to the "Starred Changes" link, it will show up
17:43:57 <mugsie> thats all i had
17:43:58 <Kiall> Okay, anyone have anything else?
17:44:02 <betsy> me
17:44:23 <betsy> Kiall - we had talked about whether RecordSet table should be split or not
17:44:41 <betsy> I talked to a dba this week (different than the last one I talked to) and he agreed with you that it should remain one table
17:44:48 <betsy> So, I’ll rewrite the bp to reflect that
17:45:08 <betsy> We’ll only split out the Record table
17:45:18 <Kiall> betsy: cool - I'm happy to hear that, the split of the RRSet table made me nervous :)
17:45:32 <betsy> :D
17:45:57 <betsy> that’s all I had
17:46:04 <Kiall> (for those who weren't around, we discussed splitting the Record and RecordSet table into a table per RRType (A, AAAA, MX, etc)
17:46:41 <Kiall> Okay - Anything else? 13 mins or so left.
17:47:33 <mugsie> i am good
17:47:36 <Kiall> I'll take silence as a no :)
17:47:46 <rjrjr_> also good.
17:47:49 <eankutse> nothing
17:48:10 <Kiall> Okay - Thanks all
17:48:18 <Kiall> Ill go bug infra people again ;)
17:48:22 <Kiall> #endmeeting