16:59:33 <kiall> #startmeeting Designate 16:59:34 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:59:37 <openstack> The meeting name has been set to 'designate' 16:59:51 <kiall> Heya 16:59:54 <kiall> Who's about? :) 17:00:36 <mugsie> o/ 17:00:44 <betsy> o/ 17:01:21 <kiall> 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 <kiall> Let's get started so.. 17:01:37 <kiall> #topic API v2.0 Progress 17:02:27 <kiall> 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 <kiall> 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 <eankutse> :-) 17:03:12 <kiall> But - It's on my list for this week. 17:03:23 <kiall> mugsie has been working on some V2 related stuff, which we can get to in a bit! 17:03:51 <kiall> Anyway - Just wanted to give a quick update on that... 17:03:56 <kiall> #topic Async State Transitions 17:04:00 <eankutse> thx 17:04:21 <kiall> 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 <kiall> mugsie: want to give an intro to the current plan/progress? 17:04:57 <mugsie> I am currently working on the design of the async backends 17:05:16 <mugsie> I should have some docs up on a wiki page fairly soon, but i will give a quick overview 17:05:41 <mugsie> The idea is, that when a back end operation happens, the back end is given a ticket 17:06:02 <mugsie> 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 <eankutse> ineresting... 17:06:37 <mugsie> now there is some flow issues, an trying to make sure we dont edn up with inconsistant data 17:06:46 <mugsie> but that is the genral gist 17:07:05 <mugsie> now, these tickets are completely internal to designate 17:07:23 <mugsie> so theuser just sees a 202 Accepted responce 17:07:42 <eankutse> mugsie: so what are examples of backend ops? 17:07:50 <mugsie> and when they query designate, it will show pending until it is active,at which piint the status will change 17:08:10 <mugsie> creation / update / delete of domains / record 17:08:23 <mugsie> records* 17:08:34 <kiall> Any operation which changes something you query on port 53 basically ;) 17:08:43 <betsy> Is any of this on any of the blueprints on launcpad? 17:08:51 <vinodmr> What is the response that the user sees with a 202 - how do they get the link to query for status? 17:09:18 <mugsie> betsy: not yet, but should be by beginning of next week 17:09:28 <betsy> cool 17:09:28 <mugsie> maybe then end of this one 17:09:38 <kiall> 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 <betsy> but will the user receive a link to check status? 17:10:20 <mugsie> vinodmr: the link will be the "self" item in the responce 17:10:32 <mugsie> and when they get that link it will have a status field 17:10:41 <betsy> ok 17:10:49 <vinodmr> I am trying to understand why we need a separate ticket id. 17:10:57 <mugsie> https://review.openstack.org/#/c/44730/ is the beginning work of this 17:11:05 <vinodmr> Can we not use the self link to communicate the status? 17:11:24 <mugsie> vinodmr: this is for when a backend is not doing the operations instantly 17:12:04 <kiall> 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 <kiall> Similar to how while booting a Nova instance, it will go to "BUILD", then eventually "ACTIVE" 17:12:57 <vinodmr> i meant can we use the domain/record it itself to communicate status between the backend and central? 17:13:08 <vinodmr> *id 17:14:11 <vinodmr> at any given time, can there be multiple operations outstanding for the same domain/record id? 17:14:22 <mugsie> vinodmr: this allows for multiple operations to be used 17:14:33 <mugsie> so say creating a record and domain 17:14:46 <mugsie> so both need to be done in the right order 17:15:14 <betsy> but isn't there a domain id and a record id already? 17:15:44 <mugsie> yeap, but we could have multiple operations happening on a single item 17:16:00 <mugsie> so the domain should not go to active untillall have completed 17:16:01 <kiall_> 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 <kiall_> even though those 5 records themselves would go to ACTIVE as soon as they are pushed out 17:17:59 <kiall_> 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 <mugsie> yeah, we can talk about it when the docs go up 17:18:54 <betsy> looking forward to the docs 17:19:14 <eankutse> mugsie: thx 17:19:23 <vinodmr> 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 <kiall_> #action mugsie to finish+publish docs on async backends/tickets/etc 17:20:07 <kiall_> vinodmr: so, with the v2 API as is today, create domain can't contain any RecordSets 17:20:27 <kiall_> 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 <kiall_> 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 <kiall_> 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 <vinodmr> 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 <kiall_> #topic "Verifing" Domain Ownership 17:23:37 <Kiall> #topic "Verifing" Domain Ownership 17:23:39 <Kiall> Ugh 17:23:41 <Kiall> Okay - so justinsb suggested this, and I 17:23:49 <Kiall> wanted to get your opinions on it 17:24:43 <Kiall> Does RAX have any requirement for verifying ownership of a domain before accepting/serving a domain? 17:24:50 <kiall> #topic "Verifing" Domain Ownership 17:24:53 <kiall> There we go :) 17:25:28 <CaptTofu> heh 17:25:40 <simonmcc> so this is a larger DNS hosting issue - how does it affect Designate? 17:26:03 <vinodmr> how big/common of a problem is this? 17:26:05 <simonmcc> other than providing tooling to support a decision process or correction process? 17:26:30 <kiall> 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 <jmcbride> 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 <kiall> 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 <kiall> jmcbride: absolutely - we prevent that scenario today 17:28:09 <simonmcc> how do you prevent it? 17:28:19 <kiall> But.. I think we have a bug that if someone reghisters bla.example.com, another tenant can nab example.com .. 17:28:29 <simonmcc> conflict resolution involves somebody making a decision & then deleting the 'illegal zones' 17:28:33 <kiall> I've yet to validate if that's actually an issue though 17:28:59 <vinodmr> 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 <mugsie> simonmcc: for some of them they ask you to create a cname record, then test if its there 17:29:36 <simonmcc> create a came for a zone you're trying to get hosted? or create the came in the parent? 17:29:37 <kiall> 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 <betsy> yeah or a txt record 17:29:58 <kiall> #link http://blog.cloudflare.com/whats-the-story-behind-the-names-of-cloudflares-name-servers 17:30:09 <mugsie> simonmcc: in the parent zone, unless you use an inbuilt registrar 17:30:19 <kiall> ^ that was a really interesting approach, but 100% somthing we can't bake into designate as a requirement 17:30:40 <kiall> betsy: well, the issue with a TXT record is brand new domains don't have existing DNS :) 17:30:56 <kiall> Anyway - It sounds like you guys agree, this is out of scope 17:32:03 <simonmcc> agreed, out of scope 17:32:16 <vinodmr> #agreed 17:32:25 <msisk> Yep. Big can of worms. ;) 17:32:44 <betsy> agreed 17:33:02 <kiall> Okay - Well, lets call that out of scope and move on so :) 17:33:02 <jmcbride> 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 <kiall> 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 <kiall> #topic Migration tools 17:34:06 <kiall> jmcbride: you added this item :) 17:34:57 <jmcbride> 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 <kiall> Ah - So.. At the moment, no. I have a proof on concept zone import/export 17:35:46 <kiall> #link https://blueprints.launchpad.net/designate/+spec/domain-import-export 17:35:57 <kiall> But - It's full of holes! 17:36:30 <kiall> The blueprint ^ would cover feeling in, and exporting out BIND style config files.. 17:36:34 <kiall> feeding* 17:37:05 <kiall> (It's open for the taking BTW :P) 17:37:41 <kiall> 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 <simonmcc> has anybody gone through cloud flare's process? do they just pick off www/mail/blog etc from your domain? 17:39:24 <kiall> 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 <simonmcc> 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 <kiall> 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 <msisk> yeah, I haven't used AXFR in a long time -- it's blocked everywhere nowadays. 17:41:01 <jmcbride> Sounds like AXFR should be a separate blueprint 17:41:14 <mugsie> jmcbride: yup 17:41:16 <kiall> 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 <simonmcc> yep 17:41:53 <kiall> jmcbride: yea.. It's not happening anytime soon - unless you guys have the resources to handle it :) 17:42:06 <CaptTofu> agreed 17:42:15 <kiall> I've barely got bast the "That would be a useful thing" thoughts on it :) 17:42:26 <kiall> I'm only mentioning it, as it semi-relates to importing of data :) 17:42:53 <kiall> The other import option, is something in the client, rather than an API endpoint, that reads and creates the zone. 17:44:10 <kiall> 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 <tsimmons> Cool, that would be useful. 17:44:47 <kiall> Okay moving on :) 17:44:50 <kiall> #topic Open Discussion 17:45:07 <kiall> i.e. the "Anyone got anything else?" part of the meeting :) 17:45:53 <kiall> I think eankutse had some Q's earlier? 17:45:54 <msisk> BTW, my proposal to do a presentation at http://openstack.onales.com on Designate has been accepted. ;) 17:46:12 <simonmcc> congrats msisk! 17:46:17 <kiall> Excellent! 17:46:42 <msisk> Might need you folks to help me out once I get working on the slide deck. Guess I should start soon. ;) 17:46:58 <kiall> Sure - Anytime :) 17:47:36 <msisk> kiall: Thanks! 17:48:25 <kiall> So .. Last call? :) 17:48:26 <eankutse> Nothing from me 17:49:21 <simonmcc> nothing from me 17:49:28 <mugsie> ditto 17:49:38 <betsy> same for me 17:49:43 <kiall> Okay - Thanks all :) 17:49:56 <eankutse> :-) 17:50:06 <CaptTofu> thanks! 17:50:12 <kiall> Will talk during the week, once mugsie gets the docs up 17:50:18 <mugsie> o/ 17:50:19 <kiall> probably before the next meet? 17:50:24 <tsimmons> Good stuff 17:50:25 <mugsie> yeah 17:50:33 <kiall> #endmeeting