17:05:09 <timsim> #startmeeting designate
17:05:10 <openstack> Meeting started Wed Apr 19 17:05:09 2017 UTC and is due to finish in 60 minutes.  The chair is timsim. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:05:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:05:13 <openstack> The meeting name has been set to 'designate'
17:05:15 <timsim> #topic Roll Call
17:05:24 <trungnv> o/
17:05:28 <timsim> ping mugsie sonuk
17:05:48 <sonuk> \o
17:06:47 <timsim> multi-tasking, just a sec
17:07:17 <timsim> #topic Bug Triage
17:07:34 <timsim> https://bugs.launchpad.net/designate/+bug/1682624
17:07:35 <openstack> Launchpad bug 1682624 in Designate "Record names are not validated when bypassing the Api (e.g. when using the sink)" [Undecided,New]
17:08:36 <timsim> Seems like a pretty good bug to me. H
17:09:40 <timsim> #topic Open Discussion
17:09:43 <timsim> nothing to bp
17:09:51 <timsim> Anyone have anything they'd like to discuss?
17:09:51 <trungnv> I has been replied along with your comment in my specs: https://review.openstack.org/#/c/451865/
17:10:06 <trungnv> hi timsim
17:10:12 <trungnv> I has been replied along with your comment in my specs: https://review.openstack.org/#/c/451865/
17:10:23 <trungnv> please review it.
17:10:44 <trungnv> I have agreed with API microversion which do not need for rolling upgrade.
17:11:07 <trungnv> Regarding to OVO items, I understand how to use adapter which you implemented in codebase. They will comunicate between api and object.
17:11:20 <mugsie> hey - soory -here now
17:11:37 <trungnv> Our solution with rolling upgrade that is migrating Object into OVO and keep working with currently adapter then test with rolling upgrade. Based on this result we will modify adapter again.
17:11:50 <hieulq_> o/
17:11:55 <mugsie> trungnv: we can't do that
17:12:10 <mugsie> we do validation completely differently to OVO
17:12:20 <mugsie> they do a field at a time
17:12:27 <mugsie> we do whole object validation
17:12:59 <mugsie> (so we can give back multiple errors, and we can validate the object based on the contents of some fields)
17:13:00 <trungnv> I know, we will attempt with local system then testing with our code before push into Designate project.
17:13:43 <mugsie> OK - but you may need to abandon that route
17:14:07 <trungnv> yes.
17:14:30 <trungnv> we need to try with our solution at the moment.
17:14:58 <mugsie> I honestly think in the interest of time, you should start looking at how to do it with out oslo versioned objects
17:15:04 <trungnv> because rolling-upgrade which we really need to implement for our  cloud K5 system.
17:15:38 <hieulq_> mugsie, I saw we are using adaptor as an upper layer for rendering and validating current designate object, right?
17:15:38 <trungnv> yes. we are implementing these code for OVO in local system
17:15:44 <mugsie> hieulq_: yes
17:15:53 <mugsie> well, just rendering
17:16:00 <mugsie> validation is in the object
17:16:12 <hieulq_> mugsie, thanks
17:16:41 <mugsie> https://github.com/openstack/designate/blob/master/designate/objects/base.py is the core of the work
17:16:41 <hieulq_> mugsie, so our approach is move the validation part to adaptor and migrate current object to o.vo
17:17:08 <mugsie> eh
17:17:19 <mugsie> I am not confortable with that
17:17:21 <timsim> same
17:17:30 <hieulq_> ok
17:17:40 <mugsie> and that is not called out in the spec
17:17:53 <hieulq_> yeah the spec is WIP
17:17:55 <mugsie> adapators are only ever used by the API
17:18:06 <mugsie> validation canm and should happen at other levels
17:18:45 <hieulq_> I guess my team should ask oslo team for finding a solution for this case
17:18:51 <mugsie> I really urge you to not waste time on the ovo
17:19:25 <hieulq_> thanks for suggestions
17:19:49 <mugsie> if you can get OVO split (on bit that does object validation and building, and one that does versioning), that may work
17:20:10 <mugsie> but, I think you will need to take on that work
17:20:29 <mugsie> is anyone from Fujitsu going to be in Boston?
17:20:41 <hieulq_> mugsie, I will
17:21:04 <hieulq_> along with other guys from rolling upgrade team in Fujitsu
17:21:06 <mugsie> OK - I will be as well. We should talk in person, and then send an update to the mailing list
17:21:16 <hieulq_> sure
17:21:32 <hieulq_> I will try to find a solution for this case
17:21:49 <timsim> Definitely come to this https://www.openstack.org/summit/boston-2017/summit-schedule/events/18590/project-update-designate
17:22:07 <hieulq_> scheduled in my calendar
17:22:20 <mugsie> I will also say, that you may need to have some team members working on designate itself as well
17:22:37 <hieulq_> trungnv is the dedicated member
17:22:46 <hieulq_> also he is quite new
17:22:48 <mugsie> as there is no full time devs on the project, just to keep the system builing
17:22:53 <mugsie> building*
17:23:05 <hieulq_> understood!
17:23:20 <trungnv> yep.
17:23:28 <timsim> I'll implore you, once again, to consider the *why* behind your desire to implement rolling upgrade. Designate has an upgrade story that could get you to less than a minute of downtime already without doing a years worth of work.
17:23:48 <timsim> If you slapped some maintenance mode API stuff in front of that you could have the API never go "down down".
17:24:04 <hieulq_> thanks timsim
17:24:10 <mugsie> even nginx with retry mode turned on would probably do it
17:24:26 <timsim> Re-implementing 1/3 of Designate's code to do this is...well it's a lot of work for very little gain.
17:24:58 <hieulq_> at least we are trying testing upgrade in several projects and estimate the effort for these kind of works
17:25:17 <hieulq_> so we will consider your suggestions
17:25:22 <mugsie> great
17:25:44 <timsim> Alright, does anyone want to discuss anything else?
17:25:46 <trungnv> mugsie please confirm how long for upgrade with designate? 2minutes. is right?
17:25:47 <hieulq_> if I can convince my boss from the investigation in designate cose base
17:26:04 <hieulq_> trungnv, nah, just an example
17:26:04 <mugsie> it could be, but there is a lot of factors
17:26:09 <mugsie> speed of DB machines
17:26:15 <mugsie> size of data set
17:26:26 <timsim> Amount of automation
17:26:32 <mugsie> what tooling you use for config management / orchestration
17:26:43 <mugsie> steps for upgrade are:
17:26:49 <mugsie> 1. Shutdown Services
17:26:53 <mugsie> 2. Migrate DB
17:27:01 <mugsie> 3. Start new versions of services
17:27:15 <trungnv> yes.thanks
17:27:27 <mugsie> no, on a small system I can probably do that by hand in 45 secs
17:27:30 <mugsie> now*
17:27:59 <mugsie> but in a shipped product, on a customer site it is all about how you do upgrades
17:28:09 <hieulq_> sure
17:28:28 <hieulq_> I have another question regarding our gates now
17:28:37 <mugsie> yup
17:28:50 <mugsie> they are completely broken :(
17:29:09 <hieulq_> do we have some solutions for greening them again?
17:29:48 <mugsie> not right now
17:29:55 <mugsie> we need to debug the failure
17:30:07 <hieulq_> hm
17:30:14 <timsim> It's probably not _super_ difficult, it just requires time. Neither mugsie or myself have been able to find time recently.
17:30:45 <mugsie> there is an issue with the new version of eventlet, and that is about as much as I know
17:30:46 <hieulq_> ok, I and trungnv will try to debug this
17:30:51 <mugsie> please do
17:31:05 <mugsie> it would be a good introduction to the code base
17:31:06 <hieulq_> for getting more familiar with designate
17:31:12 <hieulq_> yeah
17:31:17 <hieulq_> thanks
17:31:26 <hieulq_> no question remaining
17:31:33 <trungnv> thanks
17:31:42 <timsim> Great, we'd appreciate it.
17:31:51 <timsim> Does anyone else want to discuss anything?
17:32:13 <timsim> Going once........
17:32:33 <timsim> Twice........
17:32:59 <timsim> Alright, see you in #openstack-dns
17:33:02 <timsim> #endmeeting