09:02:06 #startmeeting qa 09:02:07 Meeting started Thu Nov 1 09:02:06 2018 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:02:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:02:10 The meeting name has been set to 'qa' 09:02:21 who all here today 09:02:51 PING LIST- gmann, andreaf, masayukig, chandankumar, felipemonteiro, frickler, mbindlish 09:07:20 seems like no one here. 09:07:33 i will be around for any discussion. 09:19:40 oh, dst has ended, I need to update my mental calendar ;) 09:21:01 so if nothing else is on the table, we could shortly discuss how to continue with the bionic migration 09:21:04 frickler: not ended :) i kept it open 09:21:10 frickler: yeah 09:21:21 i have not checked the patch result 09:21:51 my idea that we should merge https://review.openstack.org/610977 , the basic devstack patch, so that other projects can depend on that 09:22:23 I also did some fixes for devstack-plugin-ceph that could be reviewed https://review.openstack.org/611594 09:22:45 they pass the corresponding bionic checks in https://review.openstack.org/#/c/611570/ 09:23:15 I'll update https://etherpad.openstack.org/p/devstack-bionic with that 09:25:58 frickler: how you want to go 1. provide the new jobs and ask project to switch their job with new base job, or 2. test base job with bionic (610977 ) and ask project to alert that existing devstack base jobs are working fine on bionic and we are going to migrate the base job to Bionic so tell us if any risk 09:26:19 the main open question for me is whether we should change the main devstack job that most other jobs inherit from at some point soon, or whether we should wait for most projects to have changed to running devstack-bionic first. the latter option would probably delay the switch to the beginning of the next cycle 09:26:43 gmann: yeah, that's more or less what I was typing in parallel ;) 09:26:53 yea but first one will take lot of effort and time to switch 09:26:57 I think 1. is the safer option 09:27:32 probably I should write up a mail about it and ask for wider feedback on the ml 09:27:48 it is safer but only concern is it will need every project job to change. 09:28:10 frickler: +1, that will be better way. 09:28:49 because that goes with tempest base job also tempest-full etc 09:29:37 I also more or less decided not to touch the legacy jobs, i.e. those autoconverted from zuul v2 09:30:17 make sense. most of legacy job on tempest, nova is migrated but not the same case for all the projetcs 09:32:33 looking at nova and cinder I found that all jobs are either based on tempest or are legacy, so nothing I could update there directly. so either we just switch tempest or we introduce tempest-bionic-* jobs and use them in nova+cinder 09:33:49 i prefer to migrate the tempest-full but after testing the project gate. but again if majority agree on that 09:34:02 asking on ML is better way. 09:34:33 do you know how it was done in past? infra did migrate existign jobs or did migration by providing the 2 set of jobs 09:36:13 I don't remember what was done to migrate from trusty to xenial, I also wasn't infra-root back then 09:36:47 ok, anyways let's check both approach on ML and we can proceed. 09:37:21 i can push few project specific patch also for reference and will add in etherpad 09:37:33 o.k., I'll set up a draft on the etherpad and let you crosscheck before sending it out 09:38:20 #action frickler to send ML to check appropriate approach for job migration to Bionic 09:38:27 frickler: +1 09:38:50 clarkb: ianw: maybe you also have some opinion on this that we should take into account ^^ 09:39:11 or any other devstack reviewers for that matter 09:52:11 frickler: for legacy one, when project start migrating them to zuulv3 they should go on bionic based job (irrespective of either approach we decide) 09:53:02 gmann: yes, I should mention that in the mail, too. but again it would the good to have the devstack patch merged for that 09:53:16 +1 09:53:47 but devstack patch we can merge based on approach we select. if we go for second approach then we do not need to merge this right 09:54:17 I was also just thinking whether for devstack-plugin-ceph we should keep jobs running for both xenial and bionic for the time being. I would amend https://review.openstack.org/611570 accordingly 09:55:08 gmann: I think we still should merge https://review.openstack.org/610977 first and then have a second patch on top of it that switches the devstack job to bionic and creates a devstack-xenial "legacy v3" job 09:55:39 gmann: I can set up the latter for demonstration how it would look like 09:56:32 humm, but we end up undo the changes (other than openstack-two-node-bionic) in 611570 if we go for second approach 09:57:14 frickler: also what is benefit of having both job, xenial and bionic ? 09:58:55 frickler: we can use the unmerged patch also for demonstration. But if you really want to show the merged one then we can merge and undo if we go for second approach. 09:59:12 gmann: maybe it turns out that a project needs more time to migrate to bionic, so we could offer them a fallback 09:59:41 frickler: sure, so that will be our question in ML and then we can merge accordingly. 10:00:04 frickler: i think i mixed 610977 and 611570. 10:00:09 gmann: o.k., so lets wait for feedback on the ml first 10:00:30 * frickler needs to go for another meeting, will check back later 10:00:51 frickler: 611570 lgtm to merge and we can merge that if you can split 610977 with doing openstack-two-node-bionic as alone and other changes as separate 10:02:19 frickler: i see 611570 is only single node. i am reviewing that now 10:04:28 #endmeeting