17:00:49 <mugsie> #startmeeting Designate
17:00:53 <openstack> Meeting started Wed Aug 31 17:00:49 2016 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:58 <openstack> The meeting name has been set to 'designate'
17:01:05 <mugsie> #topic Roll Call
17:01:08 <timsim> o/
17:01:48 <mugsie> #topic Announcements
17:01:58 <mugsie> Designate 3.0.0.0b3 was tagged
17:02:07 <mugsie> and the dashboard
17:02:12 <mugsie> and a new version of the client
17:02:26 <mugsie> anyone else have anything?
17:02:53 <mugsie> #topic Action Items
17:03:15 <mugsie> mugsie close http://bugs.launchpad.net/designate/+bug/1609576
17:03:15 <openstack> Launchpad bug 1609576 in Designate "v1 API always gives null for record descriptions, despite v2 recordset having a description?" [Undecided,Invalid]
17:03:19 <mugsie> done
17:03:33 <mugsie> kiall to BP 028c9bf Fix SSHFP validation for ECDSA, ED25519, and SHA256
17:03:42 <mugsie> Not done afaik
17:03:50 <mugsie> #action kiall to BP 028c9bf Fix SSHFP validation for ECDSA, ED25519, and SHA256
17:04:24 <Kiall> Derp. I did it, but submitted to our internal Gerrit somehow
17:04:28 <mugsie> lol
17:04:29 <Kiall> aka not done\
17:04:41 <mugsie> #topic Bug Triage (timsim - recurring)
17:04:56 <timsim> lots of stuff this week
17:04:57 <timsim> https://bugs.launchpad.net/designate/+bug/1614627
17:04:57 <openstack> Launchpad bug 1614627 in Designate "The 'next' link not shown" [Undecided,New]
17:05:07 <Kiall> :(
17:05:15 <mugsie> huh
17:05:27 <mugsie> Critical
17:05:37 <Kiall> that looks pretty bad.
17:05:50 <timsim> yep
17:06:00 <mugsie> target RC1
17:06:02 <Kiall> Probably an off by 1 somewhere
17:06:09 <mugsie> yeah
17:06:12 <timsim> Don't have an rc1 milestone yet?
17:06:19 <mugsie> refresh
17:06:34 <timsim> cool
17:06:44 <timsim> https://bugs.launchpad.net/designate/+bug/1615997
17:06:44 <openstack> Launchpad bug 1615997 in Designate "InfoBlox backend docs out of date" [Undecided,New]
17:06:44 <mugsie> :)
17:06:50 <timsim> https://bugs.launchpad.net/designate/+bug/1618688
17:06:50 <openstack> Launchpad bug 1618688 in Designate "Infoblox backend: "SSLError: [Errno 2] No such file or directory" error when using sslverify False in pools.yml" [Undecided,New]
17:06:52 <mugsie> L, no milestone
17:06:58 <timsim> Putting those together.
17:07:05 <mugsie> eh
17:07:13 <mugsie> I think one is an actual bug
17:07:20 <mugsie> and the other is a request for docs
17:07:34 <timsim> Fair enough. L for the first one.
17:07:54 <timsim> What about the second, same?
17:08:08 <mugsie> eh - not sure
17:08:24 <Kiall> That looks like a legit bug
17:08:32 <Kiall> sslverify is either True/False or a path to a cert
17:08:35 <Kiall> (from memory)
17:08:47 <Kiall> L / High
17:09:01 <Kiall> Prob not critical
17:09:17 <mugsie> H
17:09:36 <mugsie> it looks like it is being parsed as a string, where previously is was hardcoded to a bool
17:09:42 <mugsie> https://github.com/openstack/designate/blob/master/designate/backend/impl_infoblox/config.py
17:10:05 <timsim> Just hope someone steps up to maintain that backend I guess.
17:10:18 <timsim> https://bugs.launchpad.net/designate/+bug/1616541
17:10:18 <openstack> Launchpad bug 1616541 in Designate "mDNS fails to handle SOA etc queries correctly when multiple pools have a RRSet of the same name and type" [Undecided,New]
17:10:40 <Kiall> this is the one I found at the mid-cycle
17:10:59 <Kiall> Probably High/Critical
17:11:01 <timsim> High RC1?
17:11:14 <mugsie> yeah
17:11:15 <timsim> I guess Critical if it could break multi pool eh
17:11:18 <Kiall> Yea, It should be a simple enough fix
17:11:26 <mugsie> actualy, yeah
17:11:37 <mugsie> C
17:11:51 <timsim> https://bugs.launchpad.net/designate/+bug/1617356
17:11:51 <openstack> Launchpad bug 1617356 in Designate "Recordsets are going in error status." [Undecided,New]
17:12:03 <timsim> Not a bug, support request? Come to #openstack-dns plz?
17:12:21 <Kiall> I *think* that's someone from HPE
17:12:24 <mugsie> it id
17:12:33 <mugsie> it looks like a copy + paste from a Jira
17:12:34 <timsim> ohh yeah. hah
17:12:36 <Kiall> someone who I'll be having a call with this week ;)
17:12:44 <timsim> I'll just close it out then ;)
17:12:51 <mugsie> yeah - support request
17:12:54 <timsim> https://bugs.launchpad.net/designate/+bug/1617454
17:12:54 <openstack> Launchpad bug 1617454 in Designate "Changes do not propagate to downed/recovered nameservers, depending on threshold percentage" [Undecided,New]
17:13:05 <mugsie> this was pglass
17:13:07 <mugsie> right?
17:13:10 <timsim> yep
17:13:12 <pglass> yeah.
17:13:15 <Kiall> timsim: go ahead and close, it's the pool host/port are wrong for notifies
17:13:29 <mugsie> so.
17:13:40 <pglass> i have tests which catch this, in the third party ci jobs i added
17:13:47 <mugsie> this bug - it has "peridic sync is disabled"
17:13:47 <pglass> right now they're being skipped.
17:14:06 <mugsie> this was the reason that we wrote periodic sync
17:14:56 <pglass> well, so. we aren't running periodic sync in our internal envs, I think because we encountered performance issues with it.
17:15:08 <mugsie> the solution (IMHO) is to have threshold at 100% or run the sync
17:15:22 <Kiall> So - I gues the real issue is  performance of periodic sync so it can be turned on?
17:15:27 <mugsie> yeah
17:15:49 <timsim> Yeah basically. Also, there isn't a periodic sync in the worker world yet.
17:16:00 <Kiall> That too :)
17:16:25 <mugsie> well, in worker, it couldbe OK if the producer shards it up
17:17:12 <timsim> Yeah it should be.
17:17:29 <timsim> The problem was that the RPCAPI call to central to get all those zones timed out, if memory serves.
17:17:49 <timsim> But periodic sync isn't a perfect solution
17:18:04 <timsim> If you only run it every six hours or once a day something.
17:18:05 <Kiall> Oh, don't tell me it's asking for ALL zones at once? Rather than paging though them?
17:18:11 <timsim> Of course it is
17:18:12 <mugsie> well, there not much option afaik
17:18:14 <timsim> silly Kiall
17:18:32 <mugsie> other than a new state
17:18:33 <Kiall> timsim: derp. that's certainly going to cause pain and suffering
17:18:37 <timsim> Yeah.
17:18:38 <pglass> yeah. depending on your periodic sync seconds, you could still have zones never propagating if the nameserver is down long
17:18:38 <federico3> mugsie: why no much option?
17:18:41 <pglass> long enough*
17:18:43 <mugsie> and .... not  huge fan of that
17:19:01 <timsim> I thought we decided in Galway that another state would be the best solution?
17:19:06 <mugsie> pglass: in that sort o case you should sync the zonefiles etc, befoer bringit back up
17:19:16 <pglass> right, but that is annoying
17:19:24 <timsim> With another state you could just do it in recovery.
17:19:31 <mugsie> federico3: there is not many other options, other than syn
17:19:33 <rsyed2> mugsie: why no new state?  adding complexity to logic?
17:19:37 <Kiall> pglass: yea, that's something operators just need to be aware of I guess, after a long outage, set sync seconds to the duration of the outage or more, and let it recover.
17:19:37 <mugsie> yeah
17:20:02 <timsim> I mean that logic is awful, but we should clean that up anyway, and then we can add that new state and make everything great again.
17:20:05 <mugsie> rsyed2: yeah - and it will be displayed to users, which canbe confusing
17:20:14 <timsim> Oh no don't display it to users.
17:20:36 <pglass> basically, you would have the new state, which reflects the true status on the nameserver.
17:20:42 <mugsie> then you have 2 state machines, one people can see, and one tht actually happened
17:20:55 <pglass> then you look at the state and the threshold to decide whether you display active or not
17:21:07 <timsim> Ehhh or you just say if status==almost_active display active in the api
17:21:47 <Kiall> That feels dirty ;) Anyway! We should discuss the details separatly from triage :)
17:21:48 <rsyed2> translating states for display is kind of annoying...
17:21:52 <rsyed2> yeah
17:21:59 <mugsie> then how will an admin ever know if their zones are only partially sent out?
17:22:01 <rsyed2> *yeah (to kiall)
17:22:18 <pglass> you don't know anyway, if your threshold percentage is < 100
17:22:20 <mugsie> anyway - this bug needs to move -to something, or be closed
17:22:52 <Kiall> Maybe leave it to the end. There's a mix of docs, perf fixes, and possible new code to help with thresh < 100
17:23:23 <timsim> "Opinion"? "Can be discussed". And we can discuss there on the bug?
17:23:36 <Kiall> timsim: sure
17:23:38 <mugsie> Yeah
17:23:54 <timsim> Alright cool, I'll do that.
17:24:07 <timsim> mugsie action me to start some conversation on there
17:24:37 <mugsie> #action timsim to start convo on bug 1617454
17:24:37 <openstack> bug 1617454 in Designate "Changes do not propagate to downed/recovered nameservers, depending on threshold percentage" [Undecided,Opinion] https://launchpad.net/bugs/1617454
17:25:08 <timsim> That's it :)
17:25:24 <mugsie> \o/
17:25:44 <mugsie> #topic Stable Backport Triage (kiall - recurring)
17:25:51 <mugsie> worker model
17:25:52 <Kiall> #link http://paste.openstack.org/show/565255/
17:25:52 <Kiall> As usual, take a few and nominate for backport.
17:25:59 <Kiall> mugsie: LOL
17:26:12 <Kiall> af4613b Fix ZTA API to prevent HTTP 500 upon empty body
17:26:12 <mugsie> af4613b Fix ZTA API to prevent HTTP 500 upon empty body
17:26:13 <timsim> hahahaha
17:26:17 <Kiall> (BP is already up)
17:26:33 <Kiall> 97c5ab3 Merge "Use upper constraints for all jobs in tox.ini" ? Not sure about this one
17:26:51 <mugsie> we should
17:26:54 <mugsie> i think
17:26:58 <Kiall> 4458556 Fix recordset changes so that they preserve object changes fields - maybe? timsim thoughts?
17:27:28 <timsim> ehhh. I don't think so it doesn't fix any actual functionality because nothing depends on that in mitaka.
17:28:02 <mugsie> yeah
17:28:11 <mugsie> i think it is just tox, and ZTA
17:28:53 <mugsie> any others?
17:29:13 <timsim> nah. seems legit
17:29:30 <mugsie> OK - anyone want to bp these?
17:30:00 <Kiall> I'll do ZTA API
17:30:02 <mugsie> #action mugsie bp 97c5ab3 Merge "Use upper constraints for all jobs in tox.ini"
17:30:03 <Kiall> done.
17:30:07 <mugsie> :)
17:30:15 <mugsie> #topic Open Dscussion
17:30:24 <mugsie> any of agenda items?
17:30:26 <Kiall> Oh, LOL. It hasn't merged to master yet
17:30:27 <mugsie> off*
17:30:33 <Kiall> Happened to be in local clone
17:30:38 <mugsie> -_-
17:30:45 <Kiall> timsim / elarson: https://review.openstack.org/#/c/360613/ pls ;)
17:31:01 <Kiall> I
17:31:17 <timsim> could have sworn I did that
17:31:25 <timsim> I think I did but gerrit was trippin'
17:31:26 <Kiall> You +A'd the backport ;)
17:31:37 <timsim> -_-
17:31:49 <Kiall> I've got 1 - we talked about it last week at the mid-cycle briefly, but powerdns gate is falling over wayy too often. It looks like a DBdeadlock in PowerDNS (yay!).
17:32:14 <mugsie> and the issue I had with horizon is happening from time to time in grenade now
17:32:44 <Kiall> As part of trying to debug that, we got Designate logs sucked into logstash - so http://logstash.openstack.org/ will have logs from check/gate runs now to help triage failures over multiple runs
17:32:49 <Kiall> Use it :)
17:33:08 <mugsie> use what?
17:33:12 <mugsie> there is no output
17:33:30 <Kiall> ?
17:33:35 <Kiall> There is loads of output
17:33:47 <mugsie> for the horizon issue?
17:33:57 <mugsie> or where youtalking in a more general sense?
17:34:15 <Kiall> No, I was taking about powerdns fails and in general ;)
17:34:26 <mugsie> oh - pglass - the 3rd party CI is not uploading logs
17:35:41 <mugsie> can you fix it, or change thie link?
17:36:08 <timsim> He's afk, but I think he intends to have that working, so I'm sure he'll fix it
17:36:16 <mugsie> cool
17:36:26 <mugsie> who wants 25 mins back?
17:36:38 <timsim> Nah let's stay
17:36:42 <timsim> How's seattle?
17:36:46 <mugsie> grand
17:36:51 <mugsie> sleepless
17:37:16 <mugsie> :)
17:37:17 <timsim> Alright that's all I've got ;P
17:37:20 <timsim> review worker model
17:37:21 <mugsie> haha
17:37:21 <timsim> OH WAIT
17:37:25 <timsim> :fire:
17:37:34 <mugsie> :thisisfine:
17:37:44 <mugsie> #endmeeting