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