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