16:00:01 #startmeeting nova 16:00:02 Meeting started Thu Apr 9 16:00:01 2020 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:05 The meeting name has been set to 'nova' 16:00:10 o/ 16:00:17 o/ 16:00:45 o/ 16:00:53 o/ 16:01:04 o/ 16:01:31 o/ 16:01:52 #topic Last meeting 16:01:57 #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-02-16.00.log.html 16:02:07 o/ 16:02:15 anything from the last meeting where follow up is needed? 16:03:10 #topic Bugs (stuck/critical) 16:03:17 no critical bug 16:03:22 #link 111 new untriaged bugs (+3 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 16:03:36 I guess from next week everybody will focus on bugs ;) 16:03:53 is there any bug that needs attention? 16:04:34 triaged here means importance is set and status != new right? 16:04:44 there's a few at the top of the list we can likely move 16:04:56 lyarwood: yeas, basically you verified that this is really a bug 16:05:01 kk 16:05:09 https://wiki.openstack.org/wiki/Nova/BugTriage#Tags 16:05:12 thanks 16:05:13 \o 16:05:36 #topic Gate status 16:05:41 The Gate is in FF mode (i.e. clogged) 16:05:50 * bauzas can't make promises on bug triage but has reasonable expectations for next week 16:05:50 but it feels less clogged than last time 16:05:56 Recently the hit rate of https://bugs.launchpad.net/nova/+bug/1823251 is increased so I re-heated the patch that temporarily disables the unstable tests https://review.opendev.org/#/c/718629/ 16:05:57 Launchpad bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed] 16:06:02 yeah, takes time to get the node for testing 16:06:17 any other gate issue that needs attention? 16:07:14 I've seen several hits around "multiple networks found" and proposed this https://review.opendev.org/716809 but it's the wrong approach 16:07:39 that is, this tempest test involves passing a network during server create, and it's supposed to get that network from creds 16:07:49 but the network is not present in the creds for some reason 16:08:05 could use some help understanding that one 16:08:26 other than that, I can mention that the fix for https://bugs.launchpad.net/nova/+bug/1844929 is approved and I'll be rechecking it through the gate 16:08:28 Launchpad bug 1844929 in OpenStack Compute (nova) "grenade jobs failing due to "Timed out waiting for response from cell" in scheduler" [High,In progress] - Assigned to melanie witt (melwitt) 16:08:40 melwitt: i did not get chance to look into logs, I will do after this FF thngs 16:08:49 gmann: cool thanks 16:09:07 melwitt, gmann: thanks 16:09:14 melwitt: does your cells one have a e-r query to watch for falling hits after mege? 16:09:16 *merge 16:09:21 dansmith: yes 16:09:24 sweet 16:09:37 if I could order popcorn from the empty shelves of the grocery stores, I would. 16:09:51 :P 16:09:57 :) 16:09:58 melwitt: will follow-up on this change tomorrow if needed 16:10:23 #topic Release Planning 16:10:32 happy Feature Freeze day everyone! 16:10:55 we also have the final novaclient release today for Ussuri 16:11:02 I posted an info mail to the ML #link http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014018.html 16:11:12 and started the release TODO etherpad #link https://etherpad.openstack.org/p/nova-ussuri-rc-potential 16:11:35 please review the cycle highlight patch #link https://review.opendev.org/#/c/712498/ as it is also due today 16:11:52 (we can update it later, but the today's version will be used for marketing) 16:12:19 who wants to volunteer for writing a release notes prelude? 16:12:25 I can 16:12:30 bauzas: thanks! 16:12:31 (I'm used to) 16:12:57 I noted your nick on the etherpad 16:13:04 tbc, we need to merge the prelude change before RC1 16:13:13 so we have two weeks for filling it 16:13:24 but I'll start with a proposal and people will be able to comment 16:13:25 bauzas: good, that is plenty of time 16:13:39 (or even co-author if they wish) 16:14:34 gibi: and sure for naming me in the etherpad 16:14:42 gmann pinged me about an FFE for the policy work, lets discuss that at the end 16:14:49 ok 16:15:05 any other thing we need to discuss for FF and the novaclient release? 16:15:45 like I proposed, I'll be around for rechecking tomorrow 16:16:09 I will try to look at the gate time to time during the extended weekend 16:16:10 if people have +Wd changes before tonight, they can ping me for asking a necessary +W if they got merge conflicts in the gate 16:16:22 ^^ +1 16:17:06 if so, please raise your request for fast-approval on your change in https://etherpad.openstack.org/p/nova-ussuri-rc-potential 16:17:51 yeah, one more thing. FFE requests are expected by ML post. We have 2 weeks for RC1 so I feel we need to close the FFE items end of Wednesday next week 16:18:14 and we're on a short week 16:18:18 which means there wont be too much time to argue about FFE requests 16:18:51 * gibi try to set expectations 16:19:07 anything else before moving on to stable status? 16:19:31 do we know if the olso chagnes will land for the policy thing 16:19:38 we can cover that later too 16:19:50 I have not context on that 16:20:07 s/not/no/ 16:20:17 the waring on deprecated default policies 16:20:17 others? 16:20:48 sean-k-mooney: wanring one is done - https://review.opendev.org/#/c/717879/ 16:20:49 gmann i think has patches submitted and requested an oslo FFE for them 16:21:06 sean-k-mooney: new flag for migration is pending - https://review.opendev.org/#/c/717943/ 16:21:12 cool 16:21:54 gmann: do we need follow ups on the nova side for that ^^ ? 16:22:16 if yes, please make a note on the etherpad #link https://etherpad.openstack.org/p/nova-ussuri-rc-potential 16:22:24 I am testing that on gate but due to new config options, flag is set true properly. I tested locally and ot worked 16:22:33 gibi: +1, i will add 16:22:55 gmann: thanks 16:23:52 #topic Stable Branches 16:24:03 lyarwood do we need to release stable/train and stable/stein as we are close to ussuri? 16:24:22 I mean close to have stable/ussuri 16:24:41 gibi: we can but I'd like to flush the queue post M3 16:24:55 good call on flushing the queues 16:24:58 gibi: I'll look into that next week once the gate settles down 16:24:59 lyarwood: agree. 16:25:07 usually good to release stable branches each milestone (if there's enough changes) 16:25:10 we could find bugs on ussuri that 'd drop down the releases 16:25:19 lets flush the queue and release before RC! 16:25:21 RC1 16:25:24 yup ack 16:25:27 thanks 16:25:36 anything else on the stable land? 16:25:58 also, worth saying that we will refuse bugs on ussuri between RC1 and release date 16:26:07 for ussuri I mean 16:26:16 bugs are fine until RC however right? 16:26:23 so, next two weeks are pretty straightforward 16:26:25 unless they're regressions 16:26:30 that ^ 16:26:38 lyarwood: before RC1, yeah any bug is fine 16:26:42 bugs I fine until RC1 if they are regressions or low risk 16:26:47 after RC1, then we branch 16:26:51 ack cool just confirming 16:27:04 after RC1 we only merge bugfixes that warrant a new RC 16:27:07 I mean after RC1 if there's a regression that's grounds for another RC 16:27:17 ^^ +1 16:27:18 yup understood 16:27:53 #topic Sub/related team Highlights 16:28:03 Placement (tetsuro) 16:29:01 API (gmann) 16:29:09 no other things to mention than FFE for policy work which we will discuss at the end 16:29:21 gmann: thanks 16:29:26 #topic Stuck Reviews 16:29:31 nothing on the agenda 16:29:38 do we have stuck review to discuss? 16:30:46 #topic Open discussion 16:30:53 (gmann): FFE for the remaining policy work. 16:30:57 gmann: your turn ^^ 16:32:18 for policy work, we left with few policy. as rough count it is- ~7 policy patches up but not merged + 3 API policies to push patches 16:32:57 and i am thinking to update the deprecated API policy also to be consistent because they are still valid for older version 16:33:23 I can spend time on reviewing those on Tuesday, Wednesday next week 16:33:25 i need more time to finish those. tried my best to push hard since last couple of week but could not finish 16:33:49 gibi: thanks. 16:33:59 gmann: what if we don't do the deprecated part of the work for U? Is the rest still usable? 16:35:03 gibi: yes, that is usable and by default all the new changes (scope and defaults) are not enabled so existing deployment would break 16:35:14 that is what we tested with test cases 16:35:43 you mean "would not break" 16:35:51 alas. hopefully :) 16:36:17 no, it will keep working until they enable scope flag which is disabled by default 16:36:34 OK, so the feauter is disable by default. cool 16:36:57 other, what do you think about granting FFE for the policy work? 16:37:04 others 16:37:09 and if they enable the scope flag enforce_scope and new flag enforce_new_defaults then everything move to new system 16:37:32 I have pros and cons 16:38:11 I feel it's reasonable to assume that the changes are self-contained and the risk is low 16:38:21 my hope is in ussuri we rlease so that operator when they switch the flag to adopt new things all policy get the changes 16:38:53 on the other hand, just by looking at https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+%28status:open+OR+status:merged%29 I can see there is still a massive effort to make for getting all the patches merged 16:38:55 instead of few policy left to have new things 16:39:05 I'm thinking it would be good to have the complete set of new policy defaults together in one release 16:39:15 yeah, +1 16:39:17 and scope types support 16:39:18 and looking at the timings, we are short 16:39:29 the RC1 period is two weeks 16:39:43 and we have this Friday and Monday where people on or off 16:39:44 bauzas: other than first patch which is adding tests cases, changes are very straight forward 16:40:25 straight forward means changing the policy on same line with decision of correct scope and dfaults 16:40:26 so, yeah, I'm intended to say yes, but I have concerns about whether we can merge the whole series by Wednesday 16:40:53 gmann: sure, but like I said to you, there is https://review.opendev.org/718348 that's not merged yet 16:41:12 and if we say we want the whole series by Ussuri, this one necessarly has to work 16:41:47 Wednesday ? 16:42:20 I don't know, I don't want to give a specific deadline 16:42:24 as I meantioned above we have two weeks til RC1 so it would be good to done with FFEs at next Wednesday 16:42:29 I am pretty confident to make all work (other than deprecated APIs) up before Tuesday 16:42:45 but honestly, given 2 weeks of RC1, giving more than one extra week for FFEs seems unreasonable 16:43:19 if we have things up by Tuesday then it might need still couple days to review 16:43:27 honestly, I don't know what to say, stephenfin did most of the reviews so he should speak IMHO 16:43:45 still I tend to agree on granting a FFE due to the impact we can make if we finish 16:43:49 me too 16:43:50 gibi: and considering the gate and rebase things if happens 16:44:07 I'm .9 on this one but i have concerns 16:44:11 No arguments from me, fwiw. They're pretty easy to review 16:44:33 stephenfin: will you have bandwidth for review next week for the policy patches? 16:44:39 who would review besides stephenfin ? gibi, me ? 16:44:47 hah, jinxed 16:44:48 Sure. Just not Monday (I'm off) 16:44:58 yeah I'm also back on Tuesday 16:44:59 johnthetubaguy is the other person that's been doing most of the reviews 16:45:02 johnthetubaguy: review also but he is not online now so cannot say 16:45:06 yeah 16:45:06 I can help review 16:45:11 cool 16:45:15 thanks melwitt 16:45:20 I will be here on monday 16:45:34 then... 16:45:36 anybody else has concerns? 16:46:31 #info FFE is granted for the policy work. We are aiming for finishing it next week. 16:46:43 thanks everyone 16:46:55 gmann: please drop a mail to the ML about it, just for formality. 16:47:11 on including this on cycle highlights page. I am working on adding doc and reno. can we get those today and link to page which is deadline today ? 16:47:19 gibi: yeah. noted 16:47:25 gmann: that looks difficult 16:47:39 we can't tell about things that haven't merged yet, right? 16:47:49 gmann: could you write like 2-3 senteces to me after the meeting that I can put it into the highlight? 16:47:58 ok 16:48:00 and i don't know whether we can patch the highlights later on 16:48:04 bauzas: I'm not sure 16:48:09 bauzas: we can patch 16:48:13 Im sure about that 16:48:14 then 16:48:18 we can patch highlights later but they won't go into marketing materials 16:48:24 let's patch once it's merged, nope ? 16:48:26 the only limit is that the marketing folks will start using the today's version 16:48:27 we can patch later but only things is it can miss if market team pick before modification 16:48:31 yeah 16:48:40 if they pick monday or later then even better 16:49:58 so i can write the 2-3 lines and in parallel work on doc/reno which can be linked later ? 16:49:58 we already merged parts of the policy support 16:50:13 so we can write a generic highlight that is true already 16:50:24 we already have improved policy support, so we wouldn't be lying 16:50:31 yes ^^ 16:50:36 that is what I'm thinking 16:50:41 lol 16:50:42 and the details will be in the reno 16:50:47 the lie would be to say it's complete :) 16:50:56 exaclty 16:50:57 yup, reno ftw 16:51:02 that's what happens when you ask nerds to provide you marketing materials 16:51:12 I don't feel bad about it 16:52:12 OK. I will update the cycle highlight patch today 16:52:26 anything else to discuss? 16:52:39 thanks. I will write the summary and provide to you 16:52:47 gmann: awesome 16:53:53 thanks everyone for supporting it /o\. 16:54:27 if nothing else then I will close the meeting and go to pray for God Zuul a bit 16:54:44 Quick questions - RC1 is in 2 weeks, so that's the time window we have to merge bug fixes? 16:54:54 yes 16:54:57 * artom didn't realize it was this short 16:55:13 And after that it's only regressions, or really bad stuff? 16:55:14 after rc1 the master branch switich to Victoria 16:55:17 artom: between now and RC1 we fix bugs, between RC1 and GA we only fix release breaking bugs 16:55:18 artom: we can merge bugs *after* RC1 but those will be officilally Victoria 16:55:52 if you want them to be Ussuri, hold your breath for a couple of weeks or shout it's a regression fix 16:56:03 between rc1 and relase teh stable branch is till manage by the core team 16:56:22 again, we can merge bugs 16:56:23 once the releae is done normal backports can be don to stable/usuri 16:56:37 they are just on the master branch, which won't be Ussuri 16:56:38 Understood, thanks all 16:56:46 yeah for regressions after RC1 that causes another RC and then the fix backported to stable/ussuri 16:57:03 Aha, so RC1 = master becomes Victoria 16:57:08 yep 16:57:13 (And presumably stable/ussuri is cut) 16:57:21 yes 16:57:39 Understood 16:57:43 i think we are done o/ 16:57:48 OK 16:57:52 thanks you folks 16:57:57 and happy Easter! 16:58:04 ++ 16:58:07 #endmeeting