| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-03-02 | |||
| 20:03:37 | sean-k-mooney | we expect q35 to only be enabled in nova next currently | |
| 20:04:29 | clarkb | ah maybe we didn't jump that far ahead. We definitely had to move the machine type ahead to boot centos 9 | |
| 20:04:47 | sean-k-mooney | clarkb: you should not have too | |
| 20:04:54 | sean-k-mooney | centos 9 shoudl boot fine with pc | |
| 20:05:40 | sean-k-mooney | clarkb: do you have any link to that change | |
| 20:05:42 | clarkb | ah we bumped the cpu model not the chipset | |
| 20:05:47 | sean-k-mooney | ah right | |
| 20:05:51 | clarkb | e06d954229fc4fca827105f5bb0809a19075d590 | |
| 20:05:53 | sean-k-mooney | to nehelm | |
| 20:05:55 | clarkb | yes | |
| 20:06:01 | sean-k-mooney | ya that is differnt | |
| 20:06:03 | sean-k-mooney | that is fien | |
| 20:06:15 | clarkb | Q35 is older than nehalem though | |
| 20:06:34 | clarkb | But I guess those things don't move in lockstep when it comes to virt | |
| 20:06:52 | sean-k-mooney | q35 is basicaly the motherboard | |
| 20:07:01 | sean-k-mooney | rhather then cpu | |
| 20:07:07 | sean-k-mooney | but ya they are independent | |
| 20:07:10 | clarkb | right but the era it comes from is pre nehalem | |
| 20:07:17 | sean-k-mooney | ya | |
| 20:07:21 | clarkb | nehalem was ~2021 and q35 was ~2007 | |
| 20:07:24 | clarkb | er 2012 | |
| 20:07:29 | clarkb | too much typing 2021 last year | |
| 20:07:32 | sean-k-mooney | :) | |
| 21:33:20 | ade_lee_ | sean-k-mooney, trying centos-9 -- lets see how that goes .. https://review.opendev.org/c/openstack/tempest/+/831607/ | |
| 22:37:38 | melwitt | gmann: just a heads up that the following devstack and tempest changes are dependencies for enabling unified limits test coverage in nova-next https://review.opendev.org/q/topic:bp/unified-limits-nova+AND+is:open+AND+(project:openstack/devstack+OR+project:openstack/tempest) | |
| 23:50:08 | gmann | melwitt: ack, I will review tomorrow | |
| 23:53:38 | melwitt | thanks gmann | |
| #openstack-nova - 2022-03-03 | |||
| 07:30:40 | gibi | dmitriis, sean-k-mooney: I made a fix for the func test pci device issue in https://review.opendev.org/c/openstack/nova/+/829248/4/nova/compute/resource_tracker.py let me know what you think. I'm happy to split that patch up if needed | |
| 10:25:51 | opendevreview | ribaudr proposed openstack/python-novaclient master: Microversion 2.91: Support specifying destination host to unshelve https://review.opendev.org/c/openstack/python-novaclient/+/831651 | |
| 10:50:59 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/yoga: Update .gitreview for stable/yoga https://review.opendev.org/c/openstack/os-vif/+/831664 | |
| 10:51:03 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/yoga: Update TOX_CONSTRAINTS_FILE for stable/yoga https://review.opendev.org/c/openstack/os-vif/+/831670 | |
| 10:51:11 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/yoga https://review.opendev.org/c/openstack/os-vif/+/831678 | |
| 10:51:29 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/yoga: Update .gitreview for stable/yoga https://review.opendev.org/c/openstack/osc-placement/+/831695 | |
| 10:51:31 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/yoga: Update TOX_CONSTRAINTS_FILE for stable/yoga https://review.opendev.org/c/openstack/osc-placement/+/831698 | |
| 10:51:35 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: Update master for stable/yoga https://review.opendev.org/c/openstack/osc-placement/+/831701 | |
| 10:51:37 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/yoga: Update .gitreview for stable/yoga https://review.opendev.org/c/openstack/python-novaclient/+/831704 | |
| 10:51:39 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/yoga: Update TOX_CONSTRAINTS_FILE for stable/yoga https://review.opendev.org/c/openstack/python-novaclient/+/831705 | |
| 10:51:41 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/yoga https://review.opendev.org/c/openstack/python-novaclient/+/831706 | |
| 12:55:02 | opendevreview | Merged openstack/os-vif stable/yoga: Update .gitreview for stable/yoga https://review.opendev.org/c/openstack/os-vif/+/831664 | |
| 12:57:52 | opendevreview | Merged openstack/os-vif stable/yoga: Update TOX_CONSTRAINTS_FILE for stable/yoga https://review.opendev.org/c/openstack/os-vif/+/831670 | |
| 13:09:15 | opendevreview | ribaudr proposed openstack/python-novaclient master: Microversion 2.91: Support specifying destination host to unshelve https://review.opendev.org/c/openstack/python-novaclient/+/831651 | |
| 13:22:03 | sean-k-mooney | by the way am i the only one who sees this when they run commands | |
| 13:22:06 | sean-k-mooney | /usr/lib/python3/dist-packages/secretstorage/dhcrypto.py:15: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead | |
| 13:22:08 | sean-k-mooney | from cryptography.utils import int_from_bytes | |
| 13:22:10 | sean-k-mooney | /usr/lib/python3/dist-packages/secretstorage/util.py:19: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead | |
| 13:22:12 | sean-k-mooney | from cryptography.utils import int_from_bytes | |
| 13:22:26 | sean-k-mooney | im seing it for nova manage and also osc | |
| 13:25:59 | sean-k-mooney | i assume secretstorage is managed by uc | |
| 13:26:12 | sean-k-mooney | i wonder if that has beeen adressed there yet | |
| 13:54:05 | gibi | sean-k-mooney: I see that in a fairly recent devstack from master too so I think this is still happening | |
| 14:12:19 | sean-k-mooney | gibi: ack i think this need to be updated in secrtstorage but i dont even know what we use that for | |
| 14:13:08 | sean-k-mooney | like sure it provides a way for securly storing password | |
| 14:13:10 | sean-k-mooney | https://pypi.org/project/SecretStorage/ | |
| 14:13:27 | sean-k-mooney | but why woudl we need dbus integratoin for nova-manage | |
| 14:13:43 | sean-k-mooney | liek we are not going to be pulling things form the gnome keyring | |
| 14:14:17 | sean-k-mooney | im guessing this is really from oslo | |
| 14:15:37 | sean-k-mooney | actully i dont see it as a direct dep in any openstack porject that woudl make sense | |
| 14:15:39 | sean-k-mooney | https://codesearch.opendev.org/?q=secretstorage&i=nope&literal=nope&files=&excludeFiles=&repos= | |
| 14:19:50 | sean-k-mooney | based on strace it looks like its coming form keyring | |
| 14:21:44 | sean-k-mooney | it might be a sideffect fo stevador and the entrypoint scan it does | |
| 14:26:45 | sean-k-mooney | gibi: ok so this is from python-keystoneclient | |
| 14:26:48 | sean-k-mooney | https://opendev.org/openstack/python-keystoneclient/commit/5939541bc771e1205394b05e757d7b23b3aca862 | |
| 14:32:47 | opendevreview | Merged openstack/python-novaclient master: Update master for stable/yoga https://review.opendev.org/c/openstack/python-novaclient/+/831706 | |
| 14:32:48 | tobias-urdin | how does nova track the available of vgpu resources through placement? Or maybe phrased like: how does nova update placement with availability of vgpu resources with multiple "flavors" when using custom traits? | |
| 14:33:17 | tobias-urdin | i've tried to dig through nova scheduler and resource tracker code to understand how it calculates where there is availability | |
| 14:34:02 | sean-k-mooney | tobias-urdin: that has cahnged a littel in the last release or two | |
| 14:34:27 | sean-k-mooney | but basically you list the mdev type and the partent gpu pci adress in the config | |
| 14:35:20 | sean-k-mooney | thne nova will look at the avaiable count and create a Resouce prover per card you listed with an inventory of VGPU for each rp/card | |
| 14:35:47 | sean-k-mooney | we recently added support for generic mdevs so now you can use a differnt resouce class if you prefer | |
| 14:36:10 | sean-k-mooney | so you could have CUSTOM_NVIDIA_LARGE instead of VGPU | |
| 14:36:32 | sean-k-mooney | the generic mdev support is intendd for things that are not GPUs too | |
| 14:37:00 | sean-k-mooney | so in terms of capsity if you are not useing any traits request | |
| 14:38:02 | sean-k-mooney | the compute agent as part of update_aviable_resouces periodic task(and init_host) will read the capasity info form sysfs and translate that into RPs that are child RPs of the comptue node RP with on RP per phsyical gpu card | |
| 14:38:31 | sean-k-mooney | if you just ask for resouces:CGPU=1 in the flavor | |
| 14:39:02 | sean-k-mooney | then we will not filter on any mdev type or trait and will just select host with free VGPU inventory | |
| 14:39:15 | sean-k-mooney | which is fine if all your gpus are the same | |
| 14:39:37 | sean-k-mooney | if you have differnt ones configured you shoudl use traits or the new generic mdev feature instead ot differenciate | |
| 14:40:01 | sean-k-mooney | tobias-urdin: is there anything in particalr that you wanted to know beyond that overview | |
| 14:41:21 | tobias-urdin | CUSTOM_NVIDIA_2 traits, flavors with resources:VGPU=1 and trait:CUSTOM_NVIDIA_1=required etc | |
| 14:41:21 | tobias-urdin | so let's say i have two cards 0000:3b:00.0 and 0000:af:00.0 that is NVIDIA A10 cards, I enable VFs on those and get like 30 each let's say on 0000:3b:x.x 0000:af:x.x and assign enabled_mdev_types=nvidia-1, nvidia-2 and [mdev_nvidia-1]/device_addresses=<all VF for 0000:3b:x.x> (and same for 0000:af card) - assign those CUSTOM_NVIDIA_1 and | |
| 14:42:11 | tobias-urdin | how is placement populated for all those <computenode>_pci_0000_3b_x_x RPs to know how many it is left when it a 1:1 mapping in that RP per PCI dev addr | |
| 14:51:15 | ade_lee_ | sean-k-mooney, hey -- can you take a look at the failing experimental fips job on https://review.opendev.org/c/openstack/tempest/+/831607 | |
| 14:51:35 | ade_lee_ | sean-k-mooney, this time its on centos-9 | |
| 14:52:11 | ade_lee_ | sean-k-mooney, dansmith : https://zuul.opendev.org/t/openstack/build/0a4f8346b89f4bbfa92135dbdbf811f9 | |
| 14:52:45 | sean-k-mooney | so rescue and temp url | |
| 14:54:00 | ade_lee_ | sean-k-mooney, ack - what does that point to? | |
| 14:54:52 | dansmith | check the cinder logs? | |
| 14:55:01 | sean-k-mooney | rescure failde because fo this | |
| 14:55:18 | sean-k-mooney | Waiting for libvirt event about the detach of device vdb with device alias virtio-disk1 from instance 7323f68a-b4dc-4630-b4fd-bd7a7f69d4f4 is timed out. | |
| 14:55:36 | sean-k-mooney | so that looks like the intermiting libvirt volume detach issue | |
| 14:56:07 | sean-k-mooney | ya it is internal error: unable to execute QEMU command 'device_del': Device virtio-disk1 is already in the process of unplug. | |
| 14:56:48 | sean-k-mooney | that will be fixed by a new qemu soon we hope | |
| 14:56:57 | dansmith | seems like a lot of these centos job fails are qemu/libvirt related | |
| 14:57:01 | dansmith | which is pretty disturbing :/ | |
| 14:57:44 | sean-k-mooney | if it makes you feel better those also fail on rhel downstream | |
| 14:57:54 | dansmith | not really :) | |
| 14:58:04 | gibi | the centos jobs are running with newer libvirt and qemu than the ubunut jobs so we see the new failure modes there first | |
| 14:58:29 | sean-k-mooney | currntly yes although it prevoulsy was the other way around | |
| 14:59:18 | sean-k-mooney | gibi: dansmith what is more disturbing to me is this is using the pc machine type | |
| 14:59:22 | sean-k-mooney | not q35 | |