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