16:59:23 <mugsie> #startmeeting Designate
16:59:23 <openstack> Meeting started Wed Feb  3 16:59:23 2016 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:27 <openstack> The meeting name has been set to 'designate'
16:59:31 <mugsie> #topic Roll Call
16:59:35 <rsyed> o/
16:59:39 <sonuk> o/
16:59:40 <timsim> o/
16:59:45 <pglass> o/
17:00:16 <mugsie> federico3: ekarlso Kiall courtesy ping
17:01:14 <mugsie> #topic Action Items from last week
17:01:19 <mugsie> only one out standing
17:01:22 <mugsie> mugsie arrange sync re workshop
17:01:24 <mlavalle> o/
17:01:28 <mugsie> #action mugsie arrange sync re workshop
17:01:52 <mugsie> #topic Bug Triage (timsim - recurring)
17:02:11 <timsim> Nothing new?
17:02:13 <timsim> Really?
17:02:22 <timsim> WE HAVE ACHIEVED STABILITY
17:02:40 <mlavalle> wow!
17:02:41 <mugsie> \o/
17:03:18 <mugsie> #topic Backports
17:03:26 <mugsie> #link http://paste.openstack.org/show/485874/
17:03:38 <mugsie> so, please review and nominate patches
17:03:39 <federico3> o/
17:03:44 <timsim> (There are no new bugs)
17:04:13 <mugsie> fe3f7df Fix wildcard NS record
17:04:27 <mugsie> thats all I can see
17:04:36 <mugsie> anyone else see anything that should be back ported
17:04:38 <mugsie> ?
17:04:57 <sonuk> c3dec4e Merge "Add docs for PATCH and DELETE call of Zone transfer request"
17:05:08 <mugsie> yeah
17:05:10 <mugsie> caa9cc6 Merge "Add validation for MX, TXT, and SSHFP records"
17:05:13 <mugsie> as well
17:05:16 <timsim> lol thanks for catching up irc. I'm back now
17:05:26 <mugsie> nice
17:05:35 <mugsie> #useARealIRCClient
17:05:40 <mugsie> :P
17:05:43 <timsim> #useslack
17:05:53 * timsim is kidding, don't open that can of worms
17:06:10 <mugsie> OK, anyone want to do these backports?
17:06:30 <mugsie> dont all jump at once
17:06:31 <mugsie> :D
17:06:58 <federico3> <--
17:07:08 <mugsie> #action federico3 to backport caa9cc6 c3dec4e fe3f7df
17:07:28 <mugsie> #topic https://review.openstack.org/#/c/247588/
17:07:32 <mugsie> #link
17:07:36 <mugsie> #link https://review.openstack.org/#/c/247588/
17:08:03 <mugsie> basically - me and federico3 wanted to see if there is anything else we need from this
17:08:15 <mugsie> or if there is an alternate direction
17:08:32 <timsim> I'm not a fan.
17:08:34 <mugsie> if not - we should test the hell out of it before merging, as it could be risky
17:08:41 <mugsie> i got that from the comment :)
17:09:06 <federico3> timsim: ...because it will require more work in future to extend it to other use cases?
17:09:19 <federico3> or you want to propose a different implementation?
17:09:29 <timsim> I think, as heavy handed as it is, it's not really solving the problems that it could be.
17:10:16 <timsim> I think I could propose an alternate implementation, but definitely not in the next 2-5 minutes
17:10:23 <timsim> hint: worker model
17:10:38 <mugsie> timsim: worker model could cover some of it
17:10:45 <timsim> you can do anything with worker model (also zombo.com)
17:10:53 <mugsie> but not a global ratelimit
17:11:10 <timsim> Some intelligent caching could get you a global rate limit
17:12:17 <mugsie> true
17:12:29 <timsim> Rate limiting notifies basically solves that problem.
17:12:47 <mugsie> but this as a shorter term fix for the NS problem - should we merge this
17:12:47 <timsim> Rate limit + queue
17:13:14 <mugsie> the worker model is ... unlikely to merge pre M
17:13:21 <timsim> I think it's too much technical debt for something we'll "fix later" ;)
17:14:01 <timsim> + performance overhead
17:14:05 <timsim> But that's just me
17:14:14 <federico3> certainly the worker model would require some major rework of this code
17:14:33 <timsim> You basically wouldn't need it.
17:14:45 <timsim> You'd probably solve the problem a different way.
17:14:47 <federico3> yet, afaict we are talking about different timelines
17:14:59 <federico3> yep
17:15:30 <mugsie> my issue is we may release something that currently causes all zones to go to pending
17:15:55 <timsim> We already have, haven't we?
17:16:05 <mugsie> and when a periodic timer hits will flood the Downstream servers
17:16:18 <mugsie> we have, and I would like to avoid doing it again :)
17:16:48 <mugsie> what can we do in the short term to alivate this without causing issues when we come to the worker model
17:17:04 <timsim> Document that you can shoot yourself in the foot if you create a bunch of resources and than change the NS records?
17:17:40 <timsim> It seems like a thing that would give pretty much any operator pause.
17:18:08 <timsim> If you've only got a few hundred zones (probably everyone running Designate) it wouldn't even be a huge issue.
17:18:33 <mugsie> well, apart from all your zones being in PENDING
17:18:41 <timsim> Well yeah, but you're doing a migration at that point.
17:18:49 <timsim> and they should fix themselves over time
17:18:57 <timsim> and it's not like you can't continue to update them during that time.
17:19:33 <mugsie> OK.
17:19:59 <mugsie> can we at least give this a good dose of testing?
17:20:17 <timsim> Probably not before the mid-cycle (from us)
17:20:36 <mugsie> OK - well that is very close anyway
17:20:55 <mugsie> we can stick an hour down to talk it through there if needs be
17:21:16 <mugsie> #action mugsie circle back to https://review.openstack.org/#/c/247588/ next week
17:21:37 <mugsie> federico3: anything else to add ?
17:22:05 <federico3> no, we can discuss this more extensively next week
17:22:14 <mugsie> kk
17:22:16 <mugsie> #topic Designate/Neutron Integration Update (mlavalle - recurring)
17:22:20 <mlavalle> hi
17:22:22 <mugsie> mlavalle: over to you :)
17:22:50 <mlavalle> I submitted follow up patches to Nova https://review.openstack.org/#/c/271578/4
17:23:08 <mlavalle> I added unit tests that I think are complete now
17:23:23 <mlavalle> one of the jobs failed yesterday with 1 test
17:23:38 <mlavalle> Took a look at the logs and it's unrelated to my patch
17:23:53 <mlavalle> so I rechecked it an 1 hour ago. It should pass
17:23:57 <mugsie> OK, cool
17:24:13 <mlavalle> I also continue working on the new chapter for the Networking Guide
17:24:26 <mugsie> great
17:24:30 <mlavalle> I should push patchset at the end of the week
17:24:54 <mlavalle> and I saw we have a talk proposed for Austin.... Looking forward to it!
17:25:05 <mlavalle> and that's it from me this week
17:25:08 <mlavalle> questions?
17:25:22 <mugsie> do we need to push nova for buy in?
17:25:41 <mugsie> or is it likely to get reviewed by in time?
17:25:49 <mlavalle> I would apreciatte if you ping John, the PTL:
17:26:03 <mugsie> will do
17:26:21 <mugsie> #action mugsie ping johnthetubaguy about the DNS name patch
17:26:38 <mugsie> anyone else?
17:27:01 <mugsie> OK - thanks fopr the work mlavalle
17:27:04 <mugsie> #topic sonuk: tempest plugin implementation
17:27:10 <mugsie> sonuk: you around?
17:27:12 <sonuk> i am finding lots of issue in existing tempest in designate as it is outdated causing import and other issue. I am fixing the issues. I will submit the patch regarding tempest plugin soon.
17:27:32 <mugsie> OK, cool
17:27:42 <mugsie> if you need help, just shout
17:28:15 <mugsie> any questions for sonuk ?
17:28:35 <sonuk> musie:ok sure.
17:28:43 <sonuk> mugsie:ok sure.
17:28:49 <mugsie> I know pglass and ekarlso did most of the work on those tests, so they are good people to ping as well
17:28:56 <mugsie> ok
17:29:02 <mugsie> #topic Open Discussion
17:29:12 <mugsie> anyone have off agenda items?
17:29:19 <pglass> sonuk: fyi, the functional tests don't actually use tempest. they use tempest-lib.
17:29:33 <sonuk> yep i saw that
17:30:05 <sonuk> mugsie: https://blueprints.launchpad.net/designate/+spec/zone-transfer-accept-list-delete
17:30:29 * mugsie reads
17:31:14 <mugsie> we actually ahve a way to list all accepted zone transfer requests
17:31:44 <sonuk> mugsie: but we cant do it through rest apiu right
17:31:50 <mugsie> we can
17:32:34 <sonuk> mugsie: i am not able to execute.
17:32:39 <mugsie> GET /zones/tasks/transfer_requests?status=COMPLETE
17:32:59 <mugsie> wil show all your requests that have been completed
17:33:29 <mugsie> you cannot delete an accepted request, as it is part of the history of another object
17:34:22 <sonuk> mugsie: ok  thanks.  but i think we should have a "accepted zone transfer request list" cli
17:34:49 <mugsie> ah, in the CLI that could bu useful
17:34:52 <mugsie> be*
17:35:08 <sonuk> mugsie: yep
17:35:52 <mugsie> cool - that sounds good to me
17:36:04 <mugsie> anything else?
17:36:11 <MPBNKA> https://blueprints.launchpad.net/designate/+spec/tenant-domainid-for-designate-sink
17:36:30 <mugsie> MPBNKA: did the spec get updated for this?
17:36:52 <MPBNKA> no I am not sure how to proceed from here
17:38:20 <mugsie> OK - last week we said it should be aimed at the v2 api
17:38:41 <mugsie> and that it should not be part of the zones api itself - it needs to be separate
17:39:36 <mugsie> there is an example of a generic one -that should be made for just a domain per tenant
17:39:44 <mugsie> #link https://review.openstack.org/#/c/89689/
17:40:00 <MPBNKA> ok
17:40:40 <mugsie> so, there should be a new API endpoint (like /project/default-domain ) that people can POST a zone ID to
17:40:42 <MPBNKA> but they still wont be able to change the fqdn assigned by default by sink
17:40:51 <MPBNKA> they would need admin creds
17:41:06 <mugsie> no - that would be stored on a per tenant basis
17:41:39 <MPBNKA> ok will check this
17:41:46 <mugsie> it would be a new table in the DB, with project_id, default_zone_id as the columns
17:42:00 <mugsie> if you have any trouble ping me in IRC
17:42:34 <mugsie> anything else?
17:43:02 <mugsie> timsim: ready for a long flight?
17:43:10 <timsim> Always
17:43:19 * timsim needs to figure out how to get from dublin->galway
17:43:26 <mugsie> welcome to how the rest of the world feels :)
17:43:31 <mugsie> timsim: will ping on that after
17:43:56 <mugsie> OK - if that is it - see ya'll in IRC / inperson next week for some
17:43:59 <mugsie> #endmeeting