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