| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-04-25 | |||
| 10:52:55 | auniyal | sean-k-mooney, how can I fix skipping test then | |
| 10:52:58 | sean-k-mooney | but my guess is that is nto the actul issue | |
| 10:53:01 | sean-k-mooney | can you should be the test | |
| 10:53:25 | auniyal | https://paste.opendev.org/show/bZgalcGsTREjXm08RT34/ | |
| 10:54:19 | sean-k-mooney | https://github.com/openstack/tempest/blob/1c3fc43c9dae274a19683b003f78b5f50edbc062/doc/source/microversion_testing.rst that is the docs on adding microversion test by the way | |
| 10:55:21 | sean-k-mooney | it looks like you might be missing the resocue_setup funciton un less you are gettign that form the ineritied test | |
| 10:56:46 | sean-k-mooney | its not provided directly by the parent class https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/whitebox_tempest_plugin/api/compute/base.py#L38 | |
| 10:56:55 | sean-k-mooney | so we need to check BaseV2ComputeAdminTest | |
| 10:57:41 | sean-k-mooney | ok it should get it form here https://github.com/openstack/tempest/blob/1c3fc43c9dae274a19683b003f78b5f50edbc062/tempest/api/compute/base.py#L123 | |
| 10:58:28 | auniyal | CONF.compute.min_microversion - so None | |
| 10:58:29 | sean-k-mooney | from what i can see you have done it correctly | |
| 10:59:03 | sean-k-mooney | auniyal: its proably best to ask about this isn the QA channel by the way | |
| 10:59:15 | auniyal | sean-k-mooney, ack | |
| 10:59:21 | sean-k-mooney | that is where we gernerally discuss tempest/whitebox thigns | |
| 10:59:23 | auniyal | thanks for looking | |
| 10:59:30 | sean-k-mooney | there are more people that understand it better there | |
| 11:22:58 | songwenping_ | sean-k-mooney: use mutli threads to process the same resource. e.g. create a flavor use the same name with two thread, one thread should raise FlavorExists exception. | |
| 11:35:52 | sean-k-mooney | songwenping_: we generally dont do that in tempest, if we need to create a flavor we either generat a randome name or a uique oen for a given test | |
| 11:36:18 | sean-k-mooney | so that shoudl either never happen or test that share names need to have the @serial decorator applied | |
| 11:37:37 | songwenping_ | thanks, got it. | |
| 12:11:04 | sean-k-mooney | songwenping_: we do not split singlel testcase between workers by the way so each test runs in a singel threadn adn we distribute tests between threads | |
| 12:39:03 | opendevreview | Fabian Wiesel proposed openstack/nova master: Do not close returned image-chunk iterator & get_verifier early https://review.opendev.org/c/openstack/nova/+/909474 | |
| 22:14:02 | simondodsley | sean-k-mooney: the `CONF.host` doesn't gaurantee a unique name when taken in the context of a storage platform that can be used by systems other than OpenStack. It is possible that hosts in an organization coul dhave the same name, but with different storage prototocls, different IQNs, etc. This is why the compute node UUID would be ideal to use as this should be unique. Is there any chance this could be added to `CONF`? | |
| #openstack-nova - 2024-04-26 | |||
| 03:12:14 | opendevreview | Ilia Baikov proposed openstack/nova-specs master: Initial commit on blueprint https://review.opendev.org/c/openstack/nova-specs/+/917108 | |
| 03:19:18 | opendevreview | Ilia Baikov proposed openstack/nova-specs master: Initial spec on cloud-init for dynamic vendordata https://review.opendev.org/c/openstack/nova-specs/+/917109 | |
| 03:38:34 | opendevreview | Ilia Baikov proposed openstack/nova-specs master: Initial spec on cloud-init for dynamic vendordata https://review.opendev.org/c/openstack/nova-specs/+/917109 | |
| 03:46:13 | opendevreview | Ilia Baikov proposed openstack/nova-specs master: Initial spec on cloud-init for dynamic vendordata https://review.opendev.org/c/openstack/nova-specs/+/917109 | |
| 03:59:03 | opendevreview | Ilia Baikov proposed openstack/nova-specs master: Initial spec on cloud-init for dynamic vendordata https://review.opendev.org/c/openstack/nova-specs/+/917109 | |
| 04:07:50 | opendevreview | Ilia Baikov proposed openstack/nova-specs master: Initial spec on cloud-init for dynamic vendordata https://review.opendev.org/c/openstack/nova-specs/+/917109 | |
| 04:55:22 | opendevreview | Ilia Baikov proposed openstack/nova-specs master: Initial spec on cloud-init for dynamic vendordata https://review.opendev.org/c/openstack/nova-specs/+/917109 | |
| 07:07:15 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: scheduler: AggregateMultitenancyIsolation to support unlimited tenant https://review.opendev.org/c/openstack/nova/+/896512 | |
| 07:28:25 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix concurrent migration of vms with multiattach volume failure https://review.opendev.org/c/openstack/nova/+/872278 | |
| 07:58:58 | sahid | o/ bauzas sean-k-mooney dansmith, any chance to make progress on that one? https://review.opendev.org/c/openstack/nova/+/896512 | |
| 08:04:20 | bauzas | \o | |
| 08:04:56 | bauzas | sahid: I need to do a couple of reviews next week, tbh those two last weeks, I was off Gerrit :) | |
| 08:05:48 | bauzas | it's tracked in https://etherpad.opendev.org/p/nova-dalmatian-status, so don't worry, we'll look at it :) | |
| 08:07:45 | sahid | ah cool thanks | |
| 10:25:06 | elodilles | bauzas and release liaisons: when you have time please review these open release patches: https://review.opendev.org/q/project:openstack/releases+file:%5Edeliverables/.*/nova.yaml+is:open | |
| 10:25:16 | bauzas | I'll try | |
| 10:27:02 | elodilles | thanks in advance o/ | |
| 10:27:09 | elodilles | i know you are busy :S | |
| 11:48:37 | sean-k-mooney | simondodsley: no, and CONF.host is requried to be unique in the cloud or at least within a cell. if the there are other things usign the stroage backend that could have the same hostnames but different FQDNs then CONF.Host shoudl be an FQDN | |
| 11:49:13 | sean-k-mooney | simondodsley: today there is not api conrtract between nova and cinder that allows cidner to depend on the compute node uuid | |
| 11:49:25 | sean-k-mooney | at least not that im aware of | |
| 11:50:34 | sean-k-mooney | the attachment api is specified in teerms of the host field https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=detach-volume-from-server-detail#create-attachment | |
| 11:51:05 | opendevreview | Konrad Gube proposed openstack/nova-specs master: Re-propose using extend volume completion action for 2024.2 https://review.opendev.org/c/openstack/nova-specs/+/917133 | |
| 11:51:32 | sean-k-mooney | we also pass the iqn in the connector | |
| 11:52:22 | sean-k-mooney | simondodsley: is there a particalr feature or bug you are tring to work on? | |
| 11:54:13 | sean-k-mooney | simondodsley: we recentlly added a stable compute uuid feature. the closet thing i think we might consider would be a config flag to use the compute uuid as the value fo host | |
| 13:18:21 | simondodsley | sean-k-mooney: it's actually a bug i'm trying to fix related to synchronously replicated cinder volumes. When configured so the volume can attach to the hypervisor from both backends at the same time (for redundancy) the host object on the array is allocated different names, so it can cause issues during cinder failover events. To get the UUID of the hypervisor will allow us to have consistent host object names across the | |
| 13:18:21 | simondodsley | backends | |
| 13:19:41 | sean-k-mooney | ok but that is not something cinder should be lookign up | |
| 13:20:17 | simondodsley | i can see that, but i'm trying to find a way to get to this value - it would be incredibly helpful | |
| 13:20:18 | sean-k-mooney | its an admin only api and cidner should not really be calling out to that | |
| 13:20:29 | sean-k-mooney | we would need an api change in cinder | |
| 13:20:49 | sean-k-mooney | and nova or os-brick coudl pass it in the attachment as part of the connector | |
| 13:22:23 | simondodsley | ok - let me look into that and have a chat with the cinder cores | |
| 13:22:27 | simondodsley | thanks | |
| 17:34:30 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Migrate to JSON Schema Draft 2020-12 https://review.opendev.org/c/openstack/nova/+/915845 | |
| 17:34:31 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add 'removed' decorator https://review.opendev.org/c/openstack/nova/+/915736 | |
| 17:34:31 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Don't do version check if nothing required https://review.opendev.org/c/openstack/nova/+/915737 | |
| 17:34:32 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add remaining missing query parameter schema https://review.opendev.org/c/openstack/nova/+/915738 | |
| 17:34:32 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Ensure all APIs have a request query schema https://review.opendev.org/c/openstack/nova/+/915739 | |
| 17:34:33 | opendevreview | Stephen Finucane proposed openstack/nova master: conf: Add '[api] response_validation' option https://review.opendev.org/c/openstack/nova/+/915740 | |
| 17:34:33 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body validation helper https://review.opendev.org/c/openstack/nova/+/915741 | |
| 17:34:34 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for server action APIs https://review.opendev.org/c/openstack/nova/+/915742 | |
| 17:34:35 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add response body schemas for remaining server action APIs https://review.opendev.org/c/openstack/nova/+/915743 | |
| #openstack-nova - 2024-04-28 | |||
| 15:13:25 | opendevreview | Ilia Baikov proposed openstack/nova master: api: Add cloud-init as whitelisted property in DynamicJSON vendor data to not be JSON-encoded https://review.opendev.org/c/openstack/nova/+/917276 | |
| #openstack-nova - 2024-04-29 | |||
| 00:42:04 | opendevreview | Ilia Baikov proposed openstack/nova master: api: Add cloud-init as whitelisted property in DynamicJSON vendor data to not be JSON-encoded https://review.opendev.org/c/openstack/nova/+/917276 | |
| 01:46:02 | songwenping__ | sean-k-mooney: how can i get the access to the bugzilla? https://bugzilla.redhat.com/show_bug.cgi?id=953339 | |
| 10:50:48 | sean-k-mooney | songwenping_: its restircted to redhat employee's its also for rhel 6.4 which has been out of supprot for seveeral years so im not sure its going to be relvent ot you? | |
| 10:51:23 | sean-k-mooney | it was fixed in 2014 | |
| 10:57:48 | songwenping_ | sean-k-mooney: we meet the same problem with the libvirt 6.2.0, is the libvirt is too old and which version i will upgrade? | |
| 10:58:38 | sean-k-mooney | not being able to attach >50 VF to a single vm? | |
| 10:59:49 | sean-k-mooney | the bug you linked was in libnl which is the netlink libary but hte libvirt fix that used it was in 0.10.2 | |
| 11:00:06 | sean-k-mooney | so this is not because your libvirt is two old | |
| 11:01:59 | sean-k-mooney | actully it might not require 50 VF with one vm just vfs 50 and above? | |
| 11:02:02 | sean-k-mooney | its really not clear form the bug | |
| 11:02:04 | songwenping_ | only bind one VF to vm | |
| 11:02:21 | songwenping_ | the full error message from nova-compute is : Instance failed to spawn: libvirt.libvirtError: internal error: missing IFLA_VF_INFO in netlink response | |
| 11:03:36 | sean-k-mooney | songwenping_: ok my guess is there my be a similar bug but you are not hitting that one | |
| 11:05:20 | songwenping_ | so which version of netlink libary is support? | |
| 11:05:37 | sean-k-mooney | that has noting to do with nova | |
| 11:05:44 | sean-k-mooney | that is determined by your distro | |
| 11:05:58 | sean-k-mooney | what card are you tring to use | |
| 11:06:16 | sean-k-mooney | i found this googleing https://forums.developer.nvidia.com/t/connectx-6-dx-sr-iov-libvirt-error/249762 | |
| 11:08:34 | songwenping_ | we are using Mellanox cx5 nic | |
| 11:09:17 | sean-k-mooney | it shared the same kernel driver so it may be the same or a simialr bug | |
| 11:10:56 | songwenping_ | yeah, i alse found the site, so i wonder if we should upgrade the libvirt | |
| 12:04:32 | elodilles | bauzas: if you are around, a gentle reminder for the nova release patches o:) https://review.opendev.org/q/project:openstack/releases+file:%5Edeliverables/.*/nova.yaml+is:open | |
| 12:05:10 | elodilles | Uggla_ auniyal : fyi ^^^ | |
| 12:09:11 | frickler | oh, that's a nice search filter, /me takes notes ;) | |
| 12:11:07 | bauzas | frickler: yeah I used the filter something like 9yo when I was only a nova-scheduler expert :) | |
| 15:13:25 | samcat116 | Hi all, I submitted this bug about Placement and aarch64 nodes receiving x86 traits about a week ago. Any ideas on a next step I could take? https://bugs.launchpad.net/nova/+bug/2062425 Thanks! | |
| 15:39:13 | tkajinam | samcat116, If I read the current code correctly you still have to add HW_ARCH_* traits manually to resource providers. I don't see any logic in libvirt driver to report these traits. | |
| 15:39:33 | tkajinam | (I've left a comment in a bug too | |
| 15:40:16 | samcat116 | I see all of the relevant x86 traits created on the other x86 nodes, and I did nothing to create those | |
| 15:40:20 | tkajinam | I was not involved in the discussion of that cpu arch support. probably someone from the core can double-check my observation and probably give context of the current implementation | |
| 15:40:44 | tkajinam | that's a trait for CPU feature, not one for arch | |
| 15:41:10 | tkajinam | no cpu archutecture trait is currently reported automatically. | |