17:59:30 #startmeeting DNSaaS 17:59:31 Meeting started Wed Dec 19 17:59:30 2012 UTC. The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:34 The meeting name has been set to 'dnsaas' 17:59:47 Okay.. Hiya! 17:59:57 Agenda: http://wiki.openstack.org/Meetings/DNSaaS 18:00:08 only me and you here or ? 18:00:26 * andrewbogott is lurking :) 18:00:27 CaptTofu's around, JC is away (but I've got some input from him via email) 18:00:44 and simon is about.. but not sure he's realized it's in here just yet ;) 18:00:49 :p 18:01:34 So - Obviously, last weeks meeting never happened. I was with HP in Seattle for the week, and the TZ difference screwed me over! 18:01:41 greets 18:01:44 Apologies! 18:01:53 I forgive you :) 18:01:57 it's all my fault. 18:02:02 hah :p 18:02:05 CaptTofu, you should have remembered :P 18:02:08 it was the doughnuts 18:02:19 haha 18:02:29 Yea - lets blame the doughnuts... moving on :) 18:02:46 So the agenda has 2 items on it today.. 18:03:01 First up... 18:03:13 #topic Why I haven't released a (kinda) g1 yet 18:03:33 still not out ? 18:03:38 slowy! 18:03:43 So - I've discovered that we don't quite have all the necessary pieces in place to do a release! 18:03:48 #link https://review.openstack.org/#/c/17756/ 18:04:14 Without this (or something similar) we're left without the ability to release 18:04:41 hehe 18:05:03 So.. I've literally just had a chat with mordred / jeblair about this.. 18:05:11 and it boiled down to: 18:05:11 Kiall: i think mordred is running behind, but the general idea was maybe we should prototype with moniker how we want to do releases and tarballs for all the core projects 18:05:20 Kiall: mordred's going to write up a plan on his plane flight, so maybe we'll have details then. 18:05:26 drivers == agent, correct? 18:05:35 No - thats a launchpad group name 18:05:46 ah. 18:05:50 Basically - people with permission to hit the big red button ;) 18:05:58 ok. 18:06:55 So .. I'm happy to hold odd and work with jeblair / mordred to get a better system in place for everyone.. Assuming it's sometime soon! I'll find out more when I can 18:06:59 hold off* 18:07:25 Any questions? :) 18:08:03 Guess not... 18:08:07 #topic Reverse DNS 18:08:12 #link http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/ReverseDNS-123456999.html 18:08:34 yeh 18:08:45 So - We have 2 decisions to make re reverse DNS.. 18:09:08 question, do we do with handlers for reverse like with forward records, create A + PTR ? 18:09:13 1) Should we limit reverse DNS records to pre-defined range(s) of IPs, or allow people to create PTR's for any IP space they wish 18:10:00 2) If the answer to #1 is pre-defined only, what should the API look like? i.e. should the PTR be record be tied to the resource it's actually allocated to. 18:10:50 I had a quick chat with jcmartin last night about this, and I believe he's in favour of a restricted set of ranges, and following the RS API (linked above) 18:11:25 I'm personally in favour of restricting the PTR's to pre-defined ranges, and something kinda similar to the RS API 18:11:38 thoughts? 18:12:07 zykes-, sorry - missed that message 18:12:09 maybe quantum subnet data comes in here or ? 18:12:31 yes - we should, be defaulting records to a sane value as we get notifications from quantum/nova-network 18:12:56 But the end user should be able to change that default if they wish 18:13:10 :) 18:14:00 I'm in favour of allowing that access via something like http://moniker.api.bla.com/rdns/compute/InstanceUUID 18:14:27 how does RS dns stuff look for this? 18:14:30 which is similar to, but not exactly the same as the RS API. (I'm still trying to figure out exactly why they use a full URI rather than just the UUID) 18:14:32 http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/ReverseDNS-123456999.html 18:15:09 The RS API looks like this http://moniker.api.bla.com/rdns/compute/http://nova.api.bla.com/servers/$InstanceUUID 18:15:19 (with some urlencoding thrown in) 18:15:28 hmmm 18:16:07 The end result is something like this: http://dns.api.bla.com/rdns/compute/http%3A%2F%2Fcompute.api.bla.com%2Fservers%2F$InstanceUUID 18:16:11 why is the service passed in ? 18:16:21 Why is it useful to restrict the range? It's just the difference between getting invald vs. not found for a given query, right? 18:16:22 as in the service api 18:16:25 ehm, service url 18:17:02 andrewbogott, yes/no.. we can't allow any random user to create a PTR for 1.2.3.4, since that could be allocated to another tenant 18:17:13 a thing can be if you restrict having duplicate PTR's that if someone goes duplicate ip's you're screwed 18:17:22 Oh, you're talking about creating not querying of courseā€¦ nm, dumb question. 18:17:56 andrewbogott, yea.. this is from the REST API point of view 18:18:34 so - the service-url thing bugs me because it's ugly :) 18:18:43 it is indeed 18:18:54 I'm still trying to understand exactly why they chose this route 18:18:57 and do you really need to do like /compute ? 18:19:18 Kiall: shouldn't we restrict creation of ptr's to existing ip's in say quantum / some other source? 18:19:28 I understand that part - it allows us to pick the appropriate python-*client to make a call with 18:19:59 zykes-, yea.. so an end user can only create a PTR record if they have the IP allocated to one of their instances/load balancers/databases/etc 18:20:45 yeh 18:20:55 So.. Can anyone see a reason why RS chose to use a full URL, rather than simply the UUID? 18:21:01 noop 18:21:16 Humm - Actually, I think I just realized why. 18:21:29 What if you have multiple compute regions? 18:21:44 The compute/LB/etc API endpoint would be different 18:22:04 hmm 18:22:17 and ? 18:22:22 isn't DNS / Keystone global ? 18:22:24 DNS, being the odd one out when it comes to multi-region stuff, won't just be dealing with in-region resources 18:23:48 So - with the keystone catalog, we can from a service type and region name, obtain the URL 18:24:04 yeah 18:24:09 Maybe we use http://moniker.api.bla.com/rdns/compute/RegionOne/$InstanceUUID 18:24:18 (or something similar) 18:24:28 how does the Nova url's look like ? 18:24:34 do they use instance regions in the url ? 18:25:03 No, regions are entirely separate stand alone installs with a shared keystone (and moniker) 18:25:25 yeh 18:25:44 So http://RegionOne/servers and http://RegionTwo/servers will return different results.. 18:25:51 can't we just put the service + region within the json ? 18:26:27 Maybe for create and update requests, but fetch requests (i.e. a HTTP GET) don't have a entity-body, so no JSON. 18:26:40 k 18:27:31 I'm inclined to go with something like this 18:27:32 http://moniker.api.bla.com/rdns/RegionOne/compute/$InstanceUUID 18:27:43 http://moniker.api.bla.com/rdns/RegionOne/loadbalancer/$BalancerUUID 18:27:43 etc 18:28:29 myeh 18:28:38 was that a "meh" or "yeh" ;) 18:28:39 but should service vs region be in which order? 18:28:57 I think I prefer region first 18:29:11 what does other projects use ? 18:29:20 let's try not to differ too much from others... 18:29:56 None of the other projects need to handle another projects resources over multiple regions 18:30:00 i.e. this is a first 18:30:18 quantum ? 18:31:09 I'd need to double check since I don't use it.. But quantum would live inside a region and not handle other regions 18:31:23 The only cross-region project right now is keystone 18:32:04 yeah, but KS doesn't really care I think for things that is "in" the resource except the svc catalog 18:32:43 Exactly - and it has no need to know about servers etc, so it doesn't provide a precedent for how this should be handled 18:33:01 sorry if i'm a bit "back and forth" 18:33:05 working on Pulp atn :) 18:33:18 so, there is no precedence to follow :/ 18:33:34 guess we'll be a first :) 18:34:08 Assuming nobody shouts at me for it, I think http://moniker.api.bla.com/rdns/RegionOne/compute/$InstanceUUID will work and not be totally hideous 18:34:54 Okay.. No shouts.. 18:35:26 #action kiall to implement RDNS over the holidays using "http://moniker.api.bla.com/rdns/RegionOne/compute/$InstanceUUID" as the API endpoint 18:35:32 #topic Open discussion 18:35:58 So .. zykes- did you see this? https://review.openstack.org/#/c/18377/ 18:36:28 yeh, was planning on doing it post christmas 18:36:28 i.e. don't do any work on the rootwrap ticket you assigned to yourself until that lands :) 18:37:23 ;) 18:37:32 I am working too many angles for openstack alone :p 18:37:56 Okay - So unless anyone else has anything, we'll call it and day and pick this up in 2 weeks after the break? 18:38:08 :) 18:38:09 yeh 18:38:31 (I know CaptTofu and simonmcc are in another meeting right now, so probably have Q's but haven't had time to read the logs ;)) 18:39:01 sorry! 18:39:13 Okay .. Next meeting is the 2nd of January 18:00 UTC :) 18:39:16 2nd? 18:39:17 jasus. 18:39:22 i say 3 weeks 18:39:24 rather :p 18:39:25 can I take that statement back! 18:40:27 Okay.. Let's say 3 weeks, or the 9th of Jan. and I'm sure we'll have something impromptu in #openstack-dns between now and then 18:41:13 #endmeeting