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