16:00:22 <gibi> #startmeeting nova
16:00:23 <openstack> Meeting started Thu Jan  7 16:00:22 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:27 <openstack> The meeting name has been set to 'nova'
16:00:28 <gibi> o/
16:00:32 <dansmith> o/
16:00:39 <artom> ~o~
16:01:00 <stephenfin> o/
16:01:03 <lyarwood> o/
16:02:02 <gmann> o/
16:02:17 <gibi> happy new year :)
16:02:34 <gibi> lets get started
16:02:35 <gibi> #topic Bugs (stuck/critical)
16:02:40 <gibi> no critical bugs
16:02:44 <gibi> #link 17 new untriaged bugs (+10 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:02:57 <gibi> (it is a bit better actually as I triaged some in the meantime)
16:03:11 <stephenfin> I'll take a look later today also
16:03:17 <gibi> cool
16:03:27 <gibi> any specific bug we need to discuss today/
16:03:27 <gibi> ?
16:04:18 <gibi> if not then
16:04:19 <gibi> #topic Gate status
16:04:24 <gibi> gate on master is not blocked
16:04:35 <stephenfin> It's actually looking very stable
16:04:48 <bauzas> whoops
16:04:50 * bauzas waves late
16:05:00 <dansmith> I did see one glance job failure on a test that only runs in multistore mode
16:05:01 <gibi> I had to recheck due to some intermittent package mirror things in grenad hope it was one time
16:05:08 <dansmith> it wasn't on a nova patch, but in a job we run
16:05:31 <dansmith> so I want to dig into that.. it was like a glance test that hung forever I think, just in case anyone sees that
16:05:48 <gibi> dansmith: thanks for the info
16:05:56 <lyarwood> hmm I recall creating a bug for something like that before the break
16:05:59 * lyarwood checks
16:06:11 <gmann> devstack fixes for swift extra requirement are merged swift one is also in gate to merge so this nova fix is green and good to go https://review.opendev.org/c/openstack/nova/+/766171
16:06:43 <gibi> gmann: thanks, we get back the stable status in a bit
16:06:50 <lyarwood> gmann: that's waiting on https://review.opendev.org/c/openstack/swift/+/766214 btw
16:06:59 <lyarwood> and yeah lets talk about stable later
16:07:05 <gmann> yeah. it should pass now but let's wait
16:07:22 <lyarwood> okay I can't find the glance bug but I saw some failures like that on master before the break
16:07:31 <gibi> OK
16:07:35 <dansmith> lyarwood: ack
16:07:45 <gibi> if it becomes freqent the lets file a bug for it
16:07:57 <gibi> until that, lets move on
16:07:58 <gibi> #topic Release Planning
16:08:03 <gibi> Milestone 2 is 22nd of Jan
16:08:10 <gibi> which will be spec freeze for us
16:08:50 <gibi> any other release or deadline relate thing we need to talk about?
16:09:50 <gibi> #topic Stable Branches
16:10:00 <gibi> elod collected status that I will copy now
16:10:04 <gibi> stable gate fixes are progressing, though slowly
16:10:12 <gibi> gate of victoria, ussuri, queens and pike should be OK
16:10:16 <gibi> train fix looks promising as the patches that it depends on (in devstack) are currently on the gate queue - https://review.opendev.org/766171
16:10:21 <gibi> stein patch fails on lower-constraints job (timeout during pip install) - https://review.opendev.org/766487
16:10:26 <gibi> rocky patch fails on lower-constraints job (2 test cases fail, probably due to some dependency is too low) - https://review.opendev.org/766492
16:10:29 <gibi> EOM
16:10:31 <gibi> thanks elod
16:10:49 <lyarwood> Did we want to discuss dropping the LC jobs in stable today?
16:11:01 <gibi> lyarwood: let's discuss it
16:11:05 <gmann> yeah
16:11:37 <gmann> we still have on master right?
16:11:43 <lyarwood> so I'm personally in favour assuming the TC have talked this over with downstream packagers etc?
16:12:01 <lyarwood> gmann: I thought the idea was to drop it everywhere?
16:12:08 <gmann> yeah
16:12:11 <dansmith> I wouldn't assume that, and there seems to still be discussion on that thread as of this morning, right?
16:12:17 <gibi> my viewpoint is that i) it is pretty nightmare to maintain without pip support for lc. ii) but also I see zigo made a point on ML that he sees lc as useful input for packagers
16:12:21 <gmann> I started the thread on this #link http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.html
16:12:40 <lyarwood> right I hadn't sync'd with the thread sorry
16:12:59 <lyarwood> we should let that play out first I guess
16:13:00 <zigo> gibi: I typically cannot take care of many non-openstack dependencies. For example I'm not the maintainer of SQLA...
16:13:05 <stephenfin> can we make the jobs non-voting to fix things in the short term?
16:13:08 <gmann> i have not read the stephenfin reply yet but may be we can discuss on ML more first and then decide ?
16:13:12 <stephenfin> assuming this is breaking the gate
16:13:15 <zigo> I'd be important to test with an older SQLA.
16:13:17 <stephenfin> and let the discussion on the list play out
16:13:33 <lyarwood> stephenfin: yup that's also an alternative
16:13:47 <gmann> stephenfin: making n-v might end up with broken job and no one fixing.
16:13:51 <gibi> stephenfin: I'm not against making the non-voting while we fix / decide on the way forward
16:14:12 <stephenfin> gmann: I mean if it's already broken. If it's currently working, leave well enough alone :)
16:14:15 <gibi> zigo: is it just sqla or are there other important dependencies from your perspective?
16:14:18 <gmann> but why we want to keep it? it is testing in the way it is supposed to
16:14:32 <zigo> gibi: This was just an example out of my mind ...
16:14:37 <zigo> There's more to it, of course.
16:14:40 <gmann> hum ok until it is passing we can keep :)
16:14:50 <zigo> (probably a bad example, as we keep SQLA up-to-date anyways)
16:15:26 <gibi> zigo: would be good to know how heavly you (or other packagers) are dependant on the lc job and the lc file
16:15:45 <gmann> zigo: does not lower cap in requirements.txt help ?
16:16:10 <gmann> those lower cap in requirements.txt are same as constraint in l-c file
16:16:19 <zigo> My workflow is to try as much as I can to update everything, retaining in debian/control only what services are really declaring.
16:16:23 <stephenfin> gmann: Was that directed at me? I'm suggesting making it non-voting in case we decide to keep them, since it'll be less work to fix the job and make voting that to restore the machinery entirely
16:17:01 <zigo> I do expect that if someone says >= 2.3, then I really can use 2.3, though I will *try* to put upload whatever's in the current upper-constraints.txt.
16:17:23 <zigo> Sometimes, due to distro contraints, that's not possible.
16:17:45 <zigo> Like, another software isn't compatible yet with the latest version, so we need to keep something not as new.
16:17:59 <gmann> stephenfin: ok, but i am sure we end up spending same  effort maintaining those irrespective of it is n-v
16:19:58 <gibi> zigo: so if we not provide lc then you have to manually find a working version < uc for the latter case you mentioned
16:20:38 <lyarwood> as noted in the thread this is with the caveat that previously the LC jobs didn't test what was advertised
16:20:42 <zigo> gibi: Hopefully, we aren't talking yet about OpenStack reverting declaring sane dependencies, right?
16:20:43 <gmann> gibi: zigo if we forgot to update requirement.txt for bumping the version which can be case as gate install the latest supported one
16:20:50 <stephenfin> Can we bring this discussion back to openstack-discuss?
16:20:56 <stephenfin> Since we can't decide this unilaterally
16:20:57 <zigo> I mean, we still want to support a *range* of versions for everything ...
16:20:59 <lyarwood> yup I was about to say
16:21:07 <zigo> Otherwise, it's just unmanageable.
16:21:17 <lyarwood> lets see what happens on the thread and we can always make things non-voting in the short term to open the stable gates back up
16:21:28 <gmann> yeah let's discuss on ML
16:21:28 <gibi> zigo: I get your point about needing a range. thanks
16:21:29 <elod> currently in nova we have issue with stein and rocky (train fix will merge soon hopefully), so I also think stephenfin is right, let's move those two maybe as n-v
16:21:31 <stephenfin> RE: stuff we _can_ do, I don't think we should drop fully until we've agreed to do so
16:21:37 <zigo> The issue is, if we stop testing, then that range isn't validated.
16:21:50 <zigo> It's just what we *think* it is, without any assurance of that.
16:21:52 <lyarwood> it never was
16:21:57 <lyarwood> that's the issue
16:22:00 <stephenfin> Also we don't bump constraints on stable so that's not an issue
16:22:05 <stephenfin> Things are working on master
16:22:10 <stephenfin> no need to change to n-v there yet
16:22:23 <lyarwood> kk
16:22:30 <gibi> OK, let's make broken stable lc jobs nonvoting and continue the discussion on the ML
16:22:56 <gibi> I hope we can keep the master lc job runnig so that packagers can use it
16:23:19 <elod> I'll update the patches on stein and rocky if that's ok
16:23:24 <gibi> elod: OK for me
16:23:59 <gibi> any other stable related topic for today before we move on?
16:24:03 <elod> (or maybe separate patches with bandit cap + LC n-v)
16:24:23 <lyarwood> nope not from me
16:24:29 <elod> neither from me
16:24:37 <gibi> #topic Sub/related team Highlights
16:24:42 <gibi> Libvirt (bauzas)
16:24:53 <bauzas> nothing to report, sir.
16:25:01 <gibi> ack thanks
16:25:05 <gibi> #topic Open discussion
16:25:11 <gibi> we have one topic on the agenda
16:25:17 <gibi> (artom/stephenfin/lyarwood) Can https://bugzilla.redhat.com/show_bug.cgi?id=1880273 be a specless bp?
16:25:18 <openstack> bugzilla.redhat.com bug 1880273 in openstack-nova "RFE for OpenStack virtio-scsi multiqueue support in Nova" [Low,New] - Assigned to nova-maint
16:25:45 <gibi> it is the usual question does it need API change? a new config? how big is the impact?
16:25:56 <artom> It's like the NIC multiqueue stuff, but for virtio-scsi
16:26:06 <artom> No API changes (well, image propers and/or flavor extra specs)
16:26:08 <artom> No new config
16:26:19 <artom> Pretty self-containted impact
16:26:34 <lyarwood> assuming we don't also want scheduling support via a compat trait
16:26:41 <bauzas> maybe an upgrade impact ?
16:26:48 <lyarwood> right
16:26:51 <artom> IOW, doesn't affect you if you don't enable that extra spec/image prop
16:27:30 <lyarwood> we don't support LM between new and old computes right so that should remove the upgrade side of it?
16:27:44 <artom> We do...
16:27:48 <dansmith> we don't?
16:27:48 <lyarwood> Only old to new?
16:27:52 <artom> Both
16:27:52 <bauzas> don't we have precedents on extraspec knobs been accepted as specless BPs ?
16:27:58 <dansmith> upstream we have no such requirement, AFAIK
16:28:22 <artom> Is there precedent for "compute host supports this new thing"? Traits?
16:28:23 <lyarwood> hmm I know QEMU/libvirt don't really support that so if they change under us I assumed we wouldn't also support that
16:28:41 <bauzas> what if I'm a user and request this knob ?
16:28:49 <bauzas> thru the imag prop
16:28:51 <lyarwood> ah yeah that's true
16:28:56 <dansmith> we've previously made all the nova code kosher for both directions and I don't think we should stop
16:28:59 <lyarwood> artom: yeah loads
16:29:27 <lyarwood> kk
16:30:02 <lyarwood> so this isn't specless at this point right?
16:30:23 <gibi> if there is upgrade impact and scheduling then a small spec would be good
16:30:38 <gibi> don't have to be long, and I promise I will read it
16:30:47 <lyarwood> stephenfin was going to write it anyway ;)
16:30:48 <bauzas> me too
16:30:49 * lyarwood runs
16:30:59 <gibi> lyarwood: nice :) but then you have to review it :)
16:31:02 * artom backs lyarwood on this one
16:31:02 <bauzas> and I promise to be impartial :)
16:31:05 <lyarwood> I will
16:31:10 <stephenfin> 🙄
16:31:16 <artom> stephenfin, your words dude
16:31:24 <stephenfin> total rat
16:31:34 <stephenfin> :D
16:31:37 <artom> Oh yeah, why do you think I like cheese so much
16:31:38 * lyarwood picks stephenfin up from under the bus
16:31:42 <artom> And betrayal
16:31:42 <bauzas> stephenfin: well, see specs as docs
16:32:19 <bauzas> that's actually a good way for ops to know what's new and how this works, until someone smart enough remebers to update the docs site
16:32:31 <bauzas> :D
16:32:41 <sean-k-mooney> it will basically be https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-virtiomq.html but for virtio-scsi
16:33:05 <bauzas> I've even been told some ops subscribed to the nova-specs RSS feed :)
16:33:17 <sean-k-mooney> the implications changes and upgrade impacts are the same
16:33:39 <bauzas> copy/brain/paste seems acceptable to me
16:33:47 <gibi> me too
16:34:21 <gibi> any other business for today?
16:35:11 <stephenfin> one thing
16:35:14 <gibi> go
16:35:20 <stephenfin> are we doing runways this cycle?
16:35:38 <stephenfin> I assume not, as I don't have a etherpad to hand
16:35:51 <sean-k-mooney> i asked that before the break we have put one or two things in it
16:35:54 <gibi> https://etherpad.opendev.org/p/nova-runways-wallaby
16:36:02 <sean-k-mooney> but we have not been pushing peopel to use it activly
16:36:06 <sean-k-mooney> so we can
16:36:08 <gibi> we have two things in it, no real queue of items
16:36:11 * stephenfin pins that
16:36:20 <stephenfin> I'll stick some stuff in
16:36:23 <sean-k-mooney> stephenfin: its in the nova topic fyi
16:36:27 <gibi> I will add runway as a topic for the agenda
16:36:32 <gibi> of the meeting
16:36:33 <stephenfin> sean-k-mooney: whoops /o\
16:36:39 <stephenfin> ack, cool
16:37:05 <bauzas> heh
16:37:18 <bauzas> I suspect stephenfin coded his own IRC client
16:37:27 <bauzas> hence him not being able to see the chan title
16:37:29 <bauzas> no harm
16:37:32 <gibi> :)
16:37:51 <bauzas> at least, we're fortunate to not suffer from Slack interruptions
16:38:10 <gibi> it there anything else?
16:39:05 <gibi> then thank you all for joining today
16:39:19 <gibi> #endmeeting