17:00:50 <Kiall> #startmeeting Designate
17:00:51 <openstack> Meeting started Wed Oct 29 17:00:50 2014 UTC and is due to finish in 60 minutes.  The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:55 <openstack> The meeting name has been set to 'designate'
17:00:56 <Kiall> Hey folks, who's about?
17:00:59 <mugsie> o/
17:01:39 <vinod1> o/
17:01:47 <timsim> o/
17:01:49 <betsy> o/
17:02:45 <Kiall> Okay, So agenda wasn't updated with any new topics :) So, let's start with
17:02:46 <Kiall> #topic Pools - Where are we? (kiall)
17:03:16 <Kiall> A few more of the pools changes landed yesterday/today .. What have people got outstanding?
17:03:33 <betsy> I’m working on adding the pool_id column to domains
17:03:39 <betsy> And associated code changes
17:03:52 <vinod1> https://review.openstack.org/#/c/125868/ is ready to be reviewed and merged
17:04:19 <rjrjr_> i have lots of work on the service and central.
17:04:31 <Kiall> vinod1: I saw that one go up a couple of minutes ago :)
17:04:32 <rjrjr_> i was turning my attention today to the remaining storage changes i need.
17:04:40 <betsy> rjrjr_: to do or done already?
17:05:00 <Kiall> rjrjr_: I've seen a few revisions of your latest PS, is it ready for review?
17:05:38 <rjrjr_> what i submit is ready for review.  what everyone needs to understand is nothing is 100% complete, because i'm working without all the dependencies.
17:05:43 <Kiall> Ah - I'm thinking of the BIND9 one, rather than Create/Delete
17:05:58 <rjrjr_> bind9 is ready for review.  so is the other.
17:06:06 <Kiall> rjrjr_: Ok - So, what dependencies are you blocked on for starting to wire stuff up?
17:06:14 <rjrjr_> mdns, storage.
17:06:39 <Kiall> betsy's storage changes should be in, is there more still required there?
17:06:50 <mugsie> pool_id colum?
17:06:54 <Kiall> (They landed last night..
17:07:07 <betsy> Yeah, there’s some more, but the basic pool tables are there
17:07:07 <Kiall> as did vinod1's API additions for pools
17:07:10 <rjrjr_> ah, last night.  that's good.
17:07:38 <rjrjr_> what about mdns?  haven't been able to work on domain update without that one.
17:08:04 <mugsie> they should work as is right now...
17:08:14 <Kiall> Yep - With the frontend pieces in place, and if betsy's final change (pool_id's for the actual domains) lands, we should in theory be able to start wiring stuff up - at least for a single pool
17:08:14 <vinod1> mdns is ready to be reviewed and merged
17:08:16 <mugsie> just without separate namespaces
17:08:19 <rjrjr_> there are no calls for me to make at this point to mdns.
17:08:23 <timsim> rjrjr_: for mdns: https://review.openstack.org/#/c/125868/
17:08:28 <Kiall> yea, what mugsie said is my "for a single pool"
17:09:07 <rjrjr_> timsim: correct.
17:09:39 <Kiall> Okay.. So getting the tsig bits in for multi-pool needs to happen ASAP... my openstack/requirements change finally got a -1 yesterday, so I'll get that updated so we can add the tsig pieces to mdns for multi pool
17:10:58 <rjrjr_> anything i submit is ready for review.  just understand, it may not be 100% complete as i'm waiting on other pieces.
17:11:26 <Kiall> rjrjr_: we'll also need to add the pool-mgr service into the DevStack pieces, so we can have it up + running so we can wire central -> pool mgr..
17:11:27 <Kiall> We *may* want to do that in a phased way, e.g. create a tiny traditional backend that forwards over to the pool mgr, so we can keep everything working while we transition
17:11:56 <Kiall> thoughts?
17:12:21 <rjrjr_> i agree.
17:12:23 <timsim> If we can't avoid adding things that don't break the current stuff, we should probably do that.
17:12:26 <mugsie> yeah - I think with out a separate branch, we will have to
17:12:56 <mugsie> It should just be copy + paste what would be in central though
17:13:05 <rjrjr_> this morning, i'm going to make changes to storage which will add the needed rows to existing tables and modify central so it won't break what works today.
17:13:24 <rjrjr_> that sets me up for the update_status method in central.
17:14:54 <Kiall> Okay.. Sounds like we have a plan :) I'll add pool-mgr to DevStack, and (re)start the tsig stuff, rjrjr_ since you're most familar with the pool mgr stuff - could you add a traditional backend that calls out to PoolMgr for CUD domain calls?
17:15:28 <rjrjr_> traditional backend = powerdns?
17:15:29 <Kiall> betsy covers off the pool_id stuff in the domains table, and we hopefully have messages flowing from the API through to the pool mgmr correctly at that point
17:16:12 <mugsie> rjrjr_: a shim one
17:16:21 <Kiall> rjrjr_: a backend that can load into todays central code, and just forwards over to the pool manager service.. Similar to impl_multi.py but talking to poolmgr
17:16:30 <mugsie> that proxies a call from central to pool managers
17:16:58 <Kiall> The idea being to get that in place early, so the rest of pool mgr and it's pieces can be build + tested end to end before pulling the old stuff out of central
17:17:20 <rjrjr_> without mdns, i can't work on update.
17:17:48 <rjrjr_> can we get vinod's work through today?
17:18:25 <Kiall> rjrjr_: Yep - mugsie / betsy / myself - can we get that reviewed + approved after this meet assuming no issues?
17:18:33 <rjrjr_> cool.
17:18:49 <mugsie> yeah, np
17:19:14 <Kiall> Any other pool's statues to bring up?
17:19:34 <rjrjr_> i have a question in the meeting, but we can wait.
17:19:57 <Kiall> Okay.. Since the agenda wasn't updated.. we'll move to
17:19:57 <Kiall> #topic Open Discussion
17:20:03 <Kiall> rjrjr_: you had a question? ;)
17:20:31 <rjrjr_> Pools - Should 'masters' join 'name-servers' and 'also-notify' in pool object?
17:20:47 <rjrjr_> ekarlso brought up this one the other day.
17:21:02 <rjrjr_> it seems like 'masters' is going to be a concept for every backend driver.
17:21:28 <mugsie> hummm...
17:21:41 <rjrjr_> should it be elevated to the same level as name-servers and also-notify in pools or does it remain a backend option?
17:21:42 <mugsie> as in the mDNS addresses to slave off?
17:21:46 <Kiall> rjrjr_: thinking... I seem to remember a reason it wasn't included
17:21:49 <rjrjr_> mugsie: correct.
17:21:59 <rjrjr_> technically, it is a backend option.
17:22:13 <rjrjr_> but, it will probably be used by every backend.
17:22:15 <mugsie> that, in theory, could be autogen'd in the future (as mDNS nodes come and cgo)
17:22:26 <mugsie> so, maybe.
17:22:48 <mugsie> but, there will be a requirement to be able to override it
17:22:53 <timsim> Yeah you wouldn't want to do that in the config unless you can reload it without restarting the service. So it makes some sense.
17:23:09 <Kiall> well - reloading the config is something we can actually do
17:23:10 <mugsie> (as some people will limit "masters" to mDNS nodes in the same region
17:23:35 <Kiall> and - for "private" or "managed" pools, I'm thinking it's something we should avoid exposing.
17:23:48 <rjrjr_> send a "HUP" signal to pool manager service to reread config?
17:24:06 <mugsie> Kiall: in the object != exposing though
17:24:13 <rjrjr_> that is a common practice with other UNIX daemons.
17:24:14 <Kiall> rjrjr_: yea, we just need to wire HUP -> oslo.config's reload method, and make sure our code isn't broke ;)
17:24:53 <rjrjr_> that brings up a good point about the config changing out from under pool manager service, even on a restart...
17:24:57 <mugsie> and, it would allow for mDNS nodes to be added / removed w/o reloading a load of pool managers
17:25:10 <Kiall> I'm thinking the list of masters shouldn't be associated (directly) with a pool.. a pool might span multiple regions, but you want region local AXFR's to happen
17:25:36 <timsim> That's true ^
17:26:01 <mugsie> yup - hense the "override" bit - but for the 90% use case - it make things a lot easier
17:26:12 <mugsie> (for smaller installs)
17:26:37 <Kiall> I'm not sure I understand how it make it easier?
17:26:38 <rjrjr_> i think we leave 'masters' a backend option.  let's get pools working.  then add 'HUP' capability.
17:27:11 <Kiall> rjrjr_: ++ from me, doing that leaves the door open for a more through through plan later without too much baggage..
17:27:21 <Kiall> thought through*
17:27:34 <mugsie> for v1, - leave it as is
17:27:38 <timsim> I think I prefer that as well.
17:27:56 <Kiall> and .. the less code we have to write, the better ;)
17:28:10 <rjrjr_> i still need to consider what happens when the config changes (for example a server is added or deleted) and the pool manager is restarted.
17:28:18 <rjrjr_> i'll need to handle that in the periodic_sync.
17:28:39 <rjrjr_> and domain_update now that i'm thinking about it.
17:29:33 <Kiall> rjrjr_: yea .. there's likely a few places stuff like that may be needed :)
17:30:02 <rjrjr_> i'm pretty sure i know what needs to happen.  feel like i'm living this code right now. 8^)
17:30:24 <Kiall> It *may* be worth a second periodic task to maintain that kinda of config of existing zones, leaving the periodic_sync task to just ensure the list of zones is accurate.. Not 100% sure..
17:31:06 <Kiall> (My thinking being we want to create/delete missing zones ASAP, which means a short periodic interval, while adding a new mDNS might not be urgent)
17:31:22 <rjrjr_> the biggest issue is when a server is removed.  do we remove it from the cache?  it goes into the calculation for the threshold.
17:31:56 <rjrjr_> might need to add a 'active' field to the table and activate those entries for servers that exist.
17:32:10 <rjrjr_> and deactivate the rest.
17:32:34 <rjrjr_> i'll give this some thought.  but not right now.  i'd like to get the 'straight path' working first.
17:33:04 <Kiall> rjrjr_: good Q.. is a physical server is removed part way through a change, and the threshold is 100%, changes made will fail for a short interval. I think that's acceptable - especially for v1 - as operators can choose to reduce the threshold before decommissioning a server
17:33:39 <mugsie> rjrjr_: yup - I think the happy path is the one to walk initially
17:33:52 <rjrjr_> okay.
17:34:11 <rjrjr_> if all goes well this week, i'd like to accomplish happy path by Friday.
17:34:16 <mugsie> :)
17:34:46 <Kiall> Okay - Any other topics for the agenda today?
17:34:49 <betsy> I’ve got something
17:35:07 <rjrjr_> i'm not asking for a rubber stamp on the code pushes, but if we can somehow keep in mind right now changes are work in progress, that would be helpful.
17:35:15 <betsy> I’m transferring to a different team within Rackspace, so next Friday, Nov. 7 will be my last day on Designate
17:35:32 <rjrjr_> betsy - 8^(
17:35:33 <mugsie> betsy: :(
17:35:47 <Kiall> betsy: ahh.. :(
17:35:47 <betsy> I know. I’ll be sad, too
17:35:50 <Kiall> Where are you going?
17:36:02 <betsy> To the VMWare team
17:36:11 <betsy> Not on openstack
17:36:25 <jmcbride> Betsy, thanks for all of your dedication and work on Designate.
17:36:36 <rjrjr_> sorry to hear this.  hope you enjoy the new work!
17:36:39 <mugsie> jmcbride: +1
17:36:47 <Kiall> jmcbride: ++
17:36:48 <Kiall> VMWare team? I didn't know RAX had one of those :)
17:36:55 <betsy> yep
17:37:18 <betsy> I’ll miss working with y’all
17:37:45 <betsy> Good luck with Designate.
17:37:52 <Kiall> Thanks :)
17:37:58 <mugsie> ty
17:38:46 <Kiall> So - who's filling your spot on the RAX DNS team? :)
17:38:59 <jmcbride> TBD at the moment.
17:39:17 <jmcbride> With Betsy transitioning, we are fortunate to be able to backfill the role.  If you know anyone that would be a great asset to the Designate project, please let me know.  I'd love to find someone as soon as possible.
17:39:35 <rjrjr_> can they work from another state? 8^)
17:39:36 <Kiall> jmcbride: we're competing for the same talent pool ;)
17:39:46 <jmcbride> Are you hiring too?
17:40:06 <Kiall> Yep .. We're looking for another person for our team
17:40:17 <jmcbride> I hate to mention this so quickly but with the conference next week it is a good chance for us to recruit from attendees.
17:40:40 <Kiall> hah, yep :)
17:40:49 <jmcbride> Of course, sunny Texas is a great place to live ;)
17:41:08 <Kiall> Okay.. Any other topics before we crack a beer to wish betsy the best in the new team? ;)
17:41:13 <timsim> mugsie, ekarlso, vinod1, are we going to do a dry run for the presentation tomorrow?
17:41:35 <vinod1> i am up for it
17:41:57 <vinod1> mugsie: did you get a chance to get the updated diagrams for pools?
17:42:09 <mugsie> vinod1: nope - but i will do it before i leave tonight
17:42:15 <rjrjr_> is tuesday still the day for design sessions?
17:42:27 <mugsie> and, yeah I am up for a run though - will ping you for times in a bit
17:42:53 <timsim> Alright, cool. That's it from me :)
17:43:51 <rjrjr_> is tuesday still the day for design sessions in Paris?
17:44:12 <Kiall> Yep - No changes :(
17:44:32 <rjrjr_> k
17:45:34 <Kiall> Okay .. Let's call it so..
17:45:40 <mugsie> yup
17:45:48 <Kiall> Thanks all, and good luck betsy :)
17:45:52 <betsy> thx
17:45:59 <timsim> We'll miss you betsy :)
17:46:11 <Kiall> #endmeeting