17:27:57 <mugsie> #startmeeting designate
17:27:58 <openstack> Meeting started Wed Nov  6 17:27:57 2013 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:27:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:28:01 <openstack> The meeting name has been set to 'designate'
17:28:31 <mugsie> #topic artom's packaging fork
17:28:47 <mugsie> whos here?
17:29:01 <mugsie> I am going to ut this very short, as everyone with action items is gone
17:29:17 <artom> Wait, didn't I have something from last time?
17:29:55 <artom> Did those actually.
17:30:22 <artom> So packaging fork is just https://github.com/enovance/debian-designate
17:30:44 <betsy> here
17:30:46 <mugsie> #link https://github.com/enovance/debian-designate
17:30:53 <artom> Allows me to build packages from the master branch, thus including API v2 and domain import/export
17:31:13 <artom> We need for our prototype here, so I put it on github.
17:32:04 <mugsie> cool
17:32:13 <eankutse1> here
17:32:13 <mugsie> so how do yourun it?
17:32:15 <artom> I need to figure out where to put a short howto for using it - I can't put that in a README as it messes up the packaging.
17:32:30 <mugsie> does git-notes work?
17:32:43 <artom> git-nodes?
17:32:51 <artom> Maybe the github wiki?
17:32:56 <betsy> artom: Or I see a github wiki
17:33:13 <mugsie> yeah, github wiki could be handy
17:33:15 <betsy> Yeah. I bet that'd work
17:34:06 <artom> I guess that can be my action item for this week then, add a quick explanation to https://github.com/enovance/debian-designate's wiki
17:34:44 <mugsie> #action add a quick explanation to https://github.com/enovance/debian-designate's wiki  (artom)
17:35:16 <artom> Unless people have questions, that's all for that.
17:35:54 <mugsie> nothing from me - apart from thanks!
17:36:09 <betsy> Yeah. Nice job
17:36:29 <artom> Bah, Kiall did all the work, I forked and adjusted.
17:36:33 <artom> But thanks :)
17:37:34 <mugsie> #topic Open Discussion
17:37:42 <betsy> I heard Kiall's talk was well attended.
17:37:47 <betsy> Have you heard from him?
17:38:00 <mugsie> no, I missed him with the time overlap
17:38:25 <mugsie> but he said it went OK apparently
17:38:34 <betsy> Some of our guys that were there said there was a lot of interest in Designate
17:38:56 <mugsie> yeah, it has been mentioned in 2 -3 other talks
17:38:56 <betsy> Hopefully that bodes will for incubation
17:39:11 <mugsie> fingers crossed
17:39:28 <eankutse1> Mugsie: Server Pools - How are we preventing the creation of differently named Sever Pools that have servers that overlap with servers of other pools or have exactly the same servers in their pools? Or Is that a non-issue?
17:39:57 <mugsie> ah, yes. I went to reply to you but you had gone offline
17:40:08 <eankutse1> sorry :-)
17:40:15 <mugsie> The idea is that servers are part of one pool only
17:40:29 <eankutse1> k
17:40:39 <mugsie> so that overlap should not be an issue
17:41:06 <eankutse1> You mean even if the overlap happens, it would not cause a problem?
17:41:36 <mugsie> no, there shouldnt be an over lap as servers can only be in one pool
17:41:59 <eankutse1> Ah, so we do check for and enforce that today?
17:42:03 <eankutse1> Or \
17:42:09 <mugsie> not at the moment
17:42:11 <eankutse1> is this part of phase2/3
17:42:14 <eankutse1> ?
17:42:20 <mugsie> this would be 2/3 alright
17:42:30 <eankutse1> cool
17:42:33 <mugsie> We need to get phase one to have redundecy first
17:43:13 <mugsie> any other topics?
17:43:18 <eankutse1> More questions
17:43:24 <eankutse1> on Server pools
17:43:26 <mugsie> yup
17:43:51 <artom> I would note previous question/answer in the wiki.
17:44:12 <mugsie> artom: good idea
17:44:18 <eankutse1> What do you think about the ff assumptions on Server Pools/Pool Managers - it's ok if you'd like me to put these in the wiki:
17:44:32 <mugsie> #action update wiki with questions / answers from IRC meeting (mugsie)
17:44:42 <eankutse1> 1.	The Server Pool that is managed by a given Pool Manager is first created (by an admin) before the Pool Manager is started up
17:44:42 <eankutse1> 2.	The Pool Manager is up and running in the backend when the Update/Delete Server operation is requested
17:44:42 <eankutse1> 3.	Create/Update/Delete of a Server Pool (and the servers that belong to the pool) are "Management"-type operations that are performed on infrequent (and possibly one-time) basis. The Creation might be done ahead of time before the API is open for use. Update and Deletion of Server Pools might happen preferably during a scheduled downtime.
17:45:13 <eankutse1> :-) that's a lot
17:45:17 <eankutse1> I know
17:45:49 <mugsie> they seem sound assumptions
17:46:07 <mugsie> 3: will start out as managment style operations
17:46:27 <eankutse1> k
17:46:34 <mugsie> but could change (for private DNS in a VPC for example)
17:46:57 <mugsie> where we may use Heat to boot a pool, and do a pool create
17:47:13 <eankutse1> Ahh :-)
17:47:59 <mugsie> i know it is something we are interested in, and i can see others wanting this ability
17:48:17 <eankutse1> yes
17:48:35 <eankutse1> Do you have time for more, Mugsie?
17:48:51 <mugsie> yeah, shoot
17:48:54 <eankutse1> k
17:49:40 <eankutse1> What do you think the action of the Pool Manager will be when 1) a Server Pool is Created, 2) Server Pool is Updated 3) Server Pool is Deleted?
17:51:05 <mugsie> 1: start listenign on APMQ for messages
17:51:26 <mugsie> 2: perform required update (changing SOA records etc)
17:51:35 <mugsie> 3: humm... not sure....
17:51:58 <mugsie> Stop listening to the APMQ stream anyway
17:52:17 <eankutse1> Sounds good!
17:52:20 <betsy> mugsie: And on 1: Update the SOA records, also. Right?
17:52:20 <eankutse1> But on #2
17:52:21 <artom> Given the 1 manager per pool paradigm we seem to choosing, I would say just... disappear.
17:52:39 <artom> Not sure what happens to the records though.
17:52:54 <betsy> artom: Good point. On a delete, the Pool Manager would also be deleted
17:53:09 <mugsie> yeah, that makes sense
17:53:36 <mugsie> records, not sure - we might need to force it so a pool has no zones before deletion
17:53:58 <artom> That seems wise :)
17:54:55 <eankutse1> Good answers - jives with my thinking
17:55:04 <eankutse1> so far
17:55:13 <eankutse1> for Phase2/3
17:56:16 <artom> Couple of questions from me if we have time?
17:56:35 <mugsie> yeah
17:57:09 <artom> Scheduler is phase 2 or 3?
17:57:30 <mugsie> 2
17:57:30 <artom> The sequence diagram in phase 2 mentions "send operation to correct pool manager"
17:57:31 <eankutse1> 3, I think
17:57:39 <mugsie> sorry, yeap 3
17:57:57 <mugsie> that will be a shell to send it to the only pool in phase 2
17:58:04 <mugsie> shell function*
17:58:05 <artom> Ah, gotcha.
17:58:30 <mugsie> it will support multiple pools, but it will require mesing in the DB
17:58:45 <mugsie> (to set them up and adding zones to it)
17:58:53 <artom> So scheduler stub in phase 2, full scheduler in phase 3 is a concise way of putting it?
17:59:35 <mugsie> well, there will be no schedualer at all in phase 2
17:59:53 <mugsie> the each zone will get an extra colum, with pool-id
18:00:05 <mugsie> that is what the schedualr will populate
18:00:25 <mugsie> after that central will deal with sending the messages to the right queue
18:00:37 <artom> Ah, right, missed the "lookup pool_id for domain" part.
18:00:37 <betsy> Will the scheduler also "own" the Pool Managers?
18:00:37 <mugsie> (based on the value in that column)
18:00:41 <mugsie> no
18:00:47 <mugsie> betsy: no,
18:01:00 <betsy> So owned by Central?
18:01:04 <mugsie> yeah
18:01:18 <mugsie> similar to have the nova-schedualer works
18:01:39 <mugsie> each compute node is owned by nova, but instances are assigned by nova-schedualer
18:02:08 <mugsie> it knows about each pool, and decides where to put each zone created
18:02:14 <betsy> But the Nova scheduler doesn't track them as being in a specific pool, does it?
18:02:41 <mugsie> no, it tracks them as being on a partcualr compute node
18:03:08 <artom> So on zone creation the scheduler writes the pool-id in the DB, and then never touches it again (ignoring moves between pools, if that's even possible/planned).
18:03:10 <mugsie> for that example a compute node  is simalir to a pool
18:03:18 <mugsie> artom: yup
18:03:36 <mugsie> and we will need to do migrations.., just havent though how that will work yet
18:03:59 <mugsie> I need time to get some actual dev done :)
18:04:05 <betsy> And the pool scheduler has no part in the creation of new servers
18:04:18 <mugsie> nope, just of zones
18:04:29 <mugsie> we know what pool we want to a server to
18:04:58 <betsy> True
18:06:19 <betsy> So, is there any part of that you want help on?
18:06:29 <betsy> Writing the code, that is
18:06:47 <betsy> I'm not sure what parts you already have in flight
18:07:05 <mugsie> not quite yet. I think I have it under control. I want to get phase one done, and then we can reassess it i think
18:07:21 <betsy> sounds good
18:07:35 <mugsie> i have loads in flight - but not much of it is in a state to push yet ;)
18:07:57 <mugsie> we should be less crazy over then next few weeks, so hopefully we should see some progress
18:08:14 <eankutse1> so you think ;-)
18:08:20 <eankutse1> less crazy :-)
18:08:24 <mugsie> yeah... that is true
18:08:25 <eankutse1> what is that?
18:08:45 <eankutse1> Mugsie: not sure if I already asked for this but at some point it would be helpful to have more details on the table that is going to be introduced to support Async Response.
18:09:02 <mugsie> you did ask for it, and I promptly forgot.
18:09:04 <mugsie> sorry
18:09:11 <mugsie> Will look at it this week
18:09:23 <eankutse1> k. Thx
18:09:59 <mugsie> I wont be here next week, (i am at a conference), so if anyone has any questions, lash them here / wiki / email me over the next week, and I will get them when i can
18:10:11 <artom> Last one from me.
18:10:17 <mugsie> cool
18:10:23 <artom> https://blueprints.launchpad.net/designate/+spec/multi-backend is needed for server pools with more than 1 server, no?
18:10:43 <mugsie> well, with more than one server type
18:11:15 <mugsie> if it is PowerDNS it can be ok with multiple servers of the one DB
18:11:35 <artom> Ah, right, they all MySQL-replicate from the main one.
18:11:53 <mugsie> bind9 can have 1 server as the master, and then unlimted slaves, wiht no issues
18:12:05 <mugsie> (or needing the multi-backend)
18:12:12 <artom> But then it's not really a pool from Designate's point of view - all Designate knows about is the master server in the pool.
18:12:38 <tsimmons> A pool can have just one server in it though.
18:13:10 <mugsie> yup, but the backend could be resonsible for checking all the slave nodes have the correct reord before telling central that the operation is complete
18:13:17 <artom> Well, yes, but the way mugsie is explaining it, until multi-backend gets implemented, *all* pools will have 1 server in them.
18:13:39 <artom> mugsie, ah, gotcha.
18:13:46 <artom> (the slave nodes part)
18:13:57 <tsimmons> Unless theres two PowerDNS servers that aren't master slave?
18:16:03 <mugsie> artom: designate will know about the slaves, and insert the correct information into the SOA etc
18:16:48 <artom> So the backends will need quite a bit of work before pools is fully ready...
18:17:01 <mugsie> yup
18:17:21 <mugsie> the plan is to try and abstract as much custom backend code to them as possible
18:17:55 <artom> Gotcha.
18:17:56 <mugsie> so that we have a clean implementation of a data flow from API -> pool
18:18:05 <mugsie> cool.
18:18:09 <mugsie> anything else?
18:18:21 <artom> Nyet from I, comrade.
18:18:28 <mugsie> cool
18:18:31 <eankutse1> I am done
18:18:33 <vinod1> I have one question
18:18:36 <mugsie> cool
18:20:02 <vinod1> I need to test this - but wanted to check if when we create a zone under a SLD like co.uk and another tenant now wants to create another zone under co.uk
18:20:08 <vinod1> will there be any issue
18:20:20 <mugsie> em...
18:20:23 <mugsie> i am not sure
18:20:39 <mugsie> I woulld need to test it myself
18:20:50 <mugsie> I would thnk that .co.uk should be ok
18:21:01 <vinod1> Will the parent domain/sub domain checks flag this incorrectly?
18:21:04 <mugsie> (its generally accepted as a tld)
18:21:25 <mugsie> maybe... i think we would have caught that though
18:23:29 <artom> Try it an see ;)
18:23:43 <mugsie> yeah. Failing that kiall is your best bet
18:23:58 <vinod1> Thanks I wanted to be sure that we correctly handle SLDs and TLDs that work as TLDs
18:24:16 <mugsie> but we do have this in production, and I am sure we would have been shouted at about this if it wasnt the case
18:24:39 <mugsie> any other questions?
18:24:43 <artom> You can't outsource testing to angry users ;)
18:25:17 <mugsie> nope, that never ends well...
18:25:17 <vinod1> nothing from me
18:25:27 <mugsie> cool
18:25:44 <mugsie> #endmeeting