17:03:37 <vinod1> #startmeeting Designate
17:03:37 <openstack> Meeting started Wed Mar 26 17:03:37 2014 UTC and is due to finish in 60 minutes.  The chair is vinod1. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:40 <openstack> The meeting name has been set to 'designate'
17:03:47 <vinod1> okay who's here?
17:03:52 <esp> o/
17:04:13 <betsy> o/
17:04:16 <rjrjr_> here
17:04:19 <Sukhdev> rcurran: hey Rich, lets take it to #openstack-neutron
17:04:37 <rcurran> ok
17:04:45 <tsimmons> Here (sort of, on my phone)
17:04:56 <eankutse> here
17:05:12 <vinod1> #topic Review action items from last week
17:05:21 <vinod1> betsy to add dependency to records-table-redesign blueprint
17:06:06 <betsy> I did that
17:06:10 <vinod1> thanks betsy
17:06:12 <vinod1> vinod to come up with alternatives to recordsets
17:06:23 <vinod1> I have a proposal on the records vs recordsets at https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets
17:06:30 <vinod1> anybody had a chance to read up on that?
17:06:47 <vinod1> Betsy is coming up with another proposal now
17:06:50 <betsy> I read it. And I have a slightly different proposal but haven't had a chance to write it up yet
17:06:57 <eankutse> I did
17:07:06 <betsy> Can we postpone until next week?
17:07:08 <tsimmons> I read it.
17:07:16 <rjrjr_> i read it.  i'm still not understanding why we are concerned with this.  DNS servers seem to handle different TTLs for records in record sets.
17:07:44 <vinod1> The RFC states that this should be an error
17:08:03 <rjrjr_> which RFC?
17:08:15 <vinod1> http://tools.ietf.org/html/rfc2181 Section 5
17:08:16 <betsy> RFC 2181
17:08:52 <vinod1> since kiall and mugsie aren't around and they would have some input to this
17:08:56 <vinod1> we can move this to next week
17:09:05 <betsy> vinod1: agreed
17:09:23 <vinod1> #action all - add/review recordset proposals
17:09:38 <rjrjr_> okay.  i like the blueprint. 8^)  seems to handle the issue elegantly.
17:10:03 <vinod1> the next action item too from the last week was the same
17:10:04 <vinod1> Everyone to think about RRSets, reread the logs from the conversation, and come with alternatives and pro's con's
17:10:17 <vinod1> kiall to dig up ML archive entries around tenant id's in URLs
17:10:32 <betsy> I'll write up mine, which is a slight variation on Vinod's
17:10:39 <vinod1> kiall did mention this in the irc chat
17:11:12 <rjrjr_> that section talks about how the different TTLs are handled though. 8^(
17:12:19 <vinod1> section 5.2 states "Should a client receive a response containing RRs from an RRSet with
17:12:19 <vinod1> differing TTLs, it should treat this as an error."
17:12:23 <rjrjr_> it says it is an error, but goes on to say the client will use the lowest TTL value.
17:13:00 <rjrjr_> "client should treat the RRs for all purposes as if all TTLs in the    RRSet had been set to the value of the lowest TTL in the RRSet."
17:13:58 <vinod1> yes that is in case the client gets an incorrect response
17:14:08 <vinod1> But "In no case may a server send an RRSet with TTLs not all equal."
17:14:12 <rjrjr_> so why not handle it the same when a zone transfer is requested?  send them RRSet with the TTL of the lowest record.
17:14:27 <rjrjr_> them  = the
17:14:55 <vinod1> doing that would mean that the data that the user enter via the api is not the same as the data that is served out
17:15:07 <rjrjr_> what i'm suggesting is handle it the same way it is handled now in servers.  BIND doesn't prevent me from creating this situation.
17:15:51 <betsy> rjrjr_: I think that would be valid.
17:16:12 <betsy> But it could be confusing to the user if they didn't realize that only one ttl would be implemented
17:16:48 <rjrjr_> but they face that issue now in DNS.  do other servers point out when the admin is doing this?
17:17:07 <vinod1> i am not sure.
17:17:25 <vinod1> looks like we need more discussion around this next week
17:17:25 <betsy> AWS has the concept of RecordSets
17:17:39 <betsy> I tried to read up on their docs, but it was confusing as they don't use REST
17:17:52 <betsy> vinod1: yes
17:18:00 <vinod1> rjrjr_: could you add your thoughts to https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets
17:18:13 <vinod1> betsy could you add your proposal to the same page
17:18:13 <rjrjr_> sure.
17:18:19 <betsy> yes
17:18:30 <vinod1> that way others can review all the discussion around this in one place
17:18:47 <vinod1> #action rjrjr_ to update https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets with his thoughts
17:18:58 <vinod1> #action betsy update https://wiki.openstack.org/wiki/Designate/Blueprints/RecordSets with alternate proposal
17:19:08 <vinod1> moving on
17:19:11 <vinod1> #topic Capture the Notification Context in Designate Sink Blueprint
17:19:37 <vinod1> #link https://blueprints.launchpad.net/designate/+spec/sink-capture-notification-context
17:20:06 <rjrjr_> this one is simple.  the notification contains the context (user, tenant, etc.) and i thought it would be a good idea to capture it for use in the notification handlers.
17:20:47 <rjrjr_> i also submitted the code for review for this one.
17:21:51 <vinod1> i haven't had a chance to look at them
17:22:04 <vinod1> but at a glance this looks like a good idea
17:22:19 <vinod1> anyone else want to comment on this?
17:22:34 <eankutse> I'll take  a look at it
17:22:36 <rjrjr_> that way, the notification handler can do context related operations.  for example, i have a notification handler that relies on the context to select the forward domain that a record will be added to.
17:23:08 <betsy> I haven't looked at it yet. :(
17:23:36 <betsy> makes sense at first glance
17:23:44 <vinod1> #action all look at the blueprint and review sink-capture-notification-context
17:23:53 <vinod1> #topic Fixed IP PTR Record API Blueprint
17:24:06 <vinod1> #link https://blueprints.launchpad.net/designate/+spec/fixed-ip-ptrs
17:24:23 <rjrjr_> i also submitted the code for review for this one. 8^)
17:24:27 <betsy> So I had a question
17:24:55 <eankutse> rjrjr_: I will look at the code as well
17:24:55 <betsy> I don't know that much about fixed IP PTRS, but this is basically to track who owns the IP, correct?
17:25:19 <rjrjr_> fixed IPs are the private IPs for a VM.
17:25:38 <jmcbride> rjrjr_: so private, not public?
17:25:52 <rjrjr_> i believe so.  floating = public, fixed = private.
17:26:00 <betsy> Ah
17:26:07 <jmcbride> like a 10 or 192 or 172?
17:26:07 <rjrjr_> in our case, fixed = private and public.  we don't have floating.
17:26:22 <betsy> So does Nova keep track of who owns an IP for a VM?
17:26:50 <rjrjr_> Neutron does via ports.  a port has a subnet, a subnet has a IP.
17:26:51 <betsy> Just asking because we currently don't track this info in our DNS system. It's tracked outside of that
17:27:11 <betsy> Does it track that back to the tenant_id or project_id?
17:27:31 <rjrjr_> tenant ID
17:27:50 <rjrjr_> Nova has the VM information which contains the IP address.
17:28:00 <rjrjr_> Port has the IP address.
17:28:18 <jmcbride> So you are saying Designate should own the tenant to IP address relationship?
17:28:29 <rjrjr_> in the code, i look up the ports for a tenant, get the IP address, to validate the request is proper.
17:29:34 <rjrjr_> this code is basically finishing the work that was started with floating IP PTR API.
17:29:40 <vinod1> who owns ports - is it neutron?
17:29:49 <rjrjr_> Neutron
17:30:05 <vinod1> is there a 1 to 1 relationship between ports and ip addresses?
17:30:20 <rjrjr_> no, it is more complicated than that.
17:30:38 <rjrjr_> a port can have more than one IP.
17:31:04 <rjrjr_> think network ports.  a server can have an interface which has multiple IPs.  ditto for routers, etc.
17:31:24 <rjrjr_> Neutron is capturing that port information.
17:31:43 <rjrjr_> capturing = modelling.
17:31:48 <vinod1> so when you say "i look up the ports for a tenant", does designate contact neutron to get the ports for a tenant?
17:32:38 <rjrjr_> yes, i look up the ports and IP addresses.  that way, i'm validating the request for the tenant wanting to add the record to the reverse zone.
17:33:08 <rjrjr_> in designate reverse zones are "shared" among tenants, hence the need for the floating IP PTR and fixed IP PTR API.
17:34:34 <rjrjr_> so, in the code, i query neutron for a list of ports for a tenant.  the floating IP code does the same for floating IPs.  it just happens that floating IPs are modelled in Neutron.  the closest we have for fixed IPs is ports/subnets/IPs.
17:35:22 <vinod1> so the decision to do fixed or floating controlled by a config setting?
17:35:42 <rjrjr_> no, API calls.  /reverse/floatingips versus /reverse/fixedips
17:36:16 <rjrjr_> in Nova, not sure, but you can do just floating, just fixed, or both.
17:37:11 <rjrjr_> i'm guessing we'll need to carry this discussion to next week. 8^)
17:37:22 <vinod1> if 192.168.1.0 is a fixedip
17:37:32 <vinod1> can we create a floatingip to it?
17:37:56 <rjrjr_> no.
17:38:29 <jmcbride> rjrjr_: we were going to get together after this meeting to clarify some details on our end.  Can we get back to you?
17:38:36 <vinod1> so how would this be prevented - when designate queries neutron for floatingips?
17:38:41 <rjrjr_> yes.
17:38:48 <rjrjr_> vinod1, correct.
17:38:58 <vinod1> ok moving on
17:39:03 <vinod1> #topic Is Designate handling Region properly (Floating IP and Fixed IP PTR API)?
17:39:25 <rjrjr_> man, without kiall/mugsy, not sure if we can discuss this.
17:39:36 <rjrjr_> http://kimizhang.wordpress.com/2013/08/26/openstack-zoning-regionavailability-zonehost-aggregate/
17:39:41 <betsy> rjrjr_: agreed
17:39:46 <rjrjr_> where does Designate fall into this picture?
17:39:49 <vinod1> #link http://kimizhang.wordpress.com/2013/08/26/openstack-zoning-regionavailability-zonehost-aggregate/
17:40:09 <rjrjr_> is it like Keystone and Horizon?
17:40:36 <rjrjr_> and spans regions?  or is it like Glance, Cinder, Swift, etc. and region specific?
17:41:10 <vinod1> i would think that designate would need to span regions
17:41:12 <betsy> Seems like DNS would have to span regions
17:41:26 <betsy> But I've never seen that chart before
17:41:41 <rjrjr_> this question came out of the API for floating IP PTR/fixed IP PTR API.
17:42:16 <rjrjr_> the API has /reverse/floatingips/<region>:<floating-ip-id>
17:42:37 <rjrjr_> the resource identifier is strange <region>:<floating-ip-id>
17:43:17 <rjrjr_> if Designate spans regions, should we fix the API to /region/<region>/reverse/floatingips/<floating-ip-id> or something like that?
17:43:58 <msisk> I can see the need for supporting Designate for both fixed and floating.
17:44:22 <rjrjr_> i've seen this /region/<region> in another OpenStack API.  i'll have to look and see which one.
17:45:51 <msisk> Here at Rackspace we'll need Designate to work globally across all our DCs, but I can see other folks wanting each region/DC to have their own designate setup. That certianly makes PTR support easier.
17:47:03 <rjrjr_> hmmm... so Designate may need to participate in a region?
17:47:38 <betsy> Seems like we need Kiall and Mugsie to weigh in
17:47:45 <rjrjr_> agreed.
17:47:46 <betsy> They've probably already thought about this
17:47:56 <betsy> Let's table it for next week
17:48:09 <betsy> Is that okay with you, rjrjr?
17:48:24 <rjrjr_> yes.
17:49:00 <vinod1> #action discuss Is Designate handling Region properly (Floating IP and Fixed IP PTR API)?
17:49:10 <vinod1> #topic Mini-DNS: Can we rename it to something less provoking, like ZoneTransfer Module?
17:49:51 <vinod1> If minidns would be the master server, would calling it ZoneTransfer indicate that?
17:49:52 <eankutse> we already decided on a name, right?
17:49:59 <jmcbride> The only reason I proposed this is it seems to make people worry that we are over-engineering things.
17:50:28 <jmcbride> A common response is, "What! You are writing your own name server??"
17:50:47 <rjrjr_> i believe kiall said it does more than zone transfers though.  for example, it will need to serve SOA records as part of the zone transfer negotiation.
17:51:00 <jmcbride> true.
17:51:02 <rjrjr_> so, zone transfer is just a subset of what it will be doing.
17:51:15 <betsy> That's why it's real name is mdns, pronounced MaDNesS :)
17:51:16 <jmcbride> and I know we envision it may do much more.
17:52:03 <jmcbride> OK, well, seems like mdns is not a bad approach, I think we can close this topic.
17:52:12 <jmcbride> since mdns is the name.
17:52:23 <jmcbride> the "name"
17:52:34 <vinod1> #topic Pecan issues (bugs 1288830 and 1288834)
17:52:49 <vinod1> #link https://bugs.launchpad.net/designate/+bug/1288830
17:52:55 <vinod1> #link https://bugs.launchpad.net/designate/+bug/1288834
17:53:38 <vinod1> The primary concern here was that these issues arose because of the way pecan handles these urls
17:53:47 <vinod1> I looked at other (incubated) openstack projects. Only Ceilometer appears to use Pecan.
17:53:55 <vinod1> The question now is Should we follow up with Pecan about this issues?
17:54:05 <vinod1> are there any volunteers for this?
17:54:39 <vinod1> the other question was Should the rest of openstack community be informed about these issues?
17:55:06 <betsy> I think that's a good idea. We should send out an email to the dev email list with the concern
17:55:17 <betsy> See what the rest of the community thinks
17:56:04 <betsy> I'll send out the email
17:56:20 <vinod1> #action betsy to send out email to dev list about pecan issues
17:56:25 <vinod1> thanks betsy
17:56:42 <vinod1> any more things that need discussion
17:56:49 <vinod1> now is your time
17:56:53 <rjrjr_> i have a concern.
17:56:56 <betsy> We've only got 4 min
17:57:16 <rjrjr_> we seem to be bottlenecked when not everyone is on this meeting.  is that being addressed?
17:57:36 <rjrjr_> nobody's fault.  just seems dysfunctional.
17:57:48 <betsy> Hasn't happened that often, but you're right
17:58:06 <eankutse> right - not that often
17:58:08 <betsy> rjrjr_: True
17:58:23 <eankutse> but it sure is better if all attend
17:58:27 <rjrjr_> overall, our progress seems slow at times though. 8^(
17:58:35 <jmcbride> given kiall's work, it is definitely difficult to make a lot of progress if he's not around.
17:58:45 <vinod1> i think once we have more expertise of designate spread around, this issue will not be there
17:58:47 <betsy> I think that will change over time, though
17:58:59 <rjrjr_> okay
17:59:14 <betsy> But you bring up a good point
17:59:23 <vinod1> #endmeeting