16:00:05 <gibi> #startmeeting nova
16:00:05 <opendevmeet> Meeting started Tue Jun 22 16:00:05 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:05 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <opendevmeet> The meeting name has been set to 'nova'
16:00:25 <bauzas> \o
16:00:54 <dansmith> o/ (kinda)
16:01:00 <sean-k-mooney> o/
16:01:35 <elodilles> o/
16:01:41 <gibi> \o
16:02:08 <alistarle> o/
16:02:18 <gibi> #topic Bugs (stuck/critical)
16:02:25 <gibi> No critical bugs
16:02:30 <gibi> #link 21 new untriaged bugs (+7 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:02:43 <stephenfin> o/
16:02:51 <gibi> our backlog is growing so please if you have some time then look at it and triage some bugs
16:03:36 <gibi> is there any specific bug that we need to discuss now?
16:04:10 <sean-k-mooney> gibi: i am pretty sure that https://bugs.launchpad.net/nova/+bug/1933096
16:04:16 <sean-k-mooney> is a bug in ther ci env
16:04:24 <sean-k-mooney> so hopefully we can close that soon
16:04:44 <gibi> sean-k-mooney: cool. thanks for looking into that
16:05:53 <gibi> if nothing else then
16:05:53 <gibi> #topic Gate status
16:05:58 <gibi> Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure
16:06:01 <bauzas> gibi: I'll look at open bugs
16:06:16 <gibi> bauzas: thank you
16:06:23 <gibi> I don't see fresh gate bug in that list
16:06:31 <gibi> last week we merged couple of fixes
16:06:46 <gibi> how do you feel, does the gate improved?
16:06:46 <sean-k-mooney> am any suggestions on who i should ping to move https://review.opendev.org/c/openstack/devstack/+/796826 along in devstack
16:07:06 <bauzas> thanks lyarwood btw.
16:07:13 <bauzas> for the gate failures fixes
16:07:44 <gibi> sean-k-mooney: gmann could be one
16:08:09 <sean-k-mooney> i assume that we are still seeing the intermitant failures due to the agent haning
16:08:31 <sean-k-mooney> so if we can merge that sooner rather then later it should help with gate stablity
16:08:32 <gibi> I was off yesterday and did not push any code today so I don't have the view what is failing ont he gate
16:08:46 <gibi> but I agree that devstack patch is a good step forwa4rd
16:09:17 <gibi> anything else about the gate?
16:10:34 <gibi> Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly
16:10:38 <gibi> placement jobs are green
16:10:47 <gibi> #topic Release Planning
16:10:51 <gibi> Milestone 2 is 15 of July which is spec freeze
16:10:55 <gibi> Spec review day is 6th of July #link http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023083.html
16:11:01 <gibi> anything else about the coming milestone?
16:12:47 <gibi> #topic Stable Branches
16:12:52 <gibi> copying notes from elodilles
16:12:56 <gibi> stable/ussuri is blocked (fix needs to be merged: https://review.opendev.org/c/openstack/nova/+/794675 )
16:13:00 <gibi> other branches should be OK (however, there are quite frequent volume detach failures for example on stable/victoria)
16:13:05 <gibi> stable/ocata branches of nova are EOL, branches are deleted ( https://review.opendev.org/c/openstack/releases/+/795664 )
16:13:08 <gibi> EOM
16:13:25 <elodilles> sorry, I was lost in the ussuri gate fixing patches,
16:13:35 <gibi> the detach failure has a fix on master
16:13:36 <elodilles> i will try to sort it out in the coming days
16:13:59 <gibi> https://review.opendev.org/c/openstack/nova/+/796255
16:14:05 <gibi> this needs to be backported I think
16:14:10 <gibi> hm
16:14:23 <gibi> no\
16:14:24 <gibi> sorry
16:14:32 <gibi> I'm not sure
16:15:28 <gibi> that fix helps with the detach issue on master where we have the new notification based detach
16:15:46 <sean-k-mooney> it would need to be backported to any release using the events?
16:15:56 <sean-k-mooney> but not where we poll?
16:16:12 <sean-k-mooney> so if we backport the events based detach we need to backport both
16:16:30 <gibi> sean-k-mooney: that is my understanding yes
16:16:42 <elodilles> I saw lot of failures in victoria as I said, can it be valid backport there?
16:17:18 <sean-k-mooney> i think its a relitivly safe backport in either case
16:17:36 <gibi> elodilles: the detach modification is pretty huge patch but it does not change external interfaces
16:17:51 <sean-k-mooney> gibi: did we backport your events patch to victoria?
16:17:53 <gibi> so from process perspective it is backportable
16:17:57 <gibi> sean-k-mooney: no
16:18:02 <gibi> I dont think so
16:18:20 <elodilles> anyway, that sound good (except that it's a huge patch :S), I'll add this to my TODO to investigate :)
16:18:29 <sean-k-mooney> so the failure on vicotria are proably not related to OPERATION_FAILED
16:18:44 <gibi> sean-k-mooney: yeah
16:18:45 <sean-k-mooney> elodilles: wehre they OPERATION_FAILED specifcialy or was it just detach failures
16:19:20 <elodilles> well, the usual error: volume ... failed to detach (in XXXX state )  something
16:19:46 <sean-k-mooney> ok then that is likely not related to https://review.opendev.org/c/openstack/nova/+/796255
16:19:50 <gibi> sean-k-mooney: I dont think nova logs the sepcific error code
16:19:53 <elodilles> :-/
16:19:58 <sean-k-mooney> we can review after the meeting if you have an example
16:20:23 <elodilles> sure, thanks!
16:20:25 <gibi> ack
16:20:28 <sean-k-mooney> gibi: we might see it in the libvirt log in the ci run not sure but just a guess
16:20:34 <gibi> ok
16:20:42 <gibi> any other stable related issue?
16:21:16 <elodilles> nothing else i think :X
16:22:37 <gibi> #topic Sub/related team Highlights
16:22:42 <gibi> Libvirt (bauzas)
16:22:45 <bauzas> just one thing, we discussed about https://review.opendev.org/c/openstack/nova/+/769614 about how to help operators to know about a behaviour modification for a libvirt issue
16:23:05 <bauzas> we had some argument about some relnote reno section
16:23:08 <bauzas> but,
16:23:16 <bauzas> eventually, I +Wd the fix
16:23:53 <gibi> bauzas: what is the summary?
16:24:00 <bauzas> do we need to create some better way to tell operators that we no longer verify the cpu topologies ?
16:24:09 <sean-k-mooney> yes just noticed if you really wanted me to update it i was ok with that just wanted you and stephenfin  to agree on a path forward
16:24:26 <bauzas> gibi: this ^
16:24:58 <bauzas> basically, flavors could continue to have the same extraspecs
16:25:06 <stephenfin> bauzas: I'm still not sure what you're asking for. Are you suggesting we drop the 'upgrade' section?
16:25:18 <bauzas> stephenfin: no, not about this
16:25:45 <bauzas> stephenfin: about whether we would need more some kind of documentation for this
16:25:50 <stephenfin> oh, that
16:26:03 <sean-k-mooney> oh ok you were conserened if we needed to document it at all
16:26:09 <sean-k-mooney> not how we did it
16:26:10 <bauzas> yup
16:26:29 <sean-k-mooney> ok i tought you just wanted it in the fixes section so i missed that in your previous comments
16:26:33 <stephenfin> My personal opinion is no. We never documented this behaviour and we never agreed to guarantee it. I wanted to include the release note simply as a courtesy
16:26:39 <bauzas> basically, the flavors would continue to be the same, it's just the libvirt driver that won't longer verify them
16:26:54 <stephenfin> similar to how we announce virt API changes, even though we don't support out-of-tree virt drivers
16:27:16 <stephenfin> I think you've misunderstood things. Nothing changes in what we verify
16:27:21 <sean-k-mooney> well its not about verificaiotn is that we change unspecified behavior to different unspecifed behavior
16:27:27 <bauzas> stephenfin: fair enough, I'm having the same opinion but I'm asking the community here if they have concerns
16:27:34 <stephenfin> yes, what Sean said
16:28:05 <gibi> if we are changing undefined behavior then reno is just an extra, but not at all mandatory.
16:28:06 <stephenfin> we had a hidden behavior where we would try to match the number of guest CPU "threads" to the number of host CPU threads
16:28:25 <stephenfin> but it was hidden. We didn't even know it existed until sean-k-mooney started fixing this bug
16:28:28 <bauzas> yes, just a performance kind of help
16:28:37 <stephenfin> exactly. An optimization at most
16:28:47 <bauzas> okay, any concerns ?
16:28:52 <bauzas> if not, I'm OK
16:28:59 <gibi> I'm Ok too
16:29:20 <gibi> stephenfin, sean-k-mooney: is is settled from your perspective too?
16:29:25 <stephenfin> no issues from me
16:29:33 <sean-k-mooney> yep
16:29:41 <sean-k-mooney> i did not have a stong opiion
16:29:42 <bauzas> k, that's it for me
16:29:50 <gibi> ok, thanks
16:29:57 <gibi> #topic Open discussion
16:30:03 <gibi> there is one topic
16:30:07 <gibi> (wenpingsong) vGPU spec reviewing: as we discussed during ptg, cyborg-managed/nova-managed gpu should have a trait indicating who owns this gpu, thanks for bauzas's comments with different thoughts about the trait. We need to have an agreement on that. https://review.opendev.org/c/openstack/nova-specs/+/780452 (can't attending the meeting due to the time slot, but will check the logs later)
16:30:33 <gibi> as far as I understand we originally suggested the owner traits
16:30:43 <gibi> but bauzas now suggest using separate RC
16:30:49 <gibi> for cyborg managed vgpus
16:30:56 <gibi> this way the trait would not be needed
16:30:56 <sean-k-mooney> both could work
16:31:10 <bauzas> my -1 was just for discussing about it
16:31:25 <gibi> I guess we don't have the use case: Give me a vgpu I don't care if it is cyborg or nova managed
16:31:30 <bauzas> given I was also working on the mdev spec
16:31:40 <bauzas> I thought about it
16:31:43 <sean-k-mooney> owner traits i guess could have upgrade issues
16:31:49 <bauzas> and I'm not sure we need a "nova" trait
16:31:50 <sean-k-mooney> e.g. if you upgrade cyborg first
16:31:59 <sean-k-mooney> without upgrading nova to support owner traits
16:32:07 <bauzas> I know tho we said we would do it at some PTG
16:32:19 <bauzas> so I'm sorry to reopen the can
16:32:44 <sean-k-mooney> well no i think there is a usecase for a nova triat
16:32:51 <sean-k-mooney> or well RP ownwer in general
16:32:56 <sean-k-mooney> not nessiarly a trait
16:33:33 <bauzas> it's the other way of a consumer type :)
16:33:45 <bauzas> something like a inventory type :)
16:33:49 <sean-k-mooney> so its a provider type :)
16:33:58 <bauzas> yeah
16:34:24 <bauzas> tbh, I don't really like us marking traits for things unnecessary
16:34:43 <sean-k-mooney> am would it be better to continue this discsssuon on the spec. was tehre a summary you wanted to give in real time
16:34:51 <bauzas> agreed
16:34:59 <bauzas> not sure we can have a consensus now
16:35:11 <gibi> agreed too, I don't have the brainpower to think this through right now
16:35:12 <bauzas> but I want us to think more about this
16:35:26 <bauzas> and again, I'm sorry to hold a bit the spec
16:35:39 <gibi> no worries
16:35:45 <sean-k-mooney> once we add a trai we cant remove them so we shoudl get this right
16:35:53 <bauzas> but if we are about to be generic, we could also help cyborg I think
16:36:06 <bauzas> sean-k-mooney: unfortunately yes
16:36:34 <sean-k-mooney> unless we used CUSTOM_OWNER i guess we cloud i will try and read the spec again tomorow
16:36:44 <bauzas> maybe it's also the fact that a 'nova' trait seems to me bizarre
16:36:50 <gibi> OK, continue this in the spec
16:37:07 <sean-k-mooney> i dont think we shoudl treat nova as special in placment
16:37:09 <gibi> any other topic for today?
16:37:17 <bauzas> with jay's mind, I would transform this into "I can support 'nova'"
16:37:19 <sean-k-mooney> not form me
16:37:32 <bauzas> gibi: nope, I'm done
16:38:33 <sean-k-mooney> bauzas: well it would mean "i can support consumtion by nova" but that just a detail
16:38:45 <bauzas> sean-k-mooney: that's why I think the name is wrong
16:38:51 <gibi> if nothing else then I close the meeting and you can continue :)
16:38:52 <gibi> #endmeeting