15:02:47 <egonzalez> #startmeeting kolla
15:02:47 <openstack> Meeting started Wed Oct 31 15:02:47 2018 UTC and is due to finish in 60 minutes.  The chair is egonzalez. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:51 <openstack> The meeting name has been set to 'kolla'
15:02:58 <egonzalez> #topic rollcall
15:03:07 <mgoddard> \o
15:03:31 <spsurya> \o
15:03:45 <chason> o/
15:03:48 <hrw> o/
15:04:41 <egonzalez> #topic agenda
15:04:48 <egonzalez> * Roll-call
15:04:48 <egonzalez> * Announcements
15:04:48 <egonzalez> * Fast Forward Upgrade
15:04:48 <egonzalez> * open discussion
15:05:00 <egonzalez> * placement API split from nova
15:05:07 <egonzalez> missed last item
15:05:18 <egonzalez> #topic Announcements
15:05:44 <egonzalez> hi, thanks for comming the meeting, i dont have any announcement for today
15:05:59 <egonzalez> anyone have any update?
15:06:02 <pbourke> o/
15:06:09 <spsurya> egonzalez:  yes
15:06:28 <egonzalez> spsurya go ahead
15:06:38 <spsurya> I presented session in Open Source India Days
15:06:59 <spsurya> it was related to migration wit Kolla
15:07:22 <spsurya> very much people were interested in Kolla
15:07:43 <egonzalez> nice, good work spsurya
15:07:53 <egonzalez> have a link to slides or video?
15:08:01 <spsurya> Open Source India Days is largest open source event in Asia
15:08:25 <spsurya> egonzalez:  i will share, video is not live
15:08:44 <egonzalez> nice
15:08:45 <spsurya> also available only to attendees
15:09:39 <egonzalez> spsurya thanks for the update
15:09:44 <spsurya> so overall Kolla is in demand with respect to other OpenStack deployment tool
15:09:45 <egonzalez> anything else?
15:10:39 <spsurya> egonzalez: all from my side for announcement
15:11:03 <egonzalez> thats good, thanks spsurya
15:11:25 <egonzalez> lets move to next topic
15:11:28 <egonzalez> #topic Fast Forward Upgrade
15:11:36 <egonzalez> #link https://blueprints.launchpad.net/kolla-ansible/+spec/fast-forward-upgrades-support
15:11:49 <egonzalez> #link https://review.openstack.org/#/c/548101/
15:11:57 <egonzalez> #link https://review.openstack.org/#/c/556568/
15:12:14 <egonzalez> spsurya you added the items to the agenda, wanna hold this topic?
15:12:27 <spsurya> egonzalez: yes
15:12:40 <spsurya> egonzalez: i wanted to bring this to agenda
15:12:49 <spsurya> if i can give hand into it
15:12:56 <spsurya> please let me know
15:13:15 <spsurya> like testing perspective as well as implementation
15:13:22 <pbourke> is this patchset oversimplifying thigns a little?
15:13:42 <pbourke> often there's more steps required when moving between releases than db migrations
15:13:51 <egonzalez> pbourke no is different upgrade path
15:14:17 <egonzalez> for those who are not familiar with fast forward upgrades (FFU) here is the description from the FFU-SIG
15:14:19 <egonzalez> A fast-forward upgrade is an offline upgrade which effectively runs the upgrade processes for all versions of openstack components from your originating version to your desired final version.
15:14:28 <egonzalez> #link https://wiki.openstack.org/wiki/Fast_forward_upgrades
15:14:54 <spsurya> pbourke: please review those patchsets
15:15:26 <egonzalez> as short resume, stop the whole control plane to jump from version to version faster
15:15:27 <spsurya> would be a great help like what else needed otherthan db migration
15:16:19 <spsurya> egonzalez: pbourke  i have pushed spec for FFU with Kolla-ansible in WIP https://review.openstack.org/#/c/614508/
15:16:21 <egonzalez> this  means, only upgrade db schemas for each service in one node, and in last iteration bring all services to the desired version
15:16:44 <pbourke> a good example is the introduction of the nova cell stuff
15:16:57 <pbourke> how would that be handled in this situation
15:17:23 <mgoddard> pbourke: isn't that all done via nova-manage?
15:17:43 <egonzalez> pbourke yep, thats the main issues in that situation, hopefully that release has passed and we already have cells_v2 ;)
15:17:45 <mgoddard> I guess it does wait for things to be registered though
15:17:59 <pbourke> egonzalez: not if I want to fast forward through that release ;)
15:18:05 <mgoddard> have we defined which releases are supported?
15:18:17 <egonzalez> should we backport the ffu feature?
15:18:18 <mgoddard> i.e. from how far back can you FFU?
15:18:20 <pbourke> that's an extreme example though
15:18:26 <pbourke> but there's other stupid sh*t
15:18:44 <mgoddard> FFU support is only required in the target release, right?
15:19:10 <egonzalez> in the case of cells_v2, only thing required to bring up would be nova-api, conductor, placement and one compute
15:19:22 <spsurya> mgoddard: yes, FFU is for higher release
15:19:32 <pbourke> unless there's been advancements since I last looked at this the only reliable way to FFU was to manually install and upgrade each release
15:19:40 <mgoddard> spsurya: higher release?
15:20:00 <mgoddard> oh, I see
15:20:28 <spsurya> mgoddard: means newton--> rokcy           newton-->stein   etc
15:20:58 <mgoddard> I think we need to pick specific examples and define what "stupid sh*t" is required :)
15:21:19 <spsurya> mgoddard: egonzalez https://review.openstack.org/#/c/614508/
15:21:25 <mgoddard> e.g. initially work on queens -> stein
15:21:27 <egonzalez> be aware that the config files for the upgrade should be compatible with all the releases
15:21:30 <spsurya> i will update in problem description
15:21:43 <spsurya> mgoddard:
15:22:09 <egonzalez> for example nova's stein config is not compatible on some option in rocky, so using latest code to jump through various version wont be easy
15:22:45 <spsurya> we need bring the spec in final shape to do target implementation IIUC
15:23:13 <mgoddard> egonzalez: surely only the latest config is used?
15:23:46 <mgoddard> i.e. latest nova-manage and updated nova.conf are used to upgrade the DB
15:23:57 <egonzalez> mgoddard latest code, or only support ffu from stein (if implemented) to newers
15:24:34 <egonzalez> thats not possible, db schemas doesnt allow version skip
15:24:58 <egonzalez> IMHO, we should only support FFU from the version implemented in master to newers
15:25:21 <mgoddard> the DB manage just syncs the DB to the latest supported by the version of nova-manage, right?
15:25:52 <mgoddard> egonzalez: I disagree - I don't see why the source version matters
15:26:17 <mgoddard> to upgrade, the first thing you do is to upgrade kolla-ansible
15:26:28 <mgoddard> so whatever is in the old version doesn't matter
15:26:36 <egonzalez> yes, if only want to upgrade one release
15:26:38 <mgoddard> unless we need to change patterns to make things compatible
15:26:39 <spsurya> mgoddard: egonzalez version should not be the case in FFU while migrating db....me be i have check more
15:26:54 <egonzalez> in case of +2 upgrades, will need to jump through each release
15:28:00 <mgoddard> ok, so we would not actually skip versions, but perform multiple upgrades while offline?
15:28:16 <egonzalez> yes, skip version is not supported by the projects
15:28:43 <mgoddard> hmm, so really this feature is 'offline upgrades'
15:28:55 <egonzalez> IIRC nova said in 2017 denver summit that they wont support version skip
15:29:13 <egonzalez> mgoddard yes, thats how FFU works now
15:29:49 <spsurya> mgoddard: egonzalez IIRC i have seen someone from the community wrote the scripts for FFU while going through each releases, as per my dublin PTG update
15:29:57 <egonzalez> but trying to minimize downtime by only upgrading one api node, do db syncs and then upgrade all other's nodes
15:29:58 <mgoddard> ok, so we could support an offline upgrade to stein
15:30:29 <egonzalez> yes, a FFU would be more like two offline upgrades
15:30:42 <mgoddard> and in T we could support an FFU
15:30:58 <egonzalez> yes
15:31:24 <mgoddard> got it. sorry for being slow :)
15:31:27 <egonzalez> thats why in the ansible code is not called FFU, is offline upgrade to make things clear
15:32:32 <spsurya> egonzalez: +1
15:33:09 <egonzalez> FFU is like a dark definition of a offline upgrade through various releases without bringing all control plane up
15:33:38 <egonzalez> we can discuss this more in the spec
15:33:58 <egonzalez> once more data is added we should add ffu-sig ML to be aware of it
15:35:06 <spsurya> yes
15:35:07 <egonzalez> could we move this discussion into the spec review? we have other item in the agenda to talk about
15:35:14 <mgoddard> +1
15:35:25 <egonzalez> we're finally bussy in a meeting :)
15:35:49 <egonzalez> #topic placement API split from nova
15:36:01 <egonzalez> #link https://review.openstack.org/#/c/613629/
15:36:08 <egonzalez> #link https://review.openstack.org/#/c/613589/
15:36:35 <egonzalez> as you will probably aware, placement api is finally being splitted into its own project
15:36:49 <egonzalez> they will finish the work for this cycle
15:37:39 <egonzalez> for now, they've migrated the api code, main thing missing is the placement-manage which is not implemented yet
15:38:13 <egonzalez> the links in the topic are the starting point of splitting the API from nova roles/images
15:38:38 <egonzalez> please feel free to review and take over work on it
15:39:06 <egonzalez> they need some project to finish the migration so they make sure nothing gets broken in existing evironments
15:39:07 <spsurya> egonzalez: thanks for update
15:39:24 <mgoddard> thanks for starting that work egonzalez. are you saying you don't have time to finish it?
15:39:45 <egonzalez> i have, but if we are working more on it, faster will get done
15:39:56 <spsurya> egonzalez: +1
15:40:00 <mgoddard> cool
15:40:01 <egonzalez> anyway we're blocked until placement-manage is not implemented
15:40:21 <spsurya> yes it should be finished nova side
15:40:22 <egonzalez> we could use dev mode to fetch the placement-manage change
15:41:22 <egonzalez> here's the ML thread
15:41:25 <egonzalez> #link http://lists.openstack.org/pipermail/openstack-dev/2018-October/136075.html
15:41:39 <egonzalez> there you have more information and links to reviews
15:43:04 <egonzalez> any question about this topic or something to add?
15:44:37 <egonzalez> guess not, lets move to open discussion
15:44:45 <egonzalez> #topic open discussion
15:45:07 <egonzalez> anything else to discuss on todays meeting?
15:45:33 <spsurya> how many kolla cores are going to Berlin Summit ?
15:45:38 <mgoddard> o/
15:45:40 <egonzalez> I am
15:46:23 <spsurya> my travel is pending as of now.....waiting for green flag from Org ;)
15:46:42 <egonzalez> best luck spsurya
15:46:48 <egonzalez> pbourke you going?
15:47:02 <spsurya> thanks egonzalez :)
15:48:14 <egonzalez> in berlin i think we will be more than in denver (even not being that much from the core)
15:48:36 <egonzalez> but many contributors
15:48:41 <pbourke> egonzalez: no plans currently
15:48:46 <spsurya> seems so egonzalez
15:48:49 <egonzalez> :(
15:49:35 <egonzalez> anyway, any topic for the meeting or we can move to #openstack-kolla ?
15:51:11 <egonzalez> thank you all for attending the meeting, have a nice day :)
15:51:26 <spsurya> thanks egonzalez mgoddard pbourke for FFU discussion
15:51:32 <egonzalez> #endmeeting