17:00:50 #startmeeting Designate 17:00:51 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:55 The meeting name has been set to 'designate' 17:00:56 Hey folks, who's about? 17:00:59 o/ 17:01:39 o/ 17:01:47 o/ 17:01:49 o/ 17:02:45 Okay, So agenda wasn't updated with any new topics :) So, let's start with 17:02:46 #topic Pools - Where are we? (kiall) 17:03:16 A few more of the pools changes landed yesterday/today .. What have people got outstanding? 17:03:33 I’m working on adding the pool_id column to domains 17:03:39 And associated code changes 17:03:52 https://review.openstack.org/#/c/125868/ is ready to be reviewed and merged 17:04:19 i have lots of work on the service and central. 17:04:31 vinod1: I saw that one go up a couple of minutes ago :) 17:04:32 i was turning my attention today to the remaining storage changes i need. 17:04:40 rjrjr_: to do or done already? 17:05:00 rjrjr_: I've seen a few revisions of your latest PS, is it ready for review? 17:05:38 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 Ah - I'm thinking of the BIND9 one, rather than Create/Delete 17:05:58 bind9 is ready for review. so is the other. 17:06:06 rjrjr_: Ok - So, what dependencies are you blocked on for starting to wire stuff up? 17:06:14 mdns, storage. 17:06:39 betsy's storage changes should be in, is there more still required there? 17:06:50 pool_id colum? 17:06:54 (They landed last night.. 17:07:07 Yeah, there’s some more, but the basic pool tables are there 17:07:07 as did vinod1's API additions for pools 17:07:10 ah, last night. that's good. 17:07:38 what about mdns? haven't been able to work on domain update without that one. 17:08:04 they should work as is right now... 17:08:14 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 mdns is ready to be reviewed and merged 17:08:16 just without separate namespaces 17:08:19 there are no calls for me to make at this point to mdns. 17:08:23 rjrjr_: for mdns: https://review.openstack.org/#/c/125868/ 17:08:28 yea, what mugsie said is my "for a single pool" 17:09:07 timsim: correct. 17:09:39 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 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 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 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 thoughts? 17:12:21 i agree. 17:12:23 If we can't avoid adding things that don't break the current stuff, we should probably do that. 17:12:26 yeah - I think with out a separate branch, we will have to 17:12:56 It should just be copy + paste what would be in central though 17:13:05 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 that sets me up for the update_status method in central. 17:14:54 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 traditional backend = powerdns? 17:15:29 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 rjrjr_: a shim one 17:16:21 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 that proxies a call from central to pool managers 17:16:58 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 without mdns, i can't work on update. 17:17:48 can we get vinod's work through today? 17:18:25 rjrjr_: Yep - mugsie / betsy / myself - can we get that reviewed + approved after this meet assuming no issues? 17:18:33 cool. 17:18:49 yeah, np 17:19:14 Any other pool's statues to bring up? 17:19:34 i have a question in the meeting, but we can wait. 17:19:57 Okay.. Since the agenda wasn't updated.. we'll move to 17:19:57 #topic Open Discussion 17:20:03 rjrjr_: you had a question? ;) 17:20:31 Pools - Should 'masters' join 'name-servers' and 'also-notify' in pool object? 17:20:47 ekarlso brought up this one the other day. 17:21:02 it seems like 'masters' is going to be a concept for every backend driver. 17:21:28 hummm... 17:21:41 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 as in the mDNS addresses to slave off? 17:21:46 rjrjr_: thinking... I seem to remember a reason it wasn't included 17:21:49 mugsie: correct. 17:21:59 technically, it is a backend option. 17:22:13 but, it will probably be used by every backend. 17:22:15 that, in theory, could be autogen'd in the future (as mDNS nodes come and cgo) 17:22:26 so, maybe. 17:22:48 but, there will be a requirement to be able to override it 17:22:53 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 well - reloading the config is something we can actually do 17:23:10 (as some people will limit "masters" to mDNS nodes in the same region 17:23:35 and - for "private" or "managed" pools, I'm thinking it's something we should avoid exposing. 17:23:48 send a "HUP" signal to pool manager service to reread config? 17:24:06 Kiall: in the object != exposing though 17:24:13 that is a common practice with other UNIX daemons. 17:24:14 rjrjr_: yea, we just need to wire HUP -> oslo.config's reload method, and make sure our code isn't broke ;) 17:24:53 that brings up a good point about the config changing out from under pool manager service, even on a restart... 17:24:57 and, it would allow for mDNS nodes to be added / removed w/o reloading a load of pool managers 17:25:10 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 That's true ^ 17:26:01 yup - hense the "override" bit - but for the 90% use case - it make things a lot easier 17:26:12 (for smaller installs) 17:26:37 I'm not sure I understand how it make it easier? 17:26:38 i think we leave 'masters' a backend option. let's get pools working. then add 'HUP' capability. 17:27:11 rjrjr_: ++ from me, doing that leaves the door open for a more through through plan later without too much baggage.. 17:27:21 thought through* 17:27:34 for v1, - leave it as is 17:27:38 I think I prefer that as well. 17:27:56 and .. the less code we have to write, the better ;) 17:28:10 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 i'll need to handle that in the periodic_sync. 17:28:39 and domain_update now that i'm thinking about it. 17:29:33 rjrjr_: yea .. there's likely a few places stuff like that may be needed :) 17:30:02 i'm pretty sure i know what needs to happen. feel like i'm living this code right now. 8^) 17:30:24 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 (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 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 might need to add a 'active' field to the table and activate those entries for servers that exist. 17:32:10 and deactivate the rest. 17:32:34 i'll give this some thought. but not right now. i'd like to get the 'straight path' working first. 17:33:04 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 rjrjr_: yup - I think the happy path is the one to walk initially 17:33:52 okay. 17:34:11 if all goes well this week, i'd like to accomplish happy path by Friday. 17:34:16 :) 17:34:46 Okay - Any other topics for the agenda today? 17:34:49 I’ve got something 17:35:07 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 I’m transferring to a different team within Rackspace, so next Friday, Nov. 7 will be my last day on Designate 17:35:32 betsy - 8^( 17:35:33 betsy: :( 17:35:47 betsy: ahh.. :( 17:35:47 I know. I’ll be sad, too 17:35:50 Where are you going? 17:36:02 To the VMWare team 17:36:11 Not on openstack 17:36:25 Betsy, thanks for all of your dedication and work on Designate. 17:36:36 sorry to hear this. hope you enjoy the new work! 17:36:39 jmcbride: +1 17:36:47 jmcbride: ++ 17:36:48 VMWare team? I didn't know RAX had one of those :) 17:36:55 yep 17:37:18 I’ll miss working with y’all 17:37:45 Good luck with Designate. 17:37:52 Thanks :) 17:37:58 ty 17:38:46 So - who's filling your spot on the RAX DNS team? :) 17:38:59 TBD at the moment. 17:39:17 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 can they work from another state? 8^) 17:39:36 jmcbride: we're competing for the same talent pool ;) 17:39:46 Are you hiring too? 17:40:06 Yep .. We're looking for another person for our team 17:40:17 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 hah, yep :) 17:40:49 Of course, sunny Texas is a great place to live ;) 17:41:08 Okay.. Any other topics before we crack a beer to wish betsy the best in the new team? ;) 17:41:13 mugsie, ekarlso, vinod1, are we going to do a dry run for the presentation tomorrow? 17:41:35 i am up for it 17:41:57 mugsie: did you get a chance to get the updated diagrams for pools? 17:42:09 vinod1: nope - but i will do it before i leave tonight 17:42:15 is tuesday still the day for design sessions? 17:42:27 and, yeah I am up for a run though - will ping you for times in a bit 17:42:53 Alright, cool. That's it from me :) 17:43:51 is tuesday still the day for design sessions in Paris? 17:44:12 Yep - No changes :( 17:44:32 k 17:45:34 Okay .. Let's call it so.. 17:45:40 yup 17:45:48 Thanks all, and good luck betsy :) 17:45:52 thx 17:45:59 We'll miss you betsy :) 17:46:11 #endmeeting