| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-09 | |||
| 23:51:47 | openstackgerrit | Merged openstack/nova master: rbd: Only log import failures when the RbdDriver is used https://review.opendev.org/761762 | |
| #openstack-nova - 2020-11-10 | |||
| 00:31:53 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Improve policy doc for supported scope info https://review.opendev.org/762013 | |
| 00:44:02 | openstackgerrit | MaAoyu proposed openstack/os-traits master: bump py37 to py3 in tox.ini https://review.opendev.org/757432 | |
| 01:09:43 | openstackgerrit | Merged openstack/nova stable/victoria: Update pci stat pools based on PCI device changes https://review.opendev.org/761700 | |
| 04:52:40 | openstackgerrit | jichenjc proposed openstack/nova master: Print more helpful info when qemu validation failed https://review.opendev.org/762035 | |
| 06:28:08 | openstackgerrit | Xinran WANG proposed openstack/nova-specs master: SRIOV Enabled Nic Support Specification https://review.opendev.org/742785 | |
| 07:03:47 | openstackgerrit | Xinran WANG proposed openstack/nova-specs master: SRIOV Enabled Nic Support Specification https://review.opendev.org/742785 | |
| 09:05:34 | bauzas | good morning Nova | |
| 09:41:07 | lyarwood | Morning | |
| 10:38:48 | gibi | o/ | |
| 11:22:35 | gibi | "Delay in Elastic Search: Up to date" | |
| 11:22:44 | gibi | hm, did infra cleared the 144 hours of queue? | |
| 11:32:48 | stephenfin | lyarwood, gibi, kashyap: Could you folks cast your eye over https://review.opendev.org/#/q/topic:bp/smarter-usb-devices this week? | |
| 11:34:10 | gibi | added to my list, but it is now behind the cyborg shelve/unshelve patch where I'm really late already. | |
| 11:35:34 | kashyap | stephenfin: On a phone; will queue, sir | |
| 12:04:41 | sean-k-mooney | lyarwood: is "libvirt.libvirtError: internal error: missing block job data for disk 'vda'" something that is currently happening on bionic | |
| 12:05:22 | sean-k-mooney | it looks like that is what is calling the grenade multi node job to fail during a paused live migratrion | |
| 12:07:54 | lyarwood | sean-k-mooney: yeah https://bugs.launchpad.net/nova/+bug/1901739 - I should move this back to open | |
| 12:07:54 | openstack | Launchpad bug 1901739 in OpenStack Compute (nova) " libvirt.libvirtError: internal error: missing block job data for disk 'vda'" [High,Fix released] - Assigned to Lee Yarwood (lyarwood) | |
| 12:09:17 | lyarwood | updated | |
| 12:09:51 | sean-k-mooney | ok do w ehave a workaround e.g moving master to focal for grenade | |
| 12:10:06 | sean-k-mooney | victoria should have been focal anyway right | |
| 12:10:10 | lyarwood | sean-k-mooney: correct | |
| 12:10:24 | lyarwood | sean-k-mooney: and we are going to backport moving these jobs to focal to stable/victoria AFAIK | |
| 12:11:09 | lyarwood | brb | |
| 12:16:49 | sean-k-mooney | oh you removed the parent of the grenade job by mistake but https://review.opendev.org/#/c/742056/ corrects it and movs to v3 | |
| 12:31:56 | sean-k-mooney | lyarwood: could we make the multinode grenade job nonvoting until https://review.opendev.org/#/c/742056/ is merged | |
| 12:32:45 | sean-k-mooney | i think we also will need to use the cloud archive to get libvirt 6.0 for some of the other stable branches | |
| 12:32:53 | sean-k-mooney | that have to run on bionic | |
| 12:34:28 | sean-k-mooney | am i correct in assuming ussuri proably has support for blockdev too or was that added in victoria | |
| 12:34:47 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1901739/comments/6 is the root cause right? | |
| 12:34:47 | openstack | Launchpad bug 1901739 in OpenStack Compute (nova) " libvirt.libvirtError: internal error: missing block job data for disk 'vda'" [High,In progress] - Assigned to Lee Yarwood (lyarwood) | |
| 12:40:10 | sean-k-mooney | i think im going to repopose https://opendev.org/openstack/devstack/commit/7f7f488bc385dd707a3a6d8dae7859bbe72182e5 with victoria instead | |
| 13:06:42 | kashyap | sean-k-mooney: Yeah; the workaround is mentioned in the bug as a comment | |
| 13:07:13 | sean-k-mooney | using libvirt 6.0.0 | |
| 13:07:25 | kashyap | Yep | |
| 13:07:36 | sean-k-mooney | really that just means we are not fixing the issue form openstack and raising the min libvirt | |
| 13:07:41 | sean-k-mooney | which is not really a good thing | |
| 13:07:45 | kashyap | sean-k-mooney: It's using the legacy "-drive" approach; and the modern one ("-blockdev") should fix it | |
| 13:08:00 | kashyap | sean-k-mooney: It's not an OpenStack issue | |
| 13:08:07 | sean-k-mooney | yep i know | |
| 13:08:22 | sean-k-mooney | and i also know we cant force libvirt to only use drive or blockdev | |
| 13:08:30 | sean-k-mooney | which is why we can workaournd it form nova | |
| 13:09:12 | sean-k-mooney | my point is for all deployments that cant use libvirt 6 there is no way for them to work around this | |
| 13:09:28 | sean-k-mooney | well excpet upgrade | |
| 13:09:45 | sean-k-mooney | anmyway i think the victoia cloud archive had 6.0.0 | |
| 13:10:04 | kashyap | Yeah; the whole backports / how far back should upstream support is a tricky thing | |
| 13:10:07 | sean-k-mooney | so im going to bump the version we use in devstack on the older branches | |
| 13:10:25 | kashyap | The answer is: "if you want such backported fixes", use an "enterprise" distro | |
| 13:10:35 | kashyap | (So goes the argument) | |
| 13:10:35 | sean-k-mooney | well no | |
| 13:10:49 | sean-k-mooney | the anser is that libvirt could actully maintain branches and do backports | |
| 13:10:57 | kashyap | Well, they do that | |
| 13:10:59 | sean-k-mooney | they dont which forces distros to do it | |
| 13:11:09 | kashyap | But how you have to backport is an upstream decision | |
| 13:11:27 | sean-k-mooney | yep its just a strange one | |
| 13:11:27 | kashyap | They maintain several "stable" branches | |
| 13:11:39 | sean-k-mooney | very few work the way they do | |
| 13:11:50 | sean-k-mooney | anyway this is simple tweek | |
| 13:12:03 | sean-k-mooney | since it packaged in the uca | |
| 13:12:26 | kashyap | I never claimed it's all perfect :) | |
| 13:12:53 | sean-k-mooney | if it means i dont have to keep rechecking stuff then thats good enough | |
| 13:13:11 | lyarwood | sorry just back from lunch | |
| 13:13:33 | sean-k-mooney | lyarwood: im assuming the zuulv3 patch will take a while to merge | |
| 13:13:45 | lyarwood | hmm that's a good point about the UCA, why isn't the grenade bionic job using it? | |
| 13:13:49 | sean-k-mooney | lyarwood:so im just going to swap to victoria uca which has 6.0.0 | |
| 13:13:56 | sean-k-mooney | it is but train | |
| 13:13:57 | lyarwood | ah | |
| 13:14:02 | lyarwood | right kk | |
| 13:14:14 | sean-k-mooney | we when with train when we tought the other qemu detach thing was a focal issue | |
| 13:14:17 | lyarwood | and yeah either way the multinode grenade change isn't simple | |
| 13:14:21 | sean-k-mooney | that gives us 5.2.0 | |
| 13:14:33 | sean-k-mooney | on tain i think | |
| 13:14:34 | lyarwood | even calling the old scripts is borked as it assumes we are using devstack-gate etc | |
| 13:14:51 | lyarwood | sean-k-mooney: ack | |
| 13:16:25 | lyarwood | http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/bionic-updates/ I don't see Victoria listed here however | |
| 13:18:12 | kashyap | stephenfin: Really nice rework here - https://review.opendev.org/#/c/756551/ | |
| 13:18:26 | kashyap | (Also the commit message :)) | |
| 13:19:19 | sean-k-mooney | i kind fo feel like using tabels in a commit is cheating but ya it explains things well | |
| 13:30:59 | kashyap | sean-k-mooney: Hehe; what else would you use? | |
| 13:31:37 | kashyap | In my books, it's perfectly fair game to see tables in a commit message :) | |
| 13:42:44 | stephenfin | gibi: Have you seen the comment on https://review.opendev.org/#/c/738482/ ? | |
| 13:46:12 | stephenfin | gibi: There's a bug report filed for it here https://bugs.launchpad.net/tripleo/+bug/1903655 | |
| 13:46:12 | openstack | Launchpad bug 1903655 in tripleo "Compute component jobs in master branch are failing with ERROR nova nova.exception.DBNotAllowed: nova-compute attempted direct database access which is not allowed by policy" [Critical,Triaged] | |
| 13:50:53 | gibi | stephenfin: thanks for the notification, I haven't seen it | |
| 13:50:57 | gibi | yet | |
| 13:58:29 | gibi | I have to be on a call, but after It I will look into it | |
| 14:11:48 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: WIP - Image and flavor defined ephemeral storage encryption https://review.opendev.org/752284 | |
| 14:13:15 | lyarwood | ^ reviews welcome on that spec now btw, still WIP but hopefully ready for serious reviews. I'll have PoC code updated this week once I've written the func tests. | |
| 14:56:44 | sean-k-mooney | that does a lot | |
| 14:57:10 | sean-k-mooney | im guessing the duplicaiton is a result of that but havent looke at the test for it in a long time | |
| 15:16:32 | gibi | stephenfin dansmith: I've looked into https://bugs.launchpad.net/tripleo/+bug/1903655 and it seems that tripleoo configures [api_database]/connection for the nova-compute service and that causes that the service version check assumes that we are in a top level controller service which can access the api database https://github.com/openstack/nova/blob/master/nova/utils.py#L1064-L1072 | |
| 15:16:33 | openstack | Launchpad bug 1903655 in tripleo "Compute component jobs in master branch are failing with ERROR nova nova.exception.DBNotAllowed: nova-compute attempted direct database access which is not allowed by policy" [Critical,Triaged] | |
| 15:17:08 | dansmith | gibi: yeah I saw your analysis and I'm sure you're right | |
| 15:17:27 | gibi | is ther a smarter way to decided if we are inside a cell? | |
| 15:17:28 | dansmith | we have other such checks I think, so this is probably just the first time they've hit something fatal to even notice | |
| 15:17:37 | dansmith | no, I think this is a good thing | |
| 15:17:59 | dansmith | although, hmm | |
| 15:18:14 | dansmith | er, yeah, this is just compute that's failing | |
| 15:18:25 | dansmith | so yeah, I think this is good | |