16:00:18 <bauzas> #startmeeting nova
16:00:18 <opendevmeet> Meeting started Tue Jan 24 16:00:18 2023 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:18 <opendevmeet> The meeting name has been set to 'nova'
16:00:24 <bauzas> hey everyone
16:01:02 <dansmith> o/
16:01:35 <gibi> o/
16:01:58 <bauzas> I guess we can start, as we can make it quick
16:02:14 <bauzas> #topic Bugs (stuck/critical)
16:02:15 <elodilles> o/
16:02:24 <bauzas> #info One Critical bug
16:02:38 <bauzas> same than last week
16:02:47 <bauzas> #link https://bugs.launchpad.net/nova/+bug/2002951
16:03:05 <bauzas> AFAICT, gibi's skip patch is now merged, so we can put it to High
16:03:16 <bauzas> fine ?
16:03:28 <bauzas> dansmith's series is on the fly
16:03:36 <gibi> fine
16:03:58 <bauzas> #link https://review.opendev.org/c/openstack/tempest/+/870974 skipping now the failing test
16:04:32 <bauzas> #link https://review.opendev.org/c/openstack/tempest/+/871000 proposal for fixing the test issue
16:04:45 <bauzas> dansmith: can I review it ? looks so
16:05:12 <dansmith> bauzas: you can review whatever you want :)
16:05:17 <bauzas> excellenbt
16:05:20 <dansmith> but yeah need gmann and kopecmartin to hit that I think
16:05:31 <bauzas> yup, can't +2 tempest
16:05:38 <dansmith> oh,
16:05:46 <dansmith> I need to unskip so he can see, I'll do that after this
16:06:00 <bauzas> ok, I can hold then
16:06:06 <bauzas> moving on
16:07:25 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 26 new untriaged bugs (-1 since the last meeting)
16:07:36 <bauzas> thanks gibi for the triage, any bug you wanted to raise ?
16:07:56 <gibi> bauzas: I triaged ~5 bugs, nothing serious popped up
16:08:00 <bauzas> cool
16:08:10 * gibi had not enough time for triage
16:08:40 <bauzas> I think we can easily put the number down when I look at the open ones
16:09:08 <bauzas> gibi: no worries
16:09:20 <bauzas> easy transition :
16:09:22 <bauzas> #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:09:30 <bauzas> melwitt: are you around ?
16:09:34 <bauzas> she's the next in the roster
16:10:02 <bauzas> looks not
16:10:11 <bauzas> no worries, I'll try to reach her later
16:10:27 <bauzas> #topic Gate status
16:10:33 <bauzas> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:10:45 <bauzas> so the gate is still a bit funky
16:10:49 <dansmith> yeah
16:10:57 <dansmith> lots of sporadic fails still
16:11:05 <bauzas> https://bugs.launchpad.net/nova/+bug/2002782 needs help
16:11:36 <bauzas> I'll try to add more logs in some DNM to try to see whether we have more explanations
16:11:50 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state  https://review.opendev.org/c/openstack/nova/+/858384
16:12:27 <bauzas> anything people wanna discuss about it ?
16:12:39 <gibi> I have no extra input to it
16:12:54 <bauzas> gibi: I've seen you updated the bug report, thanks
16:12:58 <gibi> no worries
16:13:03 <gibi> that was part of my triage round
16:13:22 <bauzas> I just triaged it to Confirmed/High fwiw
16:13:53 <gibi> ack
16:14:01 <gibi> I did not want to triage my one bug
16:14:04 <Uggla> o/
16:14:06 <bauzas> https://zuul.openstack.org/builds?job_name=nova-tox-functional&job_name=nova-tox-functional-py310&project=openstack%2Fnova&skip=0
16:14:13 <bauzas> this is wedgy
16:14:29 <bauzas> but at least the gate isn't hold
16:14:49 <bauzas> (assuming we have true positives in that list)
16:15:10 <gibi> filtering that to the gate pipeline is a bit better
16:15:27 <bauzas> true, it avoids the true positives
16:15:29 <gibi> but that does not show patches that are good but fail on check
16:15:36 <gibi> so meh
16:15:54 <bauzas> ideally, we should filter on the right exception :)
16:16:09 <bauzas> hence not with zuul :)
16:16:17 <bauzas> but meh, moving on
16:16:18 <gibi> yeah yeah
16:16:19 <gibi> :)
16:16:28 <bauzas> hear hear
16:16:49 <bauzas> all periodic jobs turn green this week \o/
16:16:50 <bauzas> https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly
16:17:00 <bauzas> #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status
16:17:15 <bauzas> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:17:23 <bauzas> and as a reminder
16:17:28 <bauzas> #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
16:17:49 <bauzas> I haven't looked at the percentage number of blind rechecks since last year
16:18:06 <bauzas> but hopefully, should be super small given I say it literally everyweek, eh ?
16:18:26 <gibi> I did 0 blind one an a ton of proper one :)
16:18:27 * bauzas just hopes anyone working on Nova reads the meeting minutes
16:18:39 <bauzas> :)
16:18:43 <gibi> so at least the statistic will be nice :)
16:18:49 <sean-k-mooney> maybe
16:18:58 <sean-k-mooney> you put the messasge on the next line a few times
16:19:05 <sean-k-mooney> not sure if the script takes that into account
16:19:16 <sean-k-mooney> you did provide a reason in all the ones i saw
16:19:18 * bauzas actually wonders how many of our contributors know we have a weekly meeting, but I side-track
16:19:33 <bauzas> moving on
16:19:39 <bauzas> #topic Release Planning
16:19:47 <gibi> sean-k-mooney: good point, the issue is we have multiple failed jon in a single run :)
16:19:50 <bauzas> #link https://releases.openstack.org/antelope/schedule.html
16:19:58 <bauzas> #info Antelope-3 is in 3 weeks
16:20:03 <bauzas> #link https://blueprints.launchpad.net/nova/antelope All accepted blueprints for 2023.1
16:20:14 <bauzas> use this loudly ^
16:20:47 <bauzas> as a reminder, not all blueprints have specs, so this is the single source of truth for the featurefreeze
16:21:03 <bauzas> and I have a question
16:21:29 <bauzas> should I somehow put something explicit against blueprints that have API impact (ie. a microversion support) ?
16:21:44 <bauzas> in order to ease people's thoughts on what to review
16:22:06 <bauzas> my proposal would be to use the Priority flag which is honestly not in use today
16:22:19 <bauzas> I can't add tags on a blueprint
16:22:21 <sean-k-mooney> i think we have 3 with api changes
16:22:31 <sean-k-mooney> im not sure we should nessisarly priortiese them by default
16:22:39 <sean-k-mooney> but we could
16:22:56 <sean-k-mooney> too basd we cant add a generic tags filed in that view
16:22:56 <bauzas> technically the priority flag would just be a 'flag' for saying this is a api change
16:23:01 <sean-k-mooney> that is what i would prefer honestly
16:23:48 <bauzas> I can modify the blueprint name
16:23:51 <sean-k-mooney> i would perhaps just not track this in launchpad
16:23:59 <bauzas> by adding some [api] prefix
16:24:05 <bauzas> if that helps
16:24:11 <sean-k-mooney> that will break the specs
16:24:19 <sean-k-mooney> what is show there is the name that is used in the url
16:24:21 <bauzas> I don't think so
16:24:22 <sean-k-mooney> not the title
16:24:41 <sean-k-mooney> we have a tox target
16:24:48 <bauzas> the link is made on the link, not on the title
16:24:52 <sean-k-mooney> to move implemtned blueprints in teh specs repot
16:25:04 <bauzas> I know, I was referring to this script
16:25:13 <sean-k-mooney> the first one in the list is https://blueprints.launchpad.net/nova/+spec/ephemeral-storage-encryption
16:25:27 <sean-k-mooney> what we see for bluepint is the bit acter spec/
16:25:27 <bauzas> and iirc (because I used it), we map blueprints with specs using the bp link, not the bp title
16:25:42 <bauzas> we lookup the bp link in the spec file
16:25:44 <sean-k-mooney> no its based on the name of the file in the specs repo
16:25:45 <bauzas> and then we pull it
16:25:58 <sean-k-mooney> we are not parsing it out if i recall
16:26:04 <bauzas> anyway, let's not discuss that much
16:26:06 <sean-k-mooney> anyway i woudl prefer not to add [api] to it
16:26:25 <bauzas> I can do like every cycle and write an etherpad
16:26:28 <sean-k-mooney> lets just put them in an etherpad
16:26:36 <sean-k-mooney> yep
16:26:36 <bauzas> and I guess this is what I'll end up with
16:26:52 <bauzas> ok
16:27:08 <bauzas> #action bauzas to create an etherpad for tracking blueprints and their progress
16:27:15 <bauzas> there we go
16:27:49 <bauzas> #info As a reminder, Feature Freeze is in 3 weeks, be sure your patches are up to review sooner than later
16:28:11 <bauzas> moving on
16:28:18 <bauzas> #topic Review priorities
16:28:25 <bauzas> #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)
16:28:30 <bauzas> #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review
16:29:36 <bauzas> which is interesting in order to make sure we don't overlap cores's bandwidth by having the vast majority of cores looking at the same feature patches while we're so close to the feature delivery deadline
16:29:40 <bauzas> this is said.
16:30:04 <bauzas> #topic Stable Branches
16:30:14 <bauzas> elodilles: happy to pass the mic to you
16:30:22 <elodilles> #info stable branches seem to be unblocked / OK back till wallaby
16:30:30 <elodilles> #info ussuri and train might be broken ('Could not build wheels for bcrypt, cryptography' errors)
16:30:43 <elodilles> at least i saw some failures like that ^^^
16:30:51 <zigo> Can we talk a little bit about CVE-2022-47951 / OSSA-2023-002 ? That's related: I'm trying to backport the patches up to Rocky...
16:31:37 <elodilles> rocky is End of Life already from nova perspective
16:31:44 <bauzas> zigo: if you don't mind, let's discuss this properly in the open discussion
16:31:48 <zigo> Ok.
16:32:03 <bauzas> elodilles: thanks for thze summaru
16:32:06 <gibi> isn't that a private bug we should not talk about publicly yet?
16:32:09 <bauzas> summary* even
16:32:14 <bauzas> gibi: this is public now
16:32:15 <dansmith> gibi: public as of an hour ago
16:32:18 <bauzas> since 1600UTC
16:32:23 <gibi> dansmith: ahh, OK then
16:32:27 <zigo> Since 15:00 UTC
16:32:44 <bauzas> stupid French TZ which confuses me
16:33:21 <bauzas> elodilles: damn about ussuri and train, ping me tomorrow if you wish, I could try to look at the problems
16:33:33 <bauzas> sounds vaguely familiar
16:33:41 <elodilles> bauzas: ack, thanks, I'll try to look into it, too
16:33:54 <elodilles> though it's not familiar to me O.o
16:34:01 <bauzas> I'm pretty sure we had the same issues in the past
16:34:03 <elodilles> anyway, last but not least:
16:34:07 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:34:18 <elodilles> i've added it to the pad ^^^
16:35:05 <elodilles> bauzas: if you remember something regarding this error then it would be awesome :)
16:35:06 <bauzas> cool
16:35:46 <elodilles> i think that's all from me
16:35:50 <bauzas> ack
16:36:00 <bauzas> #topic Open discussion
16:36:06 <zigo> Now? :)
16:36:18 <bauzas> no items in the agenda
16:36:22 <bauzas> zigo: so, your turn
16:36:27 <zigo> I've tried backporting to Train the official patch, though for Train, it would need these to be backported (in this order if I'm not mistaking):
16:36:27 <zigo> I5ac03f923d9d181d22d44d8ec8fbc31eb0c3999e If878a023c69f25a9ea45b7de2ff9eb1976aaeb8c I56676713571e79f05ee3f0bffc5da8386e02c5d4
16:36:28 <zigo> Can someone help? Or is it out of scope of the team?
16:36:36 <bauzas> (the volume detach issue, we can discuss it later)
16:36:53 <bauzas> zigo: ideally, gerrit links may help :)
16:37:15 <zigo> https://review.opendev.org/c/openstack/nova/+/706897
16:37:28 <zigo> https://review.opendev.org/c/openstack/nova/+/710239
16:37:39 <zigo> https://review.opendev.org/c/openstack/nova/+/711679
16:38:05 <zigo> I tracked them using "git blame" and didn't try doing a backport of them to Train though ...
16:38:06 <elodilles> so this is fixed in Ussuri and newer
16:38:16 <zigo> Yeah, Ussuri and up are fine.
16:38:34 <bauzas> sec
16:38:34 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state  https://review.opendev.org/c/openstack/nova/+/858384
16:38:35 <elodilles> so from upstream perspective Train is the only target
16:38:38 <bauzas> we have a series up
16:38:40 <zigo> But Train and before would need either such a backport, or something else to get the VMDK extended infos.
16:38:45 <bauzas> that's proposed to fix the CVE
16:39:01 <bauzas> oh, this is down to yoga
16:39:32 <elodilles> zigo: Nova's stable/stein and stable/rocky is End of Life already
16:39:57 <bauzas> I guess zigo wants at least Train
16:39:58 <elodilles> so that needs to be handled downstream as branches are deleted already
16:40:04 <bauzas> correct
16:40:05 <zigo> elodilles: Yeah, but Debian is doing LTS for Rocky, so I will need to do the patch backport. And so probably is Red Hat for its customers, etc.
16:40:08 <bauzas> those are tagged eol
16:40:26 <zigo> Ok, so out of scope for the team, and I'm on my own ... :P
16:40:40 <dansmith> zigo: you might need something more bespoke if backporting all the dependencies isn't possible
16:40:51 <zigo> Oh, also, when I'm at it ...
16:40:57 <zigo> This also need another patch in oslo.utils
16:41:10 <dansmith> but it is clearly out of scope for us, which doesn't necessarily mean we won't help you, but...
16:41:36 <zigo> Ok, thanks. :P
16:42:20 <zigo> FYI, that's the oslo.utils patch that I backported already: https://review.opendev.org/c/openstack/oslo.utils/+/706880
16:42:33 <zigo> That fixed one of the unit tests...
16:42:33 <dansmith> so with that,
16:42:42 <zigo> (for train and below)
16:42:50 <bauzas> dansmith: I guess there is no plan to backport https://review.opendev.org/c/openstack/nova/+/871624 downer than Yoga ?
16:42:51 <dansmith> even if you don't backport the privsep stuff, you should have the data you need I think
16:43:03 <dansmith> bauzas: I backported to xena,
16:43:13 <dansmith> I think because xena was still in scope at the time and I was asked
16:43:43 <dansmith> it was the only one with a conflict, trivial because of the config
16:43:46 <bauzas> I'm actually surprised than backporting requires pulling more deps
16:44:07 <dansmith> because of privsep conversions
16:44:18 <dansmith> this was run within nova before IIRC
16:44:18 <bauzas> dansmith: mmm, OK, can't see it proposed in the list of cherry-picks of https://review.opendev.org/c/openstack/nova/+/871624
16:44:27 <dansmith> and probably not with json output or something
16:44:35 <dansmith> bauzas: https://review.opendev.org/c/openstack/nova/+/871622
16:45:03 <bauzas> I'm fucking blind
16:45:08 <bauzas> it's on the list
16:45:17 * bauzas facepalms
16:45:17 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state  https://review.opendev.org/c/openstack/nova/+/858384
16:45:20 <sean-k-mooney> that does not need any dep changes does it
16:45:45 <bauzas> after being deaf when dansmith speaks, I'm now blind
16:45:53 <dansmith> sean-k-mooney: not package deps, dependent patches
16:45:56 <bauzas> correct
16:46:06 <bauzas> but should be honestly minimal
16:46:13 <bauzas> the patch itself is well self-contained
16:46:25 <dansmith> but listen to what zigo is saying
16:46:30 <sean-k-mooney> but it does not have depend on so you mena we need to backprot each branch or changes in other repos
16:46:40 <dansmith> the information we need was not being exposed out of oslo utils before the patch he referenced
16:46:59 <sean-k-mooney> ok then thats kind of a problem
16:47:11 <sean-k-mooney> the olso backports would have to happen first
16:47:29 <dansmith> I don't think he's suggesting it upstream
16:47:31 <sean-k-mooney> and we would need to be able to work with older oslo
16:47:40 <opendevreview> Merged openstack/nova master: Make tenant network policy default to PROJECT_READER_OR_ADMIN  https://review.opendev.org/c/openstack/nova/+/865071
16:47:43 <dansmith> he's talking about old and crusty packages debian is keeping on life support
16:48:00 <bauzas> oh
16:48:08 <sean-k-mooney> ok we can propably talk about this out of the meeting
16:48:15 <bauzas> that's gonna be fun then
16:48:24 <dansmith> yes, especially since it's out of our support scope, very clearly
16:48:41 <sean-k-mooney> https://review.opendev.org/c/openstack/oslo.utils/+/706880  is in ussuri and above
16:48:49 <dansmith> he's talking about rocky
16:48:56 <sean-k-mooney> so i think train is the only supported release without it
16:49:13 <sean-k-mooney> dansmith: right but we have one release that does not have the oslo patch
16:49:14 * dansmith wonders if everyone else is able to read all the messages in this channel
16:49:32 <dansmith> sean-k-mooney: who is we? not upstream openstack
16:49:41 <zigo> I don't suggest it upstream, just trying to share my findings at the moment (I don't have any blockers ... yet, if I do I'll let you know).
16:49:42 <sean-k-mooney> we still supprot train for nova
16:49:52 <sean-k-mooney> and https://review.opendev.org/c/openstack/oslo.utils/+/706880 is not in it
16:50:00 <dansmith> elodilles: ?
16:50:10 <zigo> Rocky, I haven't started working on it yet...
16:50:12 <sean-k-mooney> based on the gerrit included in output
16:50:57 <zigo> sean-k-mooney: Correct. (but not really a pb for me...)
16:51:43 <sean-k-mooney> anywya lets loop back to this after the meeting
16:52:06 <sean-k-mooney> if we need it for train then we can backport it to train in oslo
16:52:13 <sean-k-mooney> but there are plenty of branches to get through first
16:52:16 <bauzas> is it me or there was a typo in the oslo.utils patch ? https://review.opendev.org/c/openstack/oslo.utils/+/706880/4/oslo_utils/imageutils.py#88
16:52:50 <sean-k-mooney> not that i see
16:52:53 <bauzas> appened ?
16:53:28 <sean-k-mooney> its a list so i think that valid
16:53:44 <bauzas> I know I'm not a python expert, but I didn't know that a list object was having an 'appened' method
16:53:48 <sean-k-mooney> https://docs.python.org/3/tutorial/datastructures.html#more-on-lists
16:53:49 <bauzas> append, eyes
16:53:59 <sean-k-mooney> """Add an item to the end of the list. Equivalent to a[len(a):] = [x]."""
16:54:08 <bauzas> append, yes
16:54:14 <bauzas> appened, doesn't exist
16:54:22 <sean-k-mooney> oh
16:54:46 <bauzas> which tends me thinking this patch is nice but unsufficient
16:55:06 <sean-k-mooney> ya thats wrong i think but i shoudl not try and spot typos :)
16:55:19 <sean-k-mooney> that presumably was fixed
16:55:27 <bauzas> correct, probably in a fup
16:55:39 <zigo> Well, in this specific case, the code is executed in the format == 'json' path, so it *is* enough ... (but still wrong in that other case)
16:55:45 <bauzas> so it would require the fup to be dragged down too
16:56:15 <sean-k-mooney> aparenlty not https://github.com/openstack/oslo.utils/blob/stable/ussuri/oslo_utils/imageutils.py#L89
16:56:19 <bauzas> zigo: correct, the bug is only on the string definition
16:56:25 <zigo> Well, stable/zed has the typo ... :/
16:56:28 <bauzas> when you str()
16:56:34 <bauzas> or you print
16:56:48 <bauzas> so, technically, you don't need the fix
16:56:51 <sean-k-mooney> https://github.com/openstack/oslo.utils/commit/d49d5944824f15d00e04e1b9c7f8c3b03b440c95
16:57:01 <sean-k-mooney> it was fixed 2 months ago
16:57:02 <bauzas> anyway, the meeting is close to the end
16:57:15 <bauzas> how to wrap up on this ?
16:57:31 <dansmith> I suggest #endmeeting
16:57:35 <sean-k-mooney> +1
16:57:38 <elodilles> :)
16:57:49 <bauzas> then
16:57:54 <bauzas> thanks all
16:57:58 <bauzas> #endmeeting