Earlier  
Posted Nick Remark
#openstack-nova - 2020-10-07
16:09:46 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Add support for virtio-based input devices https://review.opendev.org/756552
16:10:18 bauzas zigo: huh, that's horrible
16:10:53 bauzas I have to leave it now but I can take a look at why reno is f*** up tomorrow morning
16:11:38 bauzas my best guess is that since we branched, the current points to wallaby but we forgot to deliver a victoria page
16:11:47 bauzas this should be easy to fix
16:11:56 bauzas zigo: ^
16:14:02 bauzas mmmm, we have merged the necessary tho https://review.opendev.org/#/c/754321/
16:14:04 bauzas gibi: gmann: ^
16:14:35 bauzas lemme try to reproduce it locally
16:15:46 gmann it merged on 5th so reno site should be updated.
16:16:49 gmann in patch generated reno it was fine https://abad4d81dfb03b4f334d-70b013fe9ea05f673313d916271f541a.ssl.cf5.rackcdn.com/754321/1/check/build-openstack-releasenotes/b3856fd/docs/
16:17:58 bauzas yup
16:18:17 bauzas I'm still waiting for my local run to end up but I don't see any problems
16:18:42 bauzas I guess that that's the mirrors which still get stale data
16:21:17 gmann yeah, i think mirroring is the issue. I will check in after some time (in my evening) in case.
16:21:54 bauzas gmann: I don't know who to ping for such cases, this is not managed by infra folks AFAIK
16:22:36 bauzas gmann: but use wisely your TZ card, you should get more people interested in this issue than with my own TZ ;)
16:22:43 bauzas anyway, needs to drop
16:22:55 bauzas will populate the local run result when I'm back
16:23:04 gmann bauzas: sure, i will check with clark
16:23:54 elod bauzas gmann zigo : if i'm not mistaken there's another investigation around the issue, see: https://review.opendev.org/#/c/756553/1
16:24:58 gmann elod: ah, yeah it is issue in publishing only so we can wait for this fix to merge
16:35:01 bauzas gmann: elod: I do confirm everything is OK on my local build
16:35:08 bauzas definitely a publishing issue
16:35:28 bauzas zigo: in the meantime, just build the notes locally (tox -ereleasenotes)
16:35:43 bauzas anyway, bailing out
17:06:58 openstackgerrit Merged openstack/nova-specs master: Make 'Feature Liaison' optional in test https://review.opendev.org/748591
20:08:49 gmann bauzas: elod zigo wait for the next rc tag (which is this week) for release note page fix. reno publish job last ran is on same day victoria branch is cut (https://review.opendev.org/#/c/754319/) so it did not include the changes for victoria. - https://zuul.opendev.org/t/openstack/builds?job_name=publish-openstack-releasenotes-python3&project=openstack%2Fnova
20:11:23 zigo gmann: Thanks !
20:12:13 zigo In fact, I was looking for info about why Nova needs Qemu >= 4 (I was surprised when I started my first compute with Victoria this morning).
20:12:39 zigo And I was wondering if I also need a newer libvirt than 5.0.
20:19:29 gmann zigo: ohk, this is reno for qemu version bump https://review.opendev.org/#/c/746981/9/releasenotes/notes/victoria-libvirt-version-bump-e1a09b3a72ee56a4.yaml
20:20:25 zigo Oh, good, so I wont have to also backport libvirt for Buster ! :)
20:20:29 zigo Perfect.
20:20:38 zigo There's already qemu 5.0 in buster-backports.
20:21:02 zigo The annoying bit, is that it also pulls the Linux kernel from backports, but that's ok-ish I guess.
20:21:18 zigo Just annoying when upgrading the cluster (ie: needs reboot).
20:22:41 zigo I would have very much prefered if Qemu 3.1 could still be in use in Victoria for a last time ...
20:22:53 zigo nv mind...
20:23:30 zigo Can anyone tell me what new feature was needed?
20:49:02 gouthamr o/ hello gibi, nova contributors - i work on manila, and a few of us wanted to discuss virtiofs with you at the upcoming PTG, i've added the topic to https://etherpad.opendev.org/p/nova-wallaby-ptg and will keep it updated with any more material we generate
20:52:06 gouthamr i'm hoping we can avoid an overlap in schedules if this discussion could be accommodated on thursday/oct 29th :)
20:54:26 artom zigo, you mean what caused the 3.1 min qemu version bump?
20:54:39 zigo Yeah.
20:57:06 artom zigo, nothing specific, it looks like: https://review.opendev.org/#/c/695056/
20:57:25 artom There are mailing list discussions linked in that commit message around min versions
20:59:44 zigo artom: This doesn't feel right to me, there's no actual reason specified for the bump ... :/
21:00:18 artom zigo, I don't necessarily disagree (though I don't know enough context to have an informed opinion)
21:00:25 artom But... it is what it is :/
21:04:23 zigo Well, I regret I didn't take part of the discussion, but "oh, it's been a long time we didn't bump ..." is for sure *not* a good reason.
21:07:44 artom zigo, surely there was other stuff as well
21:07:55 artom It removes old code, etc...
21:08:05 artom zigo, anyways, I'm just the messenger :P
21:08:16 zigo :)
#openstack-nova - 2020-10-08
01:53:03 openstackgerrit Rajat Dhasmana proposed openstack/nova master: WIP: Add support of blockCommit when VM is down https://review.opendev.org/756261
04:43:05 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Add functional test for bug 1731668 https://review.opendev.org/756636
04:43:05 openstack bug 1731668 in OpenStack Compute (nova) queens "placement: claim allocations fails with IndexError in _ensure_lookup_table_entry" [Low,New] https://launchpad.net/bugs/1731668 - Assigned to melanie witt (melwitt)
04:43:06 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Use a separate transaction for reading after race https://review.opendev.org/756637
05:48:14 openstackgerrit melanie witt proposed openstack/nova master: Follow up for cherry-pick check for merge patch https://review.opendev.org/756639
07:14:11 gibi dansmith: I'm OK to connect https://review.opendev.org/756534 to the old bp, just add reno for visibility
07:24:09 gibi gouthamr: hi!
07:25:22 gibi gouthamr: thanks for ping
07:26:26 gibi gouthamr: would the manial team needs a dedicated 1 hour slot to discuss this or is it OK If I schedule it to Thursday 13:00-17:00 UTC dynamicall? Is there a preferred time slot during that day for the manial folks?
08:22:47 stephenfin zigo: We bump the minimum version of libvirt regularly to help reduce the conditional soup that is the libvirt driver
08:23:18 bauzas good morning Nova
08:24:38 gibi bauzas: good morning
08:30:23 kashyap stephenfin: I thought the "conditional soup" has reduced quite a bit lately ... a couple of years ago, though. It's all MIN_VERSION_THIS, MIN_VERSION_THAT ;-)
08:53:35 openstackgerrit Jorhson Deng proposed openstack/nova master: optimize the shelve code flow https://review.opendev.org/756665
08:57:10 zigo stephenfin: Thanks, makes sense.
09:11:50 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Only add a USB controller if it's necessary https://review.opendev.org/756549
09:11:50 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Remove support for '[libvirt] use_usb_tablet' https://review.opendev.org/756550
09:11:50 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Rationalize attachment of USB tablet https://review.opendev.org/756551
09:11:51 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Add support for virtio-based input devices https://review.opendev.org/756552
09:12:45 stephenfin gibi: See, it's not just me :-P https://review.opendev.org/#/q/topic:mypy+(status:open+OR+status:merged)
09:13:39 gibi stephenfin: it spreading... :)
09:15:05 gibi anyhow I have no hard problem with mypy I'm still lack the hands on experience to feel confortable.
09:18:17 stephenfin I think that still applies to everyone (I started work on an o.vo extension and quickly gave up). Still, baby steps. I'm interested in seeing how Cinder solve the o.vo problem, if indeed they do
09:21:10 gibi ovo is an interesting challenge. if I would have free time... :)
09:41:30 whoami-rajat__ hi kashyap
09:41:37 kashyap Hi
09:42:11 whoami-rajat__ i had some queries regarding the patch i'm working on https://review.opendev.org/#/c/756261/
09:42:24 kashyap Go for it
09:42:56 whoami-rajat__ the usecase is simple, we create a dependency chain vol1 -> snap1 -> snap2 and we try to delete snap2 from cinder when the VM is off
09:43:38 whoami-rajat__ incase of online blockCommit, nova/libvirt updates the backing_file of snap2 from snap1->vol1 but incase of qemu-img commit
09:43:40 kashyap (Side note: you'd want to use the arrow the other way around to represent the backing files :-) vol1 <- snap1 <- snap2)
09:43:56 whoami-rajat__ oh yep
09:44:05 whoami-rajat__ active file is the last one
09:44:13 kashyap Yes
09:44:15 whoami-rajat__ vol1 <- snap1 <- snap2
09:44:30 whoami-rajat__ anyway, when i try to do it offline using qemu-img commit
09:44:50 whoami-rajat__ the file gets commited snap1 to vol1 but i'm not sure how to update the backing_file of snap2
09:46:29 whoami-rajat__ just for ease of referencing, these are the places where nova does online blockCommit
09:46:30 whoami-rajat__ https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3130-L3131
09:46:36 whoami-rajat__ https://github.com/openstack/nova/blob/master/nova/virt/libvirt/guest.py#L822-L832
09:46:47 kashyap whoami-rajat__: Offline: you can commit snap2 into snap1, and then snap1 back into vol1. What doesn't work for you?
09:47:00 kashyap Do you have a working example to show your problem?
09:48:10 whoami-rajat__ I'm not sure what you mean by working example, we issue ``cinder snapshot-delete snap1`` command from cinder that doesn't work right now
09:48:45 whoami-rajat__ the info send from cinder to nova is the current snap to be deleted and it's backing file only
09:49:52 kashyap whoami-rajat__: Okay, your question is: when doing it offline, once snap1 is committed to vol1, then how do you update the backing file reference of 'snap2' to 'vol1' -- correct?
09:50:08 whoami-rajat__ yep

Earlier   Later