17:00:32 <timsim> #startmeeting designate
17:00:33 <openstack> Meeting started Wed Jun 14 17:00:32 2017 UTC and is due to finish in 60 minutes.  The chair is timsim. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:37 <openstack> The meeting name has been set to 'designate'
17:00:43 <mugsie> o/
17:00:46 <trungnv_> o/
17:00:53 <timsim> #topic roll call
17:00:54 <timsim> hi
17:01:05 <daidv_> o/
17:01:12 <mugsie> hey
17:02:09 <timsim> #topic action items from last week
17:02:20 <timsim> non
17:02:22 <timsim> noen
17:02:24 <timsim> NONE
17:02:35 <timsim> #topic Bug Triage
17:02:52 <timsim> wow, I don't see any new ones
17:03:02 <mugsie> yeah, I think we hit peak bug
17:03:05 <timsim> nice
17:03:33 <timsim> #topic Stable Backport Triage
17:03:42 <timsim> http://paste.openstack.org/show/612573/
17:04:27 <timsim> I don't see anything there worth bp'ing? Anyone else?
17:04:30 <mugsie> 96a5691 Fix issue with 'priority' value in pool_ns_record ?
17:04:59 <timsim> That just changes tests, I just had the same thought https://github.com/openstack/designate/commit/2e474f39bc7ca90e4c019a6bf137c23b9c66dd9e
17:05:00 <mugsie> nah
17:05:06 <mugsie> yeah - just checked
17:05:09 <trungnv_> yep.
17:05:14 <timsim> Alrighty then
17:05:20 <timsim> #topic Open Discussion
17:05:29 <timsim> o/ trungnv_ daidv_
17:05:30 <daidv_> Can I?
17:05:33 <timsim> sure
17:06:09 <daidv_> as u know, we have completed OVO migration for Designate
17:06:09 <daidv_> :D
17:06:14 <trungnv_> all PS about OVO: https://review.openstack.org/#/q/status:open+project:openstack/designate+branch:master+topic:OVO
17:06:50 <trungnv_> last time, I had discuss with mugsie about them.
17:06:57 <trungnv_> Did you test them?
17:07:02 <mugsie> yeah - I need to do manual testing
17:07:31 <mugsie> I have not had a chance this week
17:07:44 <mugsie> but they look promissing
17:07:47 <trungnv_> yep. Do you have comments at the moment for us?
17:07:55 <mugsie> not yet
17:08:58 <trungnv_> yeap.
17:09:04 <timsim> FWIW, the kind of manual testing we'll be doing is basically exercising every API call that we possibly can, errors, regular calls, things that the functional tests do, and verifying that nothing has changed.
17:09:08 <timsim> Basically trying to break it
17:09:13 <timsim> If you all would like to do that, it would be welcome
17:09:45 <timsim> The other question I had is about the actual migration stuff. Have you documented what a zero-downtime migration with this new stuff looks like? Or is it not ready for that yet?
17:11:38 <trungnv_> we are implementing for rolling-upgrade at the moment.
17:11:48 <daidv_> not yet.
17:12:33 <trungnv_> if can, we will perform zero-downtime migration in the next time.
17:14:01 <mugsie> yeah - that will be more complex
17:14:06 <mugsie> you will need to look at minidns
17:14:11 <mugsie> as it does not use object
17:14:12 <mugsie> s
17:14:30 <mugsie> it uses hand crafted SQL
17:14:40 <mugsie> so, any updates may cause major issues there
17:15:17 <trungnv_> sure. a lot of things need for zero-downtime solution in Designate project.
17:15:57 <trungnv_> Now we just want to focus rolling-upgrade and OVO are things very importance now.
17:16:25 <timsim> Alright fair enough.
17:16:29 <timsim> Anything else folks want to talk about?
17:16:38 <timsim> Besides mugsie and timsim to review things please :)
17:16:50 <trungnv_> yep.
17:17:18 <trungnv_> I want to discuss about my idea for genconfig and centralize config
17:17:46 <trungnv_> I also discuss with mugsie about them. please give me any responses?
17:17:57 <trungnv_> my BP: https://blueprints.launchpad.net/designate/+spec/centralize-config-designate
17:18:13 <trungnv_> and my PS about genconfig: https://review.openstack.org/#/c/472770/
17:19:10 <trungnv_> for genconfig, I think both option for user is good solution.
17:19:37 <trungnv_> keep current sample and create full sample in the local.
17:21:00 <timsim> Hm. So I guess the value-add is that people can generate a config that has every possible option?
17:21:49 <trungnv_> yep.
17:22:06 <mugsie> it is - but there is some issues - I have a 1/2 completed revierw
17:22:14 <mugsie> I will finish that today or tomorrow morngin
17:22:34 <trungnv_> mugsie, yeah. thanks
17:22:48 <trungnv_> about my BP, any comments for it?
17:23:18 <trungnv_> nova, magnum, babican and alot project used them.
17:23:46 <timsim> It's kinda weird that we have to conf.register everywhere
17:23:52 <timsim> that's a lot of code for that
17:23:52 <mugsie> just because nova does something doesn't make it right :)
17:24:00 <timsim> ^^^^^^ x 1000
17:24:09 <mugsie> I am not sure it is worth time
17:24:19 <trungnv_> yeah. above 1000 line of code.
17:24:54 <trungnv_> I and daidv (my co-worker) will spend effort for this BP if you want.
17:25:15 <mugsie> I personally think it is harder
17:25:33 <mugsie> as you have to go look solmewhere completely different for the defined config options
17:27:08 <trungnv_> yep. my PS about genconfig which a part of in centraliz config BP.
17:27:29 <trungnv_> I believe we can.
17:27:31 <timsim> I wonder if there's a way to do it more low-tech, where you just iterate all the modules and look for config options
17:27:39 <timsim> and it doesn't have to have all this overhead.
17:28:33 <mugsie> we dont need to move everything for generation of sample config
17:28:43 <mugsie> it we just have to tell it where to get config
17:29:31 <timsim> hm. ok
17:29:48 <trungnv_> I know. but if we have central config then developer work on more easy.
17:30:11 <mugsie> I dont think so
17:30:28 <mugsie> it is more confusing
17:30:58 <mugsie> we have very little config compared to nova - so there is not a huge advantage
17:31:46 <daidv_> I wonder how did they make config reference docs?
17:33:07 <daidv_> May be, sample config is not contain every options but config reference documentation
17:33:36 <daidv_> contain most of them.
17:33:47 <mugsie> config ref is a good idea
17:33:56 <trungnv_> daidv_, we are discussing about centralize config
17:34:09 <mugsie> I would like to see that - and that can be included int he docs as well
17:34:18 <mugsie> I dont think centralised config is a good idea
17:35:16 <trungnv_> mugsie, perhaps I need discuss this idea in the next week? I will look at code-base again.
17:35:51 <trungnv_> with genconfig then I think it need for operators.
17:36:25 <trungnv_> for some users who need full config. then this is good solution.
17:36:52 <trungnv_> I remember, have some guys asked about auto-genconfig in IRC.
17:37:49 <mugsie> yeah - gen config is different to central config
17:37:56 <mugsie> I am OK wiht gen config
17:38:33 <trungnv_> yep.
17:38:57 <daidv_> mgagne, , I have one more things.
17:39:01 <daidv_> mugsie,
17:39:09 <mugsie> sure
17:39:10 <daidv_> about TsigKey name format?
17:39:25 <mugsie> yeah
17:39:29 <mugsie> thats a bad one
17:39:38 <mugsie> we cant chage it - it is a breaking API chnage
17:39:54 <mugsie> i has to go to just a string
17:41:35 <trungnv_> so we cannot validate them.
17:42:12 <trungnv_> same like tenant_id.
17:42:21 <mugsie> yes
17:42:54 <daidv_> mugsie, Hm, in near future, we can use string only. But are you comfortable with that?
17:43:10 <trungnv_> do you want to change this format in the future?
17:46:09 <mugsie> daidv_: I am not happy about it - but we made a mistake and we have to live with it now
17:46:23 <mugsie> we cannot change the format
17:46:26 <mugsie> ever
17:46:42 <mugsie> it is a breaking API change to do that, and we do not make breaking changes
17:48:08 <trungnv_> yeap. a lot of things need changed if this format convert to domainnam.
17:48:13 <trungnv_> yeap. a lot of things need changed if this format convert to domainname.
17:48:16 <daidv_> Ok, "ever" - worst news.
17:48:39 <mugsie> yeah - but we do not break things for users
17:48:51 <daidv_> yep.
17:49:05 <daidv_> mugsie, anyway, did you remember the timeout DEBUG log?
17:49:38 <trungnv_> timsim, mugsie some remain PS on Designate need you review.
17:49:50 <daidv_> I'm trying to fix it but still not find out the problem.
17:50:37 <daidv_> But I realize one thing that if we use oslo.messaging <= 5.17.1, everything is Ok.
17:51:02 <trungnv_> yeah. this is bug which hieulq raised in launchpad.
17:51:18 <mugsie> daidv_: oh, really?
17:51:20 <mugsie> humm
17:52:02 <daidv_> yep, from oslo.messaging >=5.18.0 , I got many DEBUG log about timeout.
17:53:04 <mugsie> OK - we need to look at release notes for oslo messgaing, and the code to see what changed
17:54:07 <timsim> weird
17:54:38 <daidv_> timsim, I also still have no idea on that.
17:55:02 <daidv_> As my debuging, we got the same things at
17:55:06 <timsim> hm. Well, release notes might have a clue, let's hope
17:55:07 <daidv_> https://github.com/openstack/designate/blob/master/designate/central/rpcapi.py#L154
17:55:42 <daidv_> for Ocata and master for each time PeriodicGenerateDelayedNotifyTask called
17:56:31 <daidv_> timsim, no more information from oslo.messagin releasenotes.
17:56:56 <timsim> Well, perhaps we can think of something else
17:57:27 <timsim> Are we done? We're almost at time
17:57:56 <trungnv_> yep. enough for me.
17:57:58 <daidv_> Yep.
17:58:03 <daidv_> thanks!
17:58:07 <timsim> Alright, thanks all, see you in #openstack-dns
17:58:08 <timsim> #endmeeting