16:59:33 #startmeeting Designate 16:59:34 Meeting started Wed Sep 4 16:59:33 2013 UTC and is due to finish in 60 minutes. The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:59:37 The meeting name has been set to 'designate' 16:59:51 Heya 16:59:54 Who's about? :) 17:00:36 o/ 17:00:44 o/ 17:01:21 Okay - so a few of us :) simonmcc / capttofu are AFK at the moment, not sure if they'll be joining us today 17:01:36 Let's get started so.. 17:01:37 #topic API v2.0 Progress 17:02:27 Progress here has stalled - We've been dealing with lots of internal stuff over the last week or so ... Much more than usual! 17:02:50 * CaptTofu o 17:03:01 I've not had enough hours in the day to get the records side of the V2 API done (or even started) 17:03:11 :-) 17:03:12 But - It's on my list for this week. 17:03:23 mugsie has been working on some V2 related stuff, which we can get to in a bit! 17:03:51 Anyway - Just wanted to give a quick update on that... 17:03:56 #topic Async State Transitions 17:04:00 thx 17:04:21 So - This is what mugsie has been working on since he started with HP last week, and it ties in with both the API v2 and Async-Backends 17:04:41 mugsie: want to give an intro to the current plan/progress? 17:04:57 I am currently working on the design of the async backends 17:05:16 I should have some docs up on a wiki page fairly soon, but i will give a quick overview 17:05:41 The idea is, that when a back end operation happens, the back end is given a ticket 17:06:02 and when the operation is complete we send the ticket back to central, and mark it as complete in the designate DB 17:06:27 ineresting... 17:06:37 now there is some flow issues, an trying to make sure we dont edn up with inconsistant data 17:06:46 but that is the genral gist 17:07:05 now, these tickets are completely internal to designate 17:07:23 so theuser just sees a 202 Accepted responce 17:07:42 mugsie: so what are examples of backend ops? 17:07:50 and when they query designate, it will show pending until it is active,at which piint the status will change 17:08:10 creation / update / delete of domains / record 17:08:23 records* 17:08:34 Any operation which changes something you query on port 53 basically ;) 17:08:43 Is any of this on any of the blueprints on launcpad? 17:08:51 What is the response that the user sees with a 202 - how do they get the link to query for status? 17:09:18 betsy: not yet, but should be by beginning of next week 17:09:28 cool 17:09:28 maybe then end of this one 17:09:38 vinodmr: so, the "ticket" is more for intenal tracking of the operation within designate.. and end-user will never see the ticket ID etc, only "status = PENDING" vs "status = ACTIVE" in the API 17:10:17 but will the user receive a link to check status? 17:10:20 vinodmr: the link will be the "self" item in the responce 17:10:32 and when they get that link it will have a status field 17:10:41 ok 17:10:49 I am trying to understand why we need a separate ticket id. 17:10:57 https://review.openstack.org/#/c/44730/ is the beginning work of this 17:11:05 Can we not use the self link to communicate the status? 17:11:24 vinodmr: this is for when a backend is not doing the operations instantly 17:12:04 vinodmr: well, the status would be included alongside the self link, and re-querying the self link would return the full resource, again, including the status field 17:12:22 Similar to how while booting a Nova instance, it will go to "BUILD", then eventually "ACTIVE" 17:12:57 i meant can we use the domain/record it itself to communicate status between the backend and central? 17:13:08 *id 17:14:11 at any given time, can there be multiple operations outstanding for the same domain/record id? 17:14:22 vinodmr: this allows for multiple operations to be used 17:14:33 so say creating a record and domain 17:14:46 so both need to be done in the right order 17:15:14 but isn't there a domain id and a record id already? 17:15:44 yeap, but we could have multiple operations happening on a single item 17:16:00 so the domain should not go to active untillall have completed 17:16:01 So, the "ticket" helps tie things like - 5x create records in a row, and only when all tickets for the domain are complete, should it move back to "ACTIVE" 17:16:26 even though those 5 records themselves would go to ACTIVE as soon as they are pushed out 17:17:59 Anyway! Graham is still working through the docs for how this ties together, hopefully things will be clearer once they get pushed to the wiki/a blueprint 17:18:34 yeah, we can talk about it when the docs go up 17:18:54 looking forward to the docs 17:19:14 mugsie: thx 17:19:23 one last question - so in this e.g. would the user first send a create request for a domain and then a create request for 5 records or would it be one request with a create for a domain and 5 records? 17:19:24 #action mugsie to finish+publish docs on async backends/tickets/etc 17:20:07 vinodmr: so, with the v2 API as is today, create domain can't contain any RecordSets 17:20:27 But.. They could create the 5 records in 1 create RRSet request, or maybe 2 in one RRSet, and the rest in another etc.. 17:21:22 But - even if it could, all the RRSets/Records in a zone should be live before the zone swiches back to ACTIVE... 17:22:50 Okay :) Well - Things should get clearer once the docs go out.. We can discuss again once they go up in #openstack-dns :) 17:22:58 Thanks kiall and mugsie, I will wait for the docs for further clarification and I will look at the changeset that mugsie pointed to 17:23:03 #topic "Verifing" Domain Ownership 17:23:37 #topic "Verifing" Domain Ownership 17:23:39 Ugh 17:23:41 Okay - so justinsb suggested this, and I 17:23:49 wanted to get your opinions on it 17:24:43 Does RAX have any requirement for verifying ownership of a domain before accepting/serving a domain? 17:24:50 #topic "Verifing" Domain Ownership 17:24:53 There we go :) 17:25:28 heh 17:25:40 so this is a larger DNS hosting issue - how does it affect Designate? 17:26:03 how big/common of a problem is this? 17:26:05 other than providing tooling to support a decision process or correction process? 17:26:30 vinodmr: well, I don't personally see it as a major issue.. To me, it's something for support teams to handle. 17:26:44 In a multi tenant environment, we think it is important that if a customer creates "microsoft.com", another customer can not create "hijack.microsft.com" 17:27:22 If Yahoo! registers google.com in one of our services, and Google decides that one of us is the best for DNS, we have a problem... The Q is, should be be providing for automation of this conflict resolution? 17:27:56 jmcbride: absolutely - we prevent that scenario today 17:28:09 how do you prevent it? 17:28:19 But.. I think we have a bug that if someone reghisters bla.example.com, another tenant can nab example.com .. 17:28:29 conflict resolution involves somebody making a decision & then deleting the 'illegal zones' 17:28:33 I've yet to validate if that's actually an issue though 17:28:59 from what i saw in the chat yesterday, this looks to be very involved and the best thing at this point would be to resolve this issues through support 17:29:05 simonmcc: for some of them they ask you to create a cname record, then test if its there 17:29:36 create a came for a zone you're trying to get hosted? or create the came in the parent? 17:29:37 vinodmr: I tend to agree, there are ways of making it work 100% automated.. But I'm not sure there something we could "force" on everyone.. 17:29:42 yeah or a txt record 17:29:58 #link http://blog.cloudflare.com/whats-the-story-behind-the-names-of-cloudflares-name-servers 17:30:09 simonmcc: in the parent zone, unless you use an inbuilt registrar 17:30:19 ^ that was a really interesting approach, but 100% somthing we can't bake into designate as a requirement 17:30:40 betsy: well, the issue with a TXT record is brand new domains don't have existing DNS :) 17:30:56 Anyway - It sounds like you guys agree, this is out of scope 17:32:03 agreed, out of scope 17:32:16 #agreed 17:32:25 Yep. Big can of worms. ;) 17:32:44 agreed 17:33:02 Okay - Well, lets call that out of scope and move on so :) 17:33:02 agreed, the yahoo/google scenario is out of scope. However, we should consider the super domain scenario you described (bla.example.com and example.com). 17:33:42 jmcbride: yea, I believe that is already covered - at least in one direction - I'll validate after this and file a bug if necessary 17:33:58 #topic Migration tools 17:34:06 jmcbride: you added this item :) 17:34:57 yes, I was curious if any tools exist today that allow a customer to easily grab zone files and migrate to Designate. 17:35:43 Ah - So.. At the moment, no. I have a proof on concept zone import/export 17:35:46 #link https://blueprints.launchpad.net/designate/+spec/domain-import-export 17:35:57 But - It's full of holes! 17:36:30 The blueprint ^ would cover feeling in, and exporting out BIND style config files.. 17:36:34 feeding* 17:37:05 (It's open for the taking BTW :P) 17:37:41 I'd also love to be able to handle inbound AXFR's, allowing us to create "slave" zones that pull from a customers existing DNS servers 17:38:26 has anybody gone through cloud flare's process? do they just pick off www/mail/blog etc from your domain? 17:39:24 The CF "sucking existing records" process is awful IMO - it's grabbing only the well known names.. The interesting part is their conflict resolution/verification of ownership :) 17:39:43 inbound axfr would be a very nice feature, but I'm unsure how much use it would get? depends on your customer base, I suppose the bigger the customer, with more sophisticated users, it's more likely 17:40:11 It does probably attempt an AXFR against your DNS servers, but any well configured DNS server will reject that when it comes from $random IP :) 17:40:50 yeah, I haven't used AXFR in a long time -- it's blocked everywhere nowadays. 17:41:01 Sounds like AXFR should be a separate blueprint 17:41:14 jmcbride: yup 17:41:16 simonmcc: yea, I see it as 2 things.. 1) A way to "import" and them, flip the "slave" -> "master" switch on the zone.. and 2) to allow for the bigger guys who might want to use HP DNS, or RAX DNS as a "DNS CDN" .. simply taking advantage of our POPs 17:41:47 yep 17:41:53 jmcbride: yea.. It's not happening anytime soon - unless you guys have the resources to handle it :) 17:42:06 agreed 17:42:15 I've barely got bast the "That would be a useful thing" thoughts on it :) 17:42:26 I'm only mentioning it, as it semi-relates to importing of data :) 17:42:53 The other import option, is something in the client, rather than an API endpoint, that reads and creates the zone. 17:44:10 Anyway - The short answer is, no, we have no easy 1 step import at the moment.. But we do have a BP for 1 method :) 17:44:42 Cool, that would be useful. 17:44:47 Okay moving on :) 17:44:50 #topic Open Discussion 17:45:07 i.e. the "Anyone got anything else?" part of the meeting :) 17:45:53 I think eankutse had some Q's earlier? 17:45:54 BTW, my proposal to do a presentation at http://openstack.onales.com on Designate has been accepted. ;) 17:46:12 congrats msisk! 17:46:17 Excellent! 17:46:42 Might need you folks to help me out once I get working on the slide deck. Guess I should start soon. ;) 17:46:58 Sure - Anytime :) 17:47:36 kiall: Thanks! 17:48:25 So .. Last call? :) 17:48:26 Nothing from me 17:49:21 nothing from me 17:49:28 ditto 17:49:38 same for me 17:49:43 Okay - Thanks all :) 17:49:56 :-) 17:50:06 thanks! 17:50:12 Will talk during the week, once mugsie gets the docs up 17:50:18 o/ 17:50:19 probably before the next meet? 17:50:24 Good stuff 17:50:25 yeah 17:50:33 #endmeeting