17:02:50 <mugsie> #startmeeting designate
17:02:51 <openstack> Meeting started Wed Oct 16 17:02:50 2013 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:54 <openstack> The meeting name has been set to 'designate'
17:03:24 <mugsie> #topic Review action items from last week
17:03:34 <mugsie> or in this case, 3 weeks ago
17:03:41 <mugsie> MySQL BIND9 Docs (CaptTofu)
17:04:03 <mugsie> any update CaptTofu ?
17:04:44 <mugsie> Search out any logging guidelines from other OpenStack projects (vinodmr)
17:05:01 <vinodmr> I haven't yet gotten around to it
17:05:18 <mugsie> #action Search out any logging guidelines from other OpenStack projects (vinodmr)
17:05:29 <mugsie> cool, will leave it there for the next one
17:05:50 <mugsie> we dont have kiall, so I will move his two on a week
17:05:59 <mugsie> #action Review HP's DEBUG level logs, increase anything generally useful to INFO or above (kiall)
17:06:07 <mugsie> #action Update APIv2 Spec with proposed RRset/Record changes (kiall)
17:06:24 <mugsie> anything else from previous meeting that needs to be gone over?
17:06:28 <mugsie> meetings*
17:06:44 <tsimmons> I don't think so.
17:07:13 <simonmcc> I don't think so
17:07:26 <mugsie> vinodmr put in a review on my pools change, did anyone else have anything on it?
17:07:53 <eankutse> I looked at the code.
17:07:59 <eankutse> Looks like direction is good
17:08:07 <eankutse> Phase 1 is almost there
17:08:20 <eankutse> but a few more code to go?
17:08:21 <vinodmr> One thing I wanted to check again is - can the last pool be deleted?
17:08:34 <mugsie> i dont think so.
17:08:55 <mugsie> currently there is no create / delete allowed in phase one
17:09:15 <mugsie> but when we have multiple pools, I am not sure if we should allow it to be deleted
17:09:45 <mugsie> it is not much of a change if it is needed functionality though
17:09:52 <vinodmr> I think so too
17:10:03 <vinodmr> i.e. the last pool should not be deleted
17:10:24 <vinodmr> Currently the placeholder code does not check for the number of pools remaining - so wanted to be sure
17:10:47 <mugsie> yea, currently it just raises an execption
17:10:54 <eankutse> How about requiring a minimum number of servers in a pool ?
17:11:03 <tsimmons> Perhaps 2?
17:11:43 <mugsie> ok
17:11:57 <mugsie> that is not currently there,but it can be added
17:12:04 <betsy> Would that be part of Phase 2, also?
17:12:06 <mugsie> in v1, as far as i know we allow 0
17:12:08 <mugsie> yes
17:12:28 <mugsie> betsy: ^
17:12:33 <eankutse> But I added code recently to not allow last server to be deleted
17:12:49 <betsy> I thought the general design and the direction you're heading looks good
17:13:08 <mugsie> eankutse: i may be thinking of old code :)
17:13:21 <eankutse> yea :-)
17:13:23 <mugsie> cool. Any more feedback , please feel free to ping me whenever
17:13:36 <mugsie> I am on all day (UTC hours)
17:13:54 <mugsie> #topic Zone Import / Export Endpoint (artom - added by mugsie)
17:14:11 <mugsie> #link https://review.openstack.org/#/c/49555/
17:14:22 <mugsie> artom: you want to explain?
17:14:53 <artom> We're not sure whether to have a separate /zonefile endpoint, or use the existing /zone endpoint
17:15:12 <tsimmons> I prefer the existing /zone endpoint.
17:15:30 <mugsie> tsimmons: using the content types?
17:15:31 <artom> In the latter case, the client would specify it wants/it's posting a zonefile with Accept/Content-type headers
17:16:25 <eankutse> I would prefer a new endpoint
17:16:29 <artom> My only qualm about using /zones is that it's not the same information being outputted.
17:16:44 <eankutse> that's right
17:17:02 <eankutse> and the body is not the same either
17:17:17 <tsimmons> Ehhh, doing /zone/id/export or something works for me. That's less complicated.
17:17:43 <eankutse> I see what you mean
17:17:50 <eankutse> tsimmons
17:18:05 <artom> I can't seem to say anything?
17:18:09 <artom> Oh, we're back.
17:18:17 <artom> I was saying: /zone/zone-id with no Accept header would get the Designate dictionary
17:18:25 <artom> With created, updated, etc, but not the records.
17:18:57 <artom> /zone/zone-id with an Accept: text/dns header gets the zonefile, with records.
17:19:27 <eankutse> Artom: would you update a blueprint with the pros/cons for evaluation?
17:19:29 <mugsie> my personal preference is for the content type
17:19:38 <mugsie> eankutse: thats a good idea
17:19:42 <vinodmr> How would the import endpoint look like?
17:20:03 <vinodmr> Ideally I would want the import/export endpoints to be symmetrical
17:20:42 <mugsie> #action Update domain-import-export blueprint with pro's and con's of content types (artom)
17:21:20 <artom> Just to make sure I understand, you mean update https://blueprints.launchpad.net/designate/+spec/domain-import-export ?
17:21:22 <mugsie> vinodmr: this is why I like the idea of content type, as you could then POST to the /zones end point with a content type of text/dns
17:21:32 <mugsie> artom: yeap
17:21:40 <mugsie> #link https://blueprints.launchpad.net/designate/+spec/domain-import-export
17:22:56 <mugsie> anything else on this?
17:23:01 <tsimmons> I like that ^
17:23:20 <mugsie> tsimmons: which?
17:23:26 <betsy> I agree with mugsie - I like the content type included
17:23:34 <vinodmr> The import endpoint would be /zones and the export endpoint would be /zones/zoneid right?
17:23:36 <betsy> But nice to have the pros and cons documented so we can see
17:24:05 <artom> Are there "hard" pros and cons either way?
17:24:47 <artom> Ie, I don't see either choice imposing limitations in the future.
17:25:03 <artom> It's more about deciding what's the better design, abstractly.
17:25:11 <mugsie> but it does set the direction of how we model the API in the futre
17:25:14 <tsimmons> The only real con I can see of this way is that inexperienced users might have some troubles with it as opposed to an explicit endpoint.
17:25:30 <mugsie> tsimmons: true
17:25:46 <mugsie> we would need to build it into the designate-client tool to help them
17:26:04 <tsimmons> Does it really set a precedent though? It's kind of an edge case type of feature, no?
17:26:15 * artom wonders if other Openstack projects could guide us...
17:26:51 <tsimmons> That's a good point, if there's something similar in other OpenStack projects, that's probably the way we ought to go.
17:27:22 <mugsie> will we leave it get details together for next week?
17:27:39 <artom> Sounds good, I'll look around and update the bp.
17:27:55 <mugsie> cool.
17:28:06 <mugsie> #topic Open discussion
17:28:30 <vinodmr> I am hesitant about having the same endpoint doing multiple things depending on the content type.
17:29:46 <artom> Yeah, it's the sort of stuff I imagine putting in a big bold note in docs because it's not obvious...
17:29:46 <vinodmr> Nothing else from me
17:30:00 <mugsie> anyone else?
17:30:14 <tsimmons> I had a quick question about the current state of server pools/pool manager
17:30:27 <mugsie> yup
17:31:06 <tsimmons> I was hoping to pull down the code and mess about a little bit, what kind of experience could I expect if I were to go at making it work?
17:31:33 <tsimmons> can i start a pool manager service or start messing around with plugins or anything? Or are we not quite there yet?
17:31:45 <mugsie> no, you can start a pool manager service fine
17:32:06 <mugsie> you need to update your running config, and run the migration
17:32:13 <eankutse> is this v2?
17:32:18 <mugsie> yeah
17:32:25 <eankutse> cool:-)
17:32:31 <tsimmons> Sweet, I'll give it a shot.
17:32:41 <mugsie> if you have any problems give me a shout
17:32:46 <tsimmons> Thanks!
17:32:59 <eankutse> mugsie: so would you consider phase 1 done?
17:33:05 <mugsie> no
17:33:21 <eankutse> what's left for phase 1?
17:33:42 <mugsie> i need to finish tests, and with out a way to fail over if a pool manager service dies, it is not prodcution ready
17:33:58 <eankutse> k.
17:34:28 <mugsie> but the fail over will most likely be part of phase 2, so phase one and two might end up merging at the same time
17:34:48 <eankutse> k. What again is the difference between the pool manager and the scheduler?
17:35:25 <mugsie> a pool mananger just deals with its servers, and updates them with info as it get it from central
17:35:41 <mugsie> the schedualer will assign zones to a pool
17:36:02 <mugsie> when they are created
17:36:11 <eankutse> And there is one pool manager per pool, right?
17:36:16 <mugsie> yeap
17:36:47 <tsimmons> So the scheduler would run between central and the pool managers and delegate the zone creation to one of the pools when it gets a message from central?
17:37:19 <mugsie> it would be a plugin to central, and would tell central where to send the creation
17:37:38 <mugsie> like how nova assigns VMs to hosts currently
17:38:13 <mugsie> i think we will look at their process as an example for ours
17:38:15 <vinodmr> What is the need for multiple pool managers instead of having one pool manager manage several pools
17:38:50 <mugsie> to keep the system simple
17:39:21 <mugsie> it also allows for easier pool addition / removal
17:40:01 <mugsie> and as pools may be physically dispersed, it reduces issues for looking of resources
17:40:05 <mugsie> locking*
17:40:17 <betsy> So there's a 1-1 correlation between pool managers and pools?
17:40:27 <betsy> Or, is a pool manager the same as a pool?
17:40:28 <mugsie> betsy: yes
17:40:37 <mugsie> a pool manager will manage a pool
17:41:05 <mugsie> typically the master server, and then monitor the slaves, so it can report back whne the change is live
17:41:21 <mugsie> but that could depend on what backend is in use
17:41:39 <tsimmons> A master pool manager?
17:42:07 <tsimmons> No, the pool manager runs on the master dns server.
17:42:19 <mugsie> it could run on the master dns server for a pool
17:42:40 <mugsie> but not all pools might have master servers (Power DNS with a mysql backend etc)
17:42:48 <tsimmons> Right
17:43:26 <mugsie> the idea is that central can put a change out, and then get notified whan that change has completed, with out knowledge of the backend behind it
17:44:25 <tsimmons> Right, it just has to have knowledge of the existing pools, to know where to send the message, or at least the scheduler does.
17:44:39 <mugsie> yeap
17:44:57 * kiall made it.. just about. kinda.
17:45:09 <eankutse> :-)
17:45:11 <vinodmr> Would it be better to have one pool manager for each type of backend
17:45:13 <tsimmons> Lateness will not be tolerated.
17:45:21 <tsimmons> ;)
17:45:24 <artom> Neither will latency.
17:45:26 <mugsie> well, the scedualer will run once, at whick point the pool-id is recorded in central
17:45:55 <mugsie> vinodmr: the idea is that the current backend s will just plug into the pool-manager
17:47:37 <mugsie> anything else on this?
17:47:48 <tsimmons> Not from me
17:48:06 <mugsie> cool, as always, please feel free to add comments / questions to the wiki page for the pools
17:48:23 <mugsie> #link https://wiki.openstack.org/wiki/Designate/Server_Pools
17:48:32 <eankutse> the wiki is the same as the blueprint right?
17:48:46 <mugsie> yeah, thats the link from the blueprint
17:49:00 <mugsie> any other open deiscussion?
17:49:17 <artom> While we're all still here (and kiall joined), I had a look around other Openstack projects, and while I couldn't find import/export in APIs, I did find use of the Accept header.
17:49:30 <artom> It's to specify response *format*
17:49:35 <artom> Not content.
17:50:48 <eankutse> yep, that would be Content-Type
17:50:49 <kiall> They are somewhat linked though .. For example, GET /images/12345 with Accept: image/jpeg vs
17:51:01 <kiall> GET /images/12345 with Accept: application/json
17:51:45 <kiall> One might be the binary data, one might be the metadata associated with the image.. Different content, and representations, for the same resource (the image)
17:52:16 <tsimmons> So that would probably work for export, but not import, would import have to use Content-Type
17:52:17 <tsimmons> ?
17:52:41 <kiall> Yea - Import would be sending a Content-Type, export sending an Accept
17:53:22 <eankutse> and both would have value text/dns
17:53:32 <mugsie> yeap
17:53:54 <kiall> Yea - Accept and Content-Type are linked, sending an Accept is asking for a specific Content-Type in the response
17:54:11 <kiall> and sending a Content-Type is describing the format of the request body
17:54:21 <tsimmons> Yeah, I've seen that before.
17:55:07 <kiall> Yea - Its one of those parts of HTTP thats often underused! But makes lost of sense with REST
17:56:28 <mugsie> cool. Well artom is going to update the bp with this info, so we can look at later on in the week?
17:56:44 <mugsie> if people are online, we shouldnt need to wait a full week
17:56:51 <betsy> true
17:57:02 <mugsie> cool.
17:57:05 <artom> Yeah, we can stick with that original plan :)
17:57:10 <mugsie> Any other business?
17:57:18 <mugsie> we are nearly at time
17:57:18 <eankutse> not for me
17:57:52 <tsimmons> I'm good.
17:57:58 <kiall> #link https://wiki.openstack.org/wiki/Governance/NewProjects
17:58:12 <kiall> Not to be discussed today .. Just a few people have been asking about the process
17:58:15 <kiall> Noticed that wiki page today
17:58:15 <mugsie> cool.
17:58:36 <mugsie> thanks guys for coming
17:58:45 <mugsie> #endmeeeting
17:58:50 <kiall> Thanks mugsie for taking point :) and apologies for being late
17:58:54 <artom> Where are we at now in that flowchart?
17:58:54 <mugsie> #endmeeeting designate
17:59:11 <kiall> mugsie: re-auth to nickserv? ;)
17:59:20 <kiall> artom: External phase
17:59:53 <mugsie> #endmeeting