16:00:15 <gibi> #startmeeting nova
16:00:15 <openstack> Meeting started Thu Sep  3 16:00:15 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:19 <openstack> The meeting name has been set to 'nova'
16:00:51 <gibi> o/
16:00:58 <lyarwood> o/
16:01:01 <dansmith> o7
16:01:58 <gibi> lets get started
16:01:59 <gibi> #topic Bugs (stuck/critical)
16:02:02 <gibi> No critical
16:02:09 <gibi> #link 29 new untriaged bugs (-2 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
16:02:28 <gibi> as the release is closing I hope we can all focus a bit more on bug triage
16:02:29 <gmann> o/
16:02:43 <gibi> Is there any open bug that needs special attention?
16:03:09 * bauzas waves late
16:03:27 <artom> o/
16:03:47 <lyarwood> gibi: the focal detach volume bug could use more attention I think
16:03:48 <gibi> if no bugs then
16:03:55 <gibi> lyarwood: yeah
16:04:02 <lyarwood> gibi: but we could cover that in the libvirt section later
16:04:06 <artom> lyarwood, wait, is that related to https://review.opendev.org/#/c/742014/5?
16:04:25 <gibi> no, lets try to get some volunteer to look at that bug
16:04:36 <artom> (We're hitting an issue in whitebox where if we use focal we can't attach volumes)
16:04:40 <gibi> I mean no, don't wait for the libvirt section :D
16:04:51 <gibi> https://bugs.launchpad.net/nova/+bug/1882521
16:04:53 <openstack> Launchpad bug 1882521 in OpenStack Compute (nova) "Failing device detachments on Focal" [High,New]
16:04:56 <lyarwood> artom: no the issues we've seen has been on detach ^
16:05:06 <lyarwood> artom: but I can look at yours as well
16:05:16 * stephenfin wanders in even later
16:05:19 <lyarwood> gibi: FWIW I'm looking at this but I've yet to find anything of value tbh
16:05:35 <artom> lyarwood, I need to look at it anyways, I can analyze and report back
16:05:40 <artom> Good to know it might be a known thing
16:05:47 <gibi> artom: any help is appreciated
16:05:57 <lyarwood> I'll also ask kashyap
16:06:07 <gmann> i saw it hitting on designate testing also but no checked if that is exactly same or someting new
16:07:59 <gibi> I promised in the past to look at it but failed to reach that point in my queue
16:08:03 <gibi> so I won't promise again
16:08:09 <lyarwood> kk I think we can move on
16:08:12 <gibi> OK
16:08:17 <gibi> any other bugs?
16:08:31 <artom> lyarwood, weirdly, I can't find that volume UUID anywhere in the logs :P
16:08:44 <gibi> #topic Runways
16:08:50 <gibi> etherpad #link https://etherpad.opendev.org/p/nova-runways-victoria
16:08:57 <gibi> emoved bp/cyborg-rebuild-and-evacuate as the slot expired and the main implementation is merged, some follow up patches are still open
16:09:03 <gibi> *removed
16:09:22 <gibi> the patches for bp/add-emulated-virtual-tpm are approved and moving through the gate
16:09:31 <gibi> othing is in the queue but I think this is actually a good thing considering that next week is feature freeze
16:09:36 <gibi> *nothing
16:09:40 * gibi fails at copy pasting
16:10:40 <artom> bauzas, you had a thing we wanted to get in, no? I guess it means it's not making it?
16:10:56 <bauzas> I have a patch I'm working on
16:11:01 <bauzas> for the routed networks series
16:11:04 <bauzas> but it's a bit late
16:11:12 <bauzas> if I can provide it tomorrow, people can review
16:11:13 <gibi> we will see next week
16:11:19 <gibi> or tomorrow :)
16:11:22 <bauzas> or we will punt it, meh
16:11:34 <gibi> I also have the sriov attach 75% done
16:11:46 <bauzas> (I finally found a solution for passing the requested networks :) )
16:11:48 <gibi> but I can also accept if it will miss the release
16:11:52 <gibi> bauzas:  \o/
16:12:32 <gibi> is there any other feature that is still open but close to being finished?
16:13:16 <gibi> I take the silence as now
16:13:18 <gibi> I take the silence as no
16:13:25 <gibi> #topic Release Planning
16:13:29 <gibi> next weeks is Milestone 3 which is Feature Freeze
16:13:42 <gibi> release tracking etherpad #link https://etherpad.opendev.org/p/nova-victoria-rc-potential
16:13:48 <gibi> This week is the non client library freeze, os-vif release patch is up #link https://review.opendev.org/#/c/749535/
16:14:25 <gibi> I will talk to sean-k-mooney before I approve it
16:14:42 <gibi> Next week is client library freeze
16:14:44 <gibi> I don't see any open patches on python-novaclient #link https://review.opendev.org/#/q/project:openstack/python-novaclient+status:open+branch:master
16:15:07 <gibi> is there any novaclient change that we need before the release?
16:15:36 <stephenfin> there aren't any microversion changes to nova so nothing mandatory anyway
16:16:10 <gibi> OK, cool
16:16:33 <gibi> I wrote up the Cycle Highlights #link https://review.opendev.org/#/c/749693/ please review it
16:17:24 <lyarwood> ack will do
16:17:38 <artom> It's already merged?
16:17:39 <gibi> and last but not least
16:17:53 <gibi> wao
16:17:56 <gibi> it is merged
16:18:00 <artom> Sean (McGinnis) was quick on the trigger :P
16:18:06 <gibi> now worries
16:18:23 <gibi> just leave your comment on the merged review and I will do a follow up patch
16:19:50 <gibi> so last but not least we need a volunteer to write the release notes prelude for Victoria
16:21:06 <gibi> I will ask again next week :)
16:21:12 <artom> I don't mind, but do we have past examples? And I don't feel like I've been around enough to know wtf is up :/
16:21:16 <stephenfin> I can do the prelude
16:21:25 <artom> Sold! /me retracts himself
16:21:28 <stephenfin> Actually, if artom wants to nvm
16:21:34 <artom> jinx, no u!
16:22:01 <stephenfin> You write. I'll critique mercilessly?
16:22:09 <gibi> Ussuri prelude patch https://review.opendev.org/#/c/721548/
16:22:13 <artom> Wouldn't have it any other way
16:22:31 <artom> (Wait, why did I accept that? I lose on every count)
16:22:35 <bauzas> gibi: I can do
16:22:46 <bauzas> (sorry I was a bit afk)
16:22:51 <bauzas> ah whoops
16:23:20 <artom> stephenfin, I legit have the problem of not knowing what happened well enough, though
16:23:23 <sean-k-mooney> ok so one of the 3 volenters can submit a patch
16:23:29 <gibi> yes, please :)
16:23:29 <sean-k-mooney> and the rest of us can review it
16:23:33 <gibi> sure
16:23:55 <bauzas> remember, the timeline is important, we need to merge it before RC1
16:24:11 <bauzas> or people will kill us with anger
16:24:12 <gibi> I will make sure you won't forget about that
16:24:34 <bauzas> the who is who ?
16:24:38 <bauzas> me or stephenfin?
16:24:51 <bauzas> I don't bother, I wrote a couple of preludes already
16:24:59 <stephenfin> bauzas: you
16:25:02 <lyarwood> haha
16:25:20 <stephenfin> would hate to break the tradition
16:25:24 <bauzas> :)
16:25:30 <gibi> OK then it is sold to bauzas
16:25:33 <gibi> :D
16:25:47 <bauzas> I won't argue.
16:25:51 <gibi> Is there any other release related issue?
16:26:32 <gibi> #topic Stable Branches
16:26:41 <gibi> lyarwood, elod: any news?
16:27:12 <lyarwood> only that we are waiting for https://review.opendev.org/#/c/747360/ to land before cutting a stein release AFAIK
16:27:24 <bauzas> any other +W needed for stable changes ?
16:27:26 <lyarwood> ussuri and train already done thanks to elod
16:27:28 <bauzas> I thought not
16:27:37 <bauzas> ack good :)
16:27:38 <elod> nothing from my side. setuptools released 50.1 ~15hrs ago, that solves the issues with stable branches
16:27:51 <gibi> thanks
16:27:55 <gibi> #topic Sub/related team Highlights
16:27:59 <gibi> API (gmann)
16:28:17 <gmann> update on json to yaml policy file migration
16:28:45 <gmann> oslo side work is merged and released, i will update the nova patch by today - https://review.opendev.org/#/q/topic:bp/policy-json-to-yaml+(status:open+OR+status:merged)
16:29:06 <gmann> i am testing that locally and should be up by an hour or so
16:30:14 <gmann> i think we can make it in m-3 release.
16:30:26 <gibi> let's hope so
16:30:35 <gibi> thanks
16:30:50 <gibi> anything else on the api side?
16:31:15 <gmann> other thing is stephenfin patch which i replied on gerrit.
16:31:31 <stephenfin> Yeah, I was suggesting we find some work to do on the API to justify a microversion
16:31:49 <bauzas> lol
16:31:51 <gibi> please don't blow up the API one week before the FF :)
16:31:58 <sean-k-mooney> or jsut add a microversion that has no chagne to signal the removal
16:32:01 <stephenfin> Purely to make my life easier for the XenAPI deprecation
16:32:01 <gmann> i think it is good sign if no microverison in any release :)
16:32:18 <bauzas> sean-k-mooney: we did it in the past
16:32:18 <gmann> stephenfin: :)
16:32:38 <sean-k-mooney> i assumed we might but i could not recal when
16:32:40 <stephenfin> but as gmann sensibly noted that would require a spec, and I'm not sure it's worth the effort
16:33:01 <sean-k-mooney> then we remove xenapi early next cycle
16:33:03 <gibi> stephenfin: is there an alternative to the bump?
16:33:13 <stephenfin> Yeah, a config option in Tempest
16:33:15 <sean-k-mooney> like 6 weeks form now
16:33:19 <gmann> stephenfin: yeah, i think we can just remove those TODO as changing those status codes is not actually worth
16:33:30 <gibi> sean-k-mooney: that assumes there will be microversion bump in the next release
16:33:45 <gmann> gibi: yeah we can do via config option which is how tempest handle the release wise featrure testing
16:33:51 <gmann> feature
16:34:00 <gibi> OK, that seems like a good alternative
16:34:29 <gibi> anything else on the api side?
16:34:43 <gmann> that's all from me
16:34:46 <gibi> thanks
16:34:47 <bauzas> actually I was wrong
16:35:08 <bauzas> we never used a microversion just for signaling, since we also provided 404s for nova-network
16:35:21 <gibi> Libvirt (bauzas)
16:35:21 <bauzas> so, hands on, folks, please
16:35:27 <bauzas> well,
16:35:33 <bauzas> #link https://etherpad.opendev.org/p/nova-libvirt-subteam
16:35:37 <bauzas> is pretty empty
16:35:48 <lyarwood> yeah I need to add https://review.opendev.org/#/q/topic:bump-libvirt-qemu-victoria there
16:35:51 <bauzas> so, in case folks beg for reviews, please amend ^
16:36:08 <lyarwood> which is looks like it is also blocked by https://bugs.launchpad.net/nova/+bug/1882521
16:36:09 <openstack> Launchpad bug 1882521 in OpenStack Compute (nova) "Failing device detachments on Focal" [High,New]
16:36:14 <lyarwood> even though this is bionic
16:36:22 <lyarwood> but with updated qemu and libvirt versions
16:36:22 <stephenfin> lyarwood: Is that okay to merge now, yeah? You got the Ubuntu issue resolved?
16:36:25 <stephenfin> Ah
16:36:43 <lyarwood> and it's getting really late in the cycle to land something like this tbh
16:36:51 <sean-k-mooney> stephenfin: the issue would affeect centos8 and rhel too
16:37:06 <sean-k-mooney> we should switch
16:37:10 <lyarwood> sean-k-mooney: it should but I can't reproduce on either bionic, focal or f32
16:37:19 <sean-k-mooney> https://opendev.org/openstack/governance/src/branch/master/reference/runtimes/victoria.rst
16:37:22 <lyarwood> on any of them even
16:37:48 <sean-k-mooney> per the govnace resolution the offial supported distro version for ubuntu is 20.04 for victoria
16:38:08 <lyarwood> kk so this is a blocker to the release then?
16:38:13 <lyarwood> https://bugs.launchpad.net/nova/+bug/1882521 that is
16:38:14 <openstack> Launchpad bug 1882521 in OpenStack Compute (nova) "Failing device detachments on Focal" [High,New]
16:38:29 <stephenfin> it sure sounds like it
16:38:35 <lyarwood> phun
16:38:35 <bauzas> yup
16:38:39 <sean-k-mooney> so im not sure it always happens
16:38:55 <stephenfin> (that from someone that's been mostly disengaged from the effort to date, admittedly)
16:39:01 <sean-k-mooney> but its is showing up in the gate periodicly
16:39:09 <gmann> these failing tests are skipped for now in Focal base job migration patches.
16:39:28 <lyarwood> gmann: I really don't think they should be tbh
16:39:29 <gmann> we can test it via unskipping those but they were failing all the time
16:39:30 <sean-k-mooney> ok so we shoudl be able to swap the gate jobs over
16:39:52 <lyarwood> releasing V with this still happening would be wrong tbh
16:40:13 <gmann> lyarwood: yeah i mean just to continue the testing we did skip those test but for completing the migration we should not unskip
16:40:26 <gmann> should unskip
16:40:30 <lyarwood> gmann: is there a central change I can depend on to switch to focal btw?
16:40:33 <sean-k-mooney> ok so it look liek we have to fix this before the release so
16:40:44 <lyarwood> gmann: I'll just drop the bionic UCA stuff and focus on focal
16:40:59 <aarents> o/
16:41:07 <aarents> about libvirt-subteam : I will take care of this one because it just popup on my infra : https://bugs.launchpad.net/nova/+bug/1795747
16:41:08 <openstack> Launchpad bug 1795747 in OpenStack Compute (nova) "libvirtError: unsupported configuration: Found duplicate drive address for disk with target name 'sda' controller='0' bus='0' target='0' unit='0' when try to create an instance with two scsi volumes" [Undecided,New] - Assigned to Arthur Dayne (palagend)
16:41:50 <gmann> lyarwood: you can add DNM oatch on top of this and by unskipping those tests https://review.opendev.org/#/c/734700/
16:41:55 <gmann> DNM patch
16:42:29 <gibi> OK, please continue troubleshooting the focal bug, but lets move on here
16:42:33 <sean-k-mooney> aarents: i tought we fixed that already
16:42:40 <lyarwood> gmann: ack thanks
16:42:53 <bauzas> moving on ?
16:42:57 <aarents> sean-k-mooney: good news
16:43:02 <gibi> #topic PTG and Forum planning
16:43:08 <gibi> The next Forum and PTG is less than 2 months from now
16:43:19 <sean-k-mooney> aarents: we might not have but we change how we enumarte thing to fix a similar issue.
16:43:20 <gibi> please indicate your acceptable PTG timeslots in #link https://doodle.com/poll/a5pgqh7bypq8piew before 7th of September
16:43:38 <gibi> PTG etherped #link  #link https://etherpad.opendev.org/p/nova-wallaby-ptg
16:44:21 <gibi> at the moment there are not much topic there
16:44:28 <gibi> so I cannot judge how much time we need
16:44:34 <gibi> or if we need cross project session or not
16:44:44 <gibi> so please start populating the PTG pad
16:44:57 <gibi> anything else related to the PTG?
16:45:41 <gibi> #topic Open discussion
16:45:47 <gibi> there is one thing on the agenda
16:45:58 <gibi> "Can we support return the reserved_memory and reserved_cpu info when call the list-hypervisors-details api ?"
16:46:19 <gibi> but there is no nick attached so I don't know who added it
16:46:27 <sean-k-mooney> did we always say go check placemtn for that
16:46:32 <bauzas> can i change the question ?
16:46:42 <bauzas> "can we deprecate the os-hypervisors API ?"
16:46:53 <stephenfin> this ^
16:46:55 <sean-k-mooney> well yes that was the resoning for using placement
16:47:05 <sean-k-mooney> we wanted to delete that api
16:47:22 <gibi> I agree, this is returned from placement already
16:47:28 <bauzas> stephenfin: man, you're the king of code cleanups, just fire a change
16:48:06 <gibi> bauzas: I' not 100% sure everything in the os-hypervisor is in placement now
16:48:19 <bauzas> then we need to spec it
16:48:31 <sean-k-mooney> well we need a spec in either case
16:48:33 <bauzas> I can write it for Wallaby
16:48:35 <sean-k-mooney> all api changes do
16:48:49 <gmann> yeah
16:49:00 <bauzas> sean-k-mooney: I know, but... :D
16:49:04 <gibi> OK, I think we are in agreement here
16:49:09 <gibi> any other open discussion topic?
16:49:19 <bauzas> sean-k-mooney: technically, we don't need a microversion for *deprecating* an API
16:50:18 <sean-k-mooney> bauzas: right but we do need a spec to remove it or make any user visable changes
16:50:19 * bauzas adds a TODO for him : write an os-hypervisors API deprecation spc
16:50:33 <bauzas> sean-k-mooney: right, but I only said "deprecate"
16:51:00 <gibi> if nothing else for today then I will let you 10 minutes go early ;)
16:51:05 <gibi> 9
16:51:15 <bauzas> we could have been deprecating the API without a spec and then discuss on a spec (or at the PTG) the next actions for signal or feature parity
16:51:27 <bauzas> gibi: my mouth will love it
16:51:34 <bauzas> thirsty it is
16:51:35 <gibi> bauzas: suggest to add a topic to the PTG etherpad ^^
16:51:40 <gibi> OK
16:51:43 <bauzas> yeah ! 3 topics now !
16:51:48 <gibi> let's finish this
16:51:50 <gibi> :)
16:51:55 <gibi> thank you all for joining
16:51:58 <gibi> #endmeeting