17:00:13 #startmeeting Designate 17:00:14 Meeting started Wed Apr 2 17:00:13 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:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:17 The meeting name has been set to 'designate' 17:00:34 Heya 17:00:37 Who's about? 17:00:42 here 17:00:45 hello 17:00:46 o/ 17:00:54 O/ 17:00:58 here 17:01:26 #topic Review action items from last week 17:01:49 First up was betsy update https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets with alternate proposal 17:02:22 rjrjr_ betsy and me put up some proposals on that wiki page 17:02:59 Yep, I saw some updates today - but haven't had a chance to review.. Looks like they went up a couple of hours ago 17:03:13 that would be me. *^( 17:03:19 and Betsy 17:03:37 Want to give it a quick detail on the proposed change? 17:03:57 Okay my proposal is to essentially just deal with records 17:04:15 and create and modify time we check that the ttl values are consistent 17:04:41 to change all the ttl values at the same time we use a different parameter called modify-rrset=true 17:05:02 rjrjr_ proposal is to allow any ttl values to be set 17:05:24 minidns would then just return the lowest ttl value for the recordset - similar to bind 17:06:28 betsy's proposal is do deal with records but have multiple data 17:06:35 back - got disconnected 17:06:39 ok. The main point of all of these proposals is to get rid of the /recordsets//records stuff is it? 17:06:43 So - Looking at this example https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets#Create_a_Record_2 17:06:58 I like it, it's very close to the original v2 design 17:07:13 But, it uses /zones/ID/records rather than /zones/ID/recordsets 17:07:13 not just the api but deal only with one and not both 17:07:39 I think - hiding records, showing recordsets, and having the records as a list within the recordset makes lots of sense and maps to the specs pretty well 17:07:42 yes - that is Betsy's proposal 17:08:10 While at the same time reducing the length of the URLs, and allowing TTLs etc to be handled gracefully 17:09:00 kiall not sure if saw my earlier comments about rjrjr_'s proposal and my proposal 17:09:12 when you got disconnected 17:09:35 We actually had that in the original spec - But concurrency and transitional updates caused us issues - I believe we're in better shape today to handle both 17:09:44 vinod1: ah .. I've only see https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets#Create_a_Record_2 17:09:52 the "Records/RecordSets Redesign Option 2" section 17:10:10 12:03 17:10:10 vinod1 17:10:10 Okay my proposal is to essentially just deal with records 17:10:10 12:04 17:10:10 vinod1 17:10:11 and create and modify time we check that the ttl values are consistent 17:10:11 12:04 17:10:12 vinod1 17:10:12 to change all the ttl values at the same time we use a different parameter called modify-rrset=true 17:10:13 12:05 17:10:13 vinod1 17:10:14 rjrjr_ proposal is to allow any ttl values to be set 17:10:14 12:05 17:10:15 shivharis left the room (quit: Quit: http://www.kiwiirc.com/ - A hand crafted IRC client). 17:10:16 12:05 17:10:16 vinod1 17:10:41 vinod1 17:10:41 Okay my proposal is to essentially just deal with records 17:10:41 12:04 17:10:42 vinod1 17:10:42 and create and modify time we check that the ttl values are consistent 17:10:42 12:04 17:10:42 vinod1 17:10:43 to change all the ttl values at the same time we use a different parameter called modify-rrset=true 17:11:08 vinod1: so, is there an advantage to that over having the resource be something like this? http://paste.openstack.org/show/74881/ 17:11:30 (nabbed from https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets#Create_a_Record_2 ) 17:11:59 not able to get to paste yet 17:12:12 It's the example from https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets#Create_a_Record_2 17:12:32 I copied it to a paste to be easier to see exactly what part of of the page I was referencing 17:12:36 that looks more complicated to create and modify and we need records and data tables 17:12:37 I prefer keeping records as a list within record sets. The only issue we have is the ocncurency issue 17:13:06 (ie. if 2 people ad 2 records at teh same time, the later on will remove the previous one) 17:13:16 later one* 17:13:22 mugsie: I think we can handle concurrency the same way we handle concurrent updates to a zone/record.. latest one "wins" 17:14:00 ok, if that allowed, I would go for #2 17:14:30 with doing checks at create/modify time, the user would just need to deal with the concept of records 17:14:30 vinod1: more complicated meaning the JSON is bigger etc? 17:14:32 i don't like the idea of storing incosistant data about a record 17:14:46 inconsistant* 17:14:48 for modify we now have to have a put and a patch 17:15:18 i don't like the idea of storing incosistant data about a record - inconsistent data is not stored at any point 17:15:26 could we not use json+patch for the additions? 17:15:38 we do checks at create/modify time to prevent inconsistent data 17:15:42 vinod1: so, would there be inconsistent data? 17:15:57 with proposal #1 (my proposal) there would not 17:16:08 with rjrjr_;s proposal yes 17:16:10 e.g. if I post http://paste.openstack.org/show/74881/ (same paste again) to /zones/ID/recordsets - it would create the record and 2x records 17:16:14 vinod1: for example if some one added a record with a ttl of 3600, then added a record with a ttl of 4000, we would still store the 3600 in the db, but not use it 17:17:09 we would have to, for when the user removes the record with the ttl of 4000, they would want the record remaining to have the originally set 3600 17:17:19 set ttl of 3600* 17:18:02 mugsie which proposal are you referring to? 17:18:36 #1 17:18:56 or would we discard the 3600 when the 4000 ttl came in? 17:19:18 So, personally I'd be in favour of an Option #3 - Remove Records, Keep RecordSets. The API would look pretty close to "Redesign_Option_2" in the wiki. 17:19:20 sorry, the other way around 17:19:44 with #1, when you try to add the 2nd ttl with a value of 4000, an error would result as it is inconsistent with the value of 3600 17:20:22 vinod1: For me, that adds "weirdness" with updating a record (or rrset's) TTL 17:20:38 Needing an extra "update-rrset=true" when there is more than 1 record feels wrong 17:20:41 kiall with option #3 what would happen if you create another recordset with the same name, type and data but a different ttl 17:21:03 vinod1: it would be rejected as a duplicate RRSet 17:21:49 No 2 RRSet's can have the same (Class, Name, Type) - By definition, if they do, they are the same recordset. (We only do class IN - so that can be ignored in our API) 17:22:15 BTW - Who's was "Redesign_Option_2" on the wiki? 17:22:29 betsy 17:22:51 betsy isn't around today 17:23:08 rjrjr_: and the option above that was yours rjrjr_? (Trying to see who's proposal is who's ;) 17:23:22 handle TTLs implicitly. 17:23:31 like BIND handles them for recordsets. 17:24:00 K - Think I know who's is who's now ;) 17:24:31 so now that we discussed about these options should we decide on which one to go with? 17:24:45 or do it next week? 17:25:00 So - TTLs implicitly being reduced to the smallest TTL in the RRSet seems surprising - a user who does `dig example.com @nameserver` will see something different to what our API shows 17:25:28 yes that is true 17:25:28 it's how BIND handles the problem. i figured it should be considered. 17:25:48 it's also in the spec on how clients should handle the issue. 17:26:01 vinod1: agreed. I'm personally in favor of Redesign Option 2 - but keeping the resource called RecordSets rather than Records (since that's really what the resource is returning) 17:26:41 i'm in favor of eliminating the concept of recordsets personally. 17:26:45 rjrjr_: yea, bind handles it that way, and the spec says that clients should compensate for "broken" servers by picking the smallest 17:27:22 rjrjr_: so, what's your thinking behind that? 17:27:33 e.g. Your opinion on Redesign Option 2 17:28:28 i'm not a proponent, but i'll go with what the team decides. i was hoping to simplify down to records, not to recordsets. 17:29:08 rjrjr_: I guess, I'm trying to understand what about RRsets you dislike? Other than the long URLs, which Option 2 fixes IMO :) 17:29:33 (Also - We should probably move on and come back to this next week, as vinod1 suggested, 30 mins in already) 17:30:03 recordsets is not necessarily a concept that is in the forefront for an administrator. they work with records. 17:30:18 i agree with rjrjr_ 17:30:43 and looking at the rfc there seems to be only one mention of the term recordsets 17:30:57 or at least not as common as records 17:31:29 we can possibly add the reasoning to our proposals and decide which one we want to go with next week 17:31:34 Looking at other DNS APIs, there's plenty of precedent for the RRSet term (Route53, Dyn, JClouds using that for DNS, etc) 17:32:14 yes, but we could make ours simpler to use. 8^) 17:32:19 Okay - Lets put this back on the agenda for next week, and settle it once and for all then. Agreed? 17:32:26 yes. 17:32:26 #agreed 17:32:28 Also - If we're planning a major change to the V2 API structure, I think we're going to have to leave it as experimental in icehouse. (Probably for the best anyway) 17:33:34 #action kiall to add RRSets back on the agenda for next week. Assume it's going to take 30-40 mins to reach a decision. 17:33:45 :-) 17:34:04 Okay! 17:34:07 #topic Atanta Workshop 17:34:12 https://etherpad.openstack.org/p/DesignateAtalantaWorkshop 17:34:18 #link https://etherpad.openstack.org/p/DesignateAtalantaWorkshop 17:34:27 we also need to plan some time to talk about this 17:34:37 so #link http://doodle.com/pb4aqd59gxg489u5 17:35:00 if people want to fill in availiblity that would be great 17:35:24 mugsie: you forgot to say what you wanted on that etherpad, or what you wanted to discuss on a call ;) 17:35:52 remind me, 2 or 3 presentations in Atlanta? 17:35:55 basically we need idea for what to show, and hpw we are going to do it 17:35:58 2 accepted 17:35:59 2 17:36:09 rjrjr_: yours and mine, and the workshop 17:36:47 so if ideas can get filled in the etherpad, when we get some time to sit down, (google hangouts ok?) and plan, we have a list to work off 17:36:48 Both on the Thursday - 11:00 for the Talk, 13:30 for the workshop 17:37:25 any questions? 17:37:29 http://openstacksummitmay2014atlanta.sched.org/ has the schedule 17:37:29 i think the Designate client, parts of the API (using curl), and maybe a quick notification handler as an appetizer for the 2nd session. 17:37:55 ah, workshop is after the presentation. 17:38:12 Yea, presentation should hopefully get people interested in the workshop :) 17:38:16 yup, which means that we can show stuff in the workshop that we demoed in the talk 17:38:41 Okay - Anyway, Anyone with ideas etc - Please put them in as much detail as possible on https://etherpad.openstack.org/p/DesignateAtalantaWorkshop 17:38:59 and fill in the doodle, if you want to be on the hangout planning 17:39:01 and - we'll find a time to talk in-person via http://doodle.com/pb4aqd59gxg489u5 - so fill in your availability 17:39:29 With 20 mins left and 1 of 6 items covered.. Moving on ;) 17:39:31 #topic Capture the Notification Context in Designate Sink Blueprint 17:39:38 #link https://blueprints.launchpad.net/designate/+spec/sink-capture-notification-context 17:39:51 #link https://review.openstack.org/#/c/82667/ 17:40:12 rjrjr_: looks perfect bar the 1 thing graham spotted IMO 17:40:17 I reviewed 17:40:20 looked good 17:40:27 yup, I like it 17:40:35 I am curious what you plan on using the info for though? 17:41:07 i have a notification handler that selects the domain based on the tenant. 17:41:20 i'm assigning one forward domain to each tenant. 17:41:52 cool 17:41:58 the change to the network_api/base.py was because the catalog could be an empty list. 17:42:07 (if it is the change I am thinking of.) 17:42:15 Oh cool, we have a item at HP to do something similar. It's on our JIRA for sometime in the next 2 weeks :) 17:42:46 rjrjr_: the addition was the "list_ports" method 17:42:51 (The out of place addition) 17:43:00 https://review.openstack.org/#/c/82667/1/designate/network_api/base.py 17:43:07 Looks like it should have been part of the Fixed IPs review? 17:43:35 yes. i'll fix that. this happened because i have two WIPs submitted. 17:43:48 good catch. 8^) 17:44:23 Cool :) If we fix that up, I don't see any reason not to merge it 17:45:00 i'll fix it today. 17:45:01 Anything else / questions / comments etc before we move on? :) 17:45:26 #topic Fixed IP PTR Record API Blueprint 17:45:32 #link https://blueprints.launchpad.net/designate/+spec/fixed-ip-ptrs 17:45:37 #link https://review.openstack.org/#/c/81580/ 17:46:40 rjrjr_: Q on this one. How your handling regions in the API? Same as FloatingIP? 17:46:46 (I had a chance to code-review, but not test or properly understand how it's handling regions) 17:47:52 kiall, yes. 17:48:53 rjrjr_: cool - anyone else had time to review / have questions / comments? 17:49:11 not yet 17:49:17 i was thinking if you thought this was okay with IPs in the API, we could fix floating ips to also use IPs instead of floating_ip_id. 17:49:33 that was my largest concern. 17:49:56 From memory - fixed IPs don't get an ID, while floating IPs do? 17:50:01 yup 17:50:06 I think the choice should follow the neutron API 17:50:20 if fetching a floating IP in the neutron API uses the ID, so should we. 17:50:30 if fetching a fixed IP in the neutron API uses the IP address, so should we. 17:50:35 since we're dealing with the same resource 17:50:47 and Neutron is where the identifier for that resource is defined 17:50:56 i was trying to loosely couple us to the Neutron API. 17:51:45 rjrjr_: cool, I'll test it out tomorrow and see if it works the way I'm thinking it does, but it looks good. 17:52:15 It has made the need to split central into multiple classes even more pressing though ;) 17:52:18 i also have unit tests for it. i can submit those if this is code we are interested in. 17:52:40 It's officially at the "too damn big" stage IMO. 17:53:07 rjrjr_: yea, unit tests often help with reviewing and API testing etc - makes it easier to understand the intent 17:53:43 kiall, fetching a fixed IP does not use IP address. list ports shows port ID, subnet ID, IP address. 17:54:49 i simply grab the list of ports for a tenant and lookup (search the dict) for the IP address. if it is there, the IP address is valid. 17:54:54 Humm, yea, that feels a little odd compared to floating ips (Not wrong, just the two are different) 17:55:29 is there a nuetron equivielent of a 'floatingip-list' for fixed ips? 17:55:30 I think it's the right choice though - as neutron exposes fixed/floating IPs differently 17:55:38 hence my thinking of changing floating IPs to do the same thing. again, loose coupling was my reason for using IP address. 17:55:52 we could do the same with floating IPs. 17:55:56 mugsie: No, I don't believe there is unless you count subnet-show and expand the CIDR 17:56:43 well, think about it. i'll submit the unit tests today as well. 17:56:45 ah, ok 17:56:47 rjrjr_: so, normally I'd argue for our API being internally consistent. But - for the things calling out to neutron, I think we have to be consistent with neutron. 17:57:07 rjrjr_: cool - I'll test tomorrow - hopefully others can too. 17:57:19 yup, I will add it to my list 17:57:30 my concern is a user just knowing Designate and having to find the floating_ip_id in Neutron which they might not be familiar with. 17:57:58 rjrjr_: we have a 'list; method in designate that will give them the ids 17:58:16 and the right url to make changes (in the self reference) 17:58:25 rjrjr_: I think thats OK, since we list them if the user needs, and Nova's FIP APIs are slowly on the way out 17:58:35 Anyway - 2 mins 17:58:37 #topic Mini-DNS: Can we rename it to something less provoking, like ZoneTransfer Module? 17:58:44 #action kiall to put Mini-DNS: Can we rename it to something less provoking, like ZoneTransfer Module? on the agenda for next week 17:58:56 #topic Pecan issues (bugs 1288830 and 1288834). 17:58:58 i think we put that to bed last week. 17:59:11 Not sure who added that, but absolutely, we should file upstream bugs on them 17:59:25 i added that 17:59:29 Pecan is actually a StackForge project now - So it should be easy to find the right people. 17:59:57 Okay - Times up! 17:59:58 #link https://bugs.launchpad.net/pecan 18:00:00 Thanks all 18:00:07 #endmeeting