Earlier  
Posted Nick Remark
#openstack-nova - 2022-02-03
16:01:37 sean-k-mooney so it not a 100% failure just common
16:01:46 gibi yeah
16:01:47 yuval is there a nova-meeting today?
16:01:53 sean-k-mooney no
16:02:02 sean-k-mooney its on tuseday
16:02:10 sean-k-mooney but you can still bring stuff up any time
16:02:11 yuval ohh ok sorr
16:02:17 gibi which also means passing on non q35 might be just luck :/
16:02:36 sean-k-mooney well maybe but the other jobs seam to be ok
16:03:01 sean-k-mooney i guess we could check logstash and confirm
16:03:15 artom gibi, huh... I mean, it was never 100%, but this does seem like a weird coincidence
16:03:32 artom I wonder if we can check the qemu and/or libvirt versions in ubuntu
16:03:39 artom What changed and when
16:03:44 gibi OK, the tagged attach runs in tempest-integrated-compute and that is nicely green
16:03:54 sean-k-mooney they are in the devstack logs
16:04:05 sean-k-mooney if you want to check but i doubt that is the problem
16:28:35 artom_ So one interesting thing is that in the console logs for a failing test_tagged_attachment, I'm seeing "[ 5.322454] pcieport 0000:00:04.5: pciehp: Failed to check link status"
16:33:44 sean-k-mooney oh
16:33:53 sean-k-mooney so that could be related to the qemu patch
16:33:58 sean-k-mooney realted to state tracking
16:37:29 artom_ I'm going to try and see what's in the console for the passing run on gibi's patch
16:42:54 rosmaita sean-k-mooney bauzas: do you need a pre-yoga-release release of os-brick so you can test lightbits code for nova?
16:43:18 sean-k-mooney rosmaita: yes
16:44:03 sean-k-mooney we do not allow code to changes to merge if they depend of unrelease libs
16:44:07 rosmaita sean-k-mooney: ok, i will propose one today ... hopefully will get released right away, since it's not friday yet
16:44:29 sean-k-mooney well anytime before the non-client lib freeze is technically fine
16:44:31 artom Oh wait, we don't log the console by default, do we
16:44:39 sean-k-mooney but the nova patches wont pass ci until the release is done
16:45:05 sean-k-mooney rosmaita: so as long as there is a 5.2.0 before m3 it shoudl be ok
16:45:18 sean-k-mooney the sonner before m3 the less risk to the nova change
16:46:10 rosmaita sean-k-mooney: ok, we are planning to release os-brick one week early this cycle (so next week)
16:46:25 rosmaita if that would be ok, i won't do a pre-release to avoid confusion
16:46:48 sean-k-mooney ack yuval ^ are you ok with that
16:47:11 sean-k-mooney rosmaita: its release with intermediay so you can do addtional release at any point by the way
16:47:19 sean-k-mooney but next week likely will be fine
16:48:26 yuval yes, got it - we finish the followup til 10 feb - so it will leave window to merge the nova code till 21
16:48:58 rosmaita that sounds good, it would be better with the followup patches merged, i think
16:54:57 spatel sean-k-mooney does multiple pci_alias address allow like this in nova.conf file ? - https://paste.opendev.org/show/812504/
16:56:05 sean-k-mooney you can have multiple alsiases i need to check if its a multiopt like that or a json list or both
16:56:17 sean-k-mooney it should be in our docs but i dont recall off the top of my head
16:56:58 sean-k-mooney spatel: so yes https://docs.openstack.org/nova/latest/configuration/config.html#pci.alias
16:57:17 sean-k-mooney that sould work
16:57:25 spatel nice thanks
17:16:18 gibi bauzas: left some comment for you in the ipless port patch
17:16:25 gibi bauzas: nothing major
18:27:57 opendevreview Merged openstack/placement master: Extra tests around required traits https://review.opendev.org/c/openstack/placement/+/825846
18:28:04 opendevreview Merged openstack/nova master: docs: Add new architecture guide https://review.opendev.org/c/openstack/nova/+/814563
18:51:10 opendevreview Merged openstack/nova master: Add 'hw:vif_multiqueue_enabled' flavor extra spec https://review.opendev.org/c/openstack/nova/+/792356
19:37:02 opendevreview melanie witt proposed openstack/nova master: Raise InstanceNotFound on fkey constraint fail saving info cache https://review.opendev.org/c/openstack/nova/+/826942
20:32:24 admin1 hi .. what does qemu unexpectedly closed the monitor mean during migration ? log snippet here: https://gist.githubusercontent.com/a1git/3029cfd14883531c8ea7b12d0491d8bb/raw/74f57d9ff1f278f79dc0dca685f71508b779d40d/gistfile1.txt
20:33:12 admin1 qemu-system-x86_64: Length mismatch: 0000:00:03.0/virtio-net-pci.rom: 0x40000 in != 0x80000: Invalid argument
20:45:08 opendevreview melanie witt proposed openstack/nova master: Raise InstanceNotFound on fkey constraint fail saving info cache https://review.opendev.org/c/openstack/nova/+/826942
20:48:58 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: Introduce remote_managed tag for PCI devs https://review.opendev.org/c/openstack/nova/+/824834
20:48:59 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add support for VNIC_TYPE_SMARTNIC https://review.opendev.org/c/openstack/nova/+/824835
20:48:59 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: Bump os-traits to 2.7.0 https://review.opendev.org/c/openstack/nova/+/826675
20:49:00 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: Filter computes without remote-managed ports early https://review.opendev.org/c/openstack/nova/+/812111
20:57:50 frickler admin1: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1713490
22:20:06 admin1 frickler .. thanks .. i tried the migration again to another hypervisor with the exact same cpu and it worked without issues .. the original error was between E5-2660 v2 @ 2.20GHz -> E5-2670 v2 @ 2.50GHz .. since it was an upgraded version of the cpu, it should have worked
#openstack-nova - 2022-02-04
11:10:43 gibi sean-k-mooney: hi! could you upgrade my vote from +1 to +2 on https://review.opendev.org/q/topic:bug%252F1952941 ? thanks!
11:11:25 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add support for VNIC_TYPE_SMARTNIC https://review.opendev.org/c/openstack/nova/+/824835
11:11:26 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: Add supports_remote_managed_ports capability https://review.opendev.org/c/openstack/nova/+/827839
11:11:26 opendevreview Dmitrii Shcherbakov proposed openstack/nova master: Filter computes without remote-managed ports early https://review.opendev.org/c/openstack/nova/+/812111
11:12:26 sean-k-mooney[m] gibi: ah the requestspec fix sure
11:12:45 dmitriis doesn't early at startup.
11:12:45 dmitriis gibi: apologies for an extra respin of https://review.opendev.org/c/openstack/nova/+/812111. I moved the addition of the compute capability to a separate change https://review.opendev.org/c/openstack/nova/+/827839 and made an extra check in the whitelist. This way we can check if Libvirt has the right version and reject remote_managed ports if it
11:12:47 sean-k-mooney[m] ill review the series shortly
11:16:04 gibi dmitriis: no worry I will check after lunch
11:16:12 dmitriis gibi: ack, tyvm
11:18:39 opendevreview sean mooney proposed openstack/nova master: [WIP] add healthcheck manager to manager base https://review.opendev.org/c/openstack/nova/+/827844
11:18:39 opendevreview sean mooney proposed openstack/nova master: [WIP] add initial healthcheck support https://review.opendev.org/c/openstack/nova/+/825015
12:10:34 sean-k-mooney stephenfin: by th way im also good with your unittest patch https://review.opendev.org/c/openstack/nova/+/714676 gibi was previously +2 on it
12:10:57 sean-k-mooney i just approved his patches which will conflict with it
12:11:13 sean-k-mooney and rechecked yours
12:11:59 sean-k-mooney so waht i woudl propose is if we need to rebase your mock removal patch we shoudl try and fast approve it when you resubmit to avoid conflict with other patches
12:17:56 gibi dmitriis: left comments in https://review.opendev.org/c/openstack/nova/+/827839
12:19:32 sean-k-mooney artom_: did you put up a patch to skip the flaky test in nova-next
12:19:58 sean-k-mooney if not i might quickly do that
12:20:43 gibi sean-k-mooney: I don't see such patch from artom
12:21:11 sean-k-mooney we are only seeing tempest.api.compute.servers.test_device_tagging.TaggedAttachmentsTest.test_tagged_attachment fail so ill limit it to that
12:21:38 gibi sean-k-mooney: yepp
12:24:02 sean-k-mooney ah https://bugs.launchpad.net/nova/+bug/1959899 is the bug cool
12:24:20 gibi yes
12:24:40 sean-k-mooney i was just looking for it for the topic/commit message
12:35:57 opendevreview sean mooney proposed openstack/nova master: skip test_tagged_attachment in nova-next https://review.opendev.org/c/openstack/nova/+/827851
12:36:37 sean-k-mooney ok ya i think ^ is all that is needed
12:42:49 opendevreview Merged openstack/nova master: Reproduce bug 1952941 https://review.opendev.org/c/openstack/nova/+/820121
12:44:12 gibi sean-k-mooney: thanks
12:44:28 gibi sean-k-mooney: I will fast approve it as soon as zuul is green on the patch
12:52:50 artom_ gibi, sean-k-mooney, I hadn't, so thanks!
12:58:13 opendevreview Attila Fazekas proposed openstack/nova master: Document the floating ip behavior in short https://review.opendev.org/c/openstack/nova/+/827856
13:28:47 dmitriis gibi: looking
13:31:06 tobias-urdin logs https://paste.opendev.org/show/812522/
13:31:06 tobias-urdin i have a weird issue, back in december 2021 a resize that failed, also failed to cleanup /var/lib/instances/_resize directory, when resize was retried now (earlier today) it failed because os.rename got File exists when it tried to rename that https://github.com/openstack/nova/blob/stable/victoria/nova/virt/libvirt/driver.py#L10402 -- see
13:31:33 tobias-urdin the first issue was because of a libvirt issue (out of fd and socket issues)
13:32:33 tobias-urdin don't have logs to understand if for example SELinux blocked the file deletion, does it make sense to insert something that would catch the issue and remove the _resize directory before trying the rename? since the API would ensure there can't be an race condition for resizes
13:34:34 gibi tobias-urdin: do I understand correctly that the original delete of the dir faild and this now prevents the retry of the resize? I think we can robustify nova by retry the delete during the next resize if it sees the stale dir there
13:51:42 tobias-urdin gibi: yes, resize failed because of leftover <uuid>_resize directory in instances directory
14:02:59 opendevreview Tobias Urdin proposed openstack/nova master: Cleanup _resize directory in instances dir on resize https://review.opendev.org/c/openstack/nova/+/827865
14:03:15 tobias-urdin gibi: i guess it could be as simple as ^
14:12:42 gibi tobias-urdin: that could be it, but would be nice to add a test around it

Earlier   Later