16:00:10 <gibi> #startmeeting nova
16:00:10 <opendevmeet> Meeting started Tue Sep  7 16:00:10 2021 UTC and is due to finish in 60 minutes.  The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:10 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:10 <opendevmeet> The meeting name has been set to 'nova'
16:00:53 <gibi> o/
16:01:43 <dansmith> o/
16:03:31 <gibi> #topic Bugs (stuck/critical)
16:03:46 <gibi> no critical
16:03:50 <gibi> #link 13 new untriaged bugs (-4 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:03:57 <gibi> we have 1 bugs marked with xena-rc-potential tag #link https://bugs.launchpad.net/nova/+bugs?field.tag=xena-rc-potential
16:04:03 <gibi> https://bugs.launchpad.net/nova/+bug/1942345 fix is going through the gate
16:04:33 <gibi> and we have the placement transaction scope issue https://storyboard.openstack.org/#!/story/2009159 that is being worked on in https://review.opendev.org/c/openstack/placement/+/807014
16:04:54 <gibi> I guess we should mark that as RC critical too
16:05:34 <gibi> I think melwitt's solution is OK but we cannot really make a reproduction test working in the functional env
16:05:40 <gibi> so I started running nova jobs against the fix
16:05:58 <gibi> in https://review.opendev.org/c/openstack/nova/+/807558
16:06:16 <gibi> so far the runs there are not producing the error
16:06:48 <gibi> so probably we will land that fix without the reproduction test
16:07:24 <gibi> is there any other bug we should consider as RC critical?
16:07:37 <dansmith> you're saying that we can't repro the failure in functional,
16:07:51 <dansmith> but that's kinda expected and normal for these kinds of load-based heisenbugs right?
16:07:52 * bauzas is now back and around
16:08:25 <gibi> dansmith: yes, it is a race that is hard to reproduce in a clean env (it needs mysql and it needs parallel transactions)
16:08:29 <bauzas> dansmith: the problem is about mysql
16:08:34 <dansmith> gibi: yeah
16:08:36 <bauzas> hah, jinxed
16:08:55 <bauzas> difficult to write a correct parallel test
16:09:11 <dansmith> yeah, just sounded like gibi was expecting we wouldn't land until we had a repro test
16:09:18 <dansmith> and I'm saying I'd have expected that to be impossible
16:09:26 <gibi> we tried the repro test but we faild
16:09:32 <gibi> so I'm OK to land this without a repro
16:10:13 <bauzas> "I guess we should mark that as RC critical too" > yes, please
16:10:42 <gibi> bauzas: OK, I will. It is already in the tracking etherpad https://etherpad.opendev.org/p/nova-xena-rc-potential
16:11:19 <gibi> so if there is no other bug for the RC then I have a question about https://bugs.launchpad.net/nova/+bug/1942709
16:11:35 <gibi> do we support providing the adminPassword to the guest via the metadata service?
16:11:40 <gibi> I see that the metadata service trying to fetch the password from instance.system_metadata
16:11:43 <gibi> https://github.com/openstack/nova/blob/402fe188b4e7ff76109e8a5ea1f24a5e915eaa09/nova/api/metadata/password.py#L37
16:12:07 <gibi> but as far as I see we dont store the password in instance.system_metadata on master
16:12:20 <gibi> and I was not able to track down changes around this in the git history
16:12:28 * bauzas dunoo
16:13:05 <dansmith> I don't remember if this works with libvirt
16:13:09 <dansmith> I want to say no
16:13:30 <bauzas> we need to look at the code honestly
16:13:52 <gibi> bauzas: please, I got stuck tracking done if it ever worked
16:14:04 <gibi> OK moving on then
16:14:15 <gibi> any other bug we need to discuss?
16:15:19 <gibi> #topic Gate status
16:15:24 <gibi> Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure
16:15:29 <gibi> The nova-next job should be passing now after the new osc-placement release on Friday
16:15:42 <gibi> Allocation deletion conflict still can happen, and it is being worked on in https://review.opendev.org/c/openstack/placement/+/807014
16:15:58 <bauzas> gibi: wish me good luck for finding about the crap in sysmetadata
16:16:07 <gibi> bauzas: good luck! :)
16:16:33 <gibi> I'm not tracking other high frequency bugs in the gate I think we are able to merge code to master
16:16:43 <gibi> Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly
16:16:49 <gibi> placement periodics are green
16:17:11 <gibi> any other gate issue we need to talk about?
16:18:20 <gibi> #topic Release Planning
16:18:24 <gibi> Release tracking etherpad #link https://etherpad.opendev.org/p/nova-xena-rc-potential
16:18:28 <gibi> We are in Feature Freeze.
16:18:41 <gibi> I'm not tracking any FFEs
16:18:57 <gibi> and not tracking any feature patches approved but not landed yet
16:19:06 <gibi> We need to produce RC1 latest on 17th of September which is in less than 2 weeks.
16:19:17 * bauzas raised fist at reno btw.
16:19:30 <gibi> yeah, bauzas writing the reno prelude as you see
16:19:32 <gibi> :)
16:19:32 <bauzas> I can't upload the prelude change because of a weird issue with my rst file
16:19:45 <bauzas> (actually, yaml one)
16:19:57 <gibi> bauzas: push it up and tomorrow I can look at it
16:19:58 <bauzas> hope to fix it sooner than later
16:20:15 <bauzas> gibi: yeah, if I can't find it, I'll throw it to the gate
16:20:29 <gibi> the above etherpad has the links to RC bugs and other TODOs
16:20:35 <bauzas> probably something obvious enough that I missed.
16:20:37 <gibi> any question about the coming release?
16:21:43 <gibi> #topic PTG Planning
16:21:47 <gibi> every info is in the PTG etherpad #link https://etherpad.opendev.org/p/nova-yoga-ptg
16:22:06 <gibi> we don't have much topics yet, but there is still plenty of time
16:22:11 <gibi> If you see a need for a specific cross project section then please let me know
16:22:40 <gibi> any question about the PTG?
16:22:58 <mloza> is there way to set extra_specs to an existing instance without modifying the db?
16:22:59 <gibi> I guess you can turn to bauzas about those as well as he is the PTL elect :)P
16:23:10 <bauzas> could we have a yoga mat for the PTG ? :D
16:23:15 <gibi> mloza: let get back to you at the Open Discussion section
16:23:29 <gibi> bauzas: sure you can, please buy one in decatlon
16:23:33 <gibi> :)
16:23:49 * bauzas misses swag
16:24:13 <gibi> #topic Stable Branches
16:24:20 <gibi> elodilles_pto is off
16:24:25 <gibi> so we don't have status update on the wiki
16:24:32 <gibi> but I guess stable is OK :)
16:24:54 <gibi> any stable issue?
16:24:59 <bauzas> either way, we're entering a pretty quiet period about stable
16:25:27 <gibi> I have one news we pushed stable os-vif releases today
16:25:38 <gibi> https://review.opendev.org/c/openstack/releases/+/807694
16:25:41 <gibi> https://review.opendev.org/c/openstack/releases/+/807696
16:25:44 <gibi> victoria and ussuri
16:25:53 <gibi> anyhow moving on
16:26:05 <gibi> #topic Sub/related team Highlights
16:26:11 <gibi> Libvirt (bauzas)
16:26:13 <gibi> ? ;)
16:26:22 <bauzas> nothing to say
16:26:30 <gibi> #topic Open discussion
16:26:37 <gibi> nothing on the agenda
16:26:42 <gibi> mloza: your turn
16:26:52 <gibi> mloza: do you mean flavor extra_specs?
16:26:59 <mloza> yup
16:27:17 <gibi> you have to resize the vm
16:27:20 <bauzas> embedded flavors can't be changed
16:28:44 <bauzas> unless you resize, indeed
16:29:54 <mloza> right now live migrating is failing because the instance doesn't have extra_specs that the flavor has. I cannot afford to the resize since it incurs a downtime
16:30:33 <dansmith> I don't think that's the reason for a live migration failure, right?
16:31:37 <mloza> i have host aggregates with metadata
16:31:52 <mloza> the metadata is associated to the flavors
16:32:10 <dansmith> I see, so it's the aggregate not the flavor
16:32:23 <dansmith> force migrate should skip that, no? bauzas ?
16:33:05 <bauzas> wait, was distracted, sorry
16:33:05 <gibi> force still runs the scheduler isn't it?
16:33:22 <bauzas> gibi: that depends on the microversion you ask
16:33:25 <gibi> true
16:33:38 <gibi> with old enough microversion you can skip the scheduler
16:33:42 <bauzas> mloza: which exact command do you run ?
16:33:43 <dansmith> I was going to say, I thought there was a way.. I mean that's how you break your AZ right? :)
16:34:23 <gibi> host=<new-host> force=True  microversion <= 2.67
16:34:32 <mloza> openstack server migrate --os-compute-api-version 2.30 --live-migration $id
16:34:49 <bauzas> with no target ?
16:34:59 <mloza> yep with no taret
16:35:02 <mloza> target*
16:35:04 <gibi> you need < 2.30 and you nee d target
16:35:04 <bauzas> if so, this goes to the scheduler
16:35:13 <bauzas> which checks this indeed
16:35:17 <gibi> https://docs.openstack.org/api-ref/compute/?expanded=live-migrate-server-os-migratelive-action-detail#live-migrate-server-os-migratelive-action
16:35:30 <dansmith> the scheduler is doing what you asked, in that case.. not sending the host to the aggregate that requires specific specs
16:35:35 <sean-k-mooney> mloza: if  you dont pass a target then  it will use the az form the request spec
16:35:37 <bauzas> gibi: or you can use 2.30 with the explicit force flag
16:35:52 <gibi> bauzas: yes, or <=2.67 and force=True
16:35:54 <bauzas> (which was deprecated later)
16:35:59 <bauzas> that, yes
16:36:35 <bauzas> I'd say, the contract is granted.
16:36:47 <bauzas> you're asking to migrate something you shouldn't migrate
16:37:02 <bauzas> I know this is weird
16:37:34 <sean-k-mooney> if you for the migration  will that bypas the aggreate extra spec affintiy filter
16:37:42 <sean-k-mooney> i assume that is the one that is blocking the host
16:37:47 <sean-k-mooney> id did not think it would
16:37:49 <bauzas> but if all your hosts are within aggregates that set metadata and you have a filter that verifies this, then you explicitly write a contract
16:38:45 <sean-k-mooney> i guess with force we will just check the host exist and skip everything else with the old microverion?
16:39:05 <sean-k-mooney> that would leave the vm in a state the future move operation will try to move ti out of the aggreate you moved it into
16:39:32 <mloza> got it to live migrate after passing a target host
16:40:01 <gibi> OK, I guess that is solve then
16:40:03 <gibi> :0
16:40:04 <gibi> :)
16:40:17 <gibi> any other topic for today?
16:42:10 <gibi> then lets closed this
16:42:17 <gibi> thanks for joining
16:42:23 <gibi> #endmeeting