| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-07 | |||
| 17:03:38 | sean-k-mooney | to avoid needing to configure this in the job | |
| 17:03:51 | sean-k-mooney | gmann: no worries | |
| 17:04:06 | gmann | gibi: sean-k-mooney: it seems ok to approve specless, there is no interface or API change here, SecurityGroupNotFound error can occur in any case even no SG in tenant or so and adding to get shared SG does not change it even improve to avoid notFound cases | |
| 17:04:44 | opendevreview | Vasyl Saienko proposed openstack/nova master: [ironic] Fix rebooting instance https://review.opendev.org/c/openstack/nova/+/918195 | |
| 17:05:15 | sean-k-mooney | gmann: ya i had a simialr feeling. the secuirty gorup could also have been delete between the vm create request being accpeted by the api and the swapn on the compute | |
| 17:05:18 | gmann | and as it check the neutron extension enable or not, we have the discovery path also for inteop point of view | |
| 17:05:27 | gmann | sean-k-mooney: yeah | |
| 17:05:27 | sean-k-mooney | gmann: so its always possibel that this would fail the way it is now | |
| 17:09:31 | sean-k-mooney | dansmith: so i think there is some funky interaction between specifying block_device_mapping_v2.disk_bus vs haveign hw_disk_bus=scsi on the image | |
| 17:10:22 | sean-k-mooney | as far as im waware we dont offically supprot having multiple diffent disk buses in a nova inastance at once | |
| 17:10:32 | sean-k-mooney | however using bdms you could achive that | |
| 17:12:18 | sean-k-mooney | i tought on of the geneal probelms with that was that we did nto have the correct code to create teh requried contolers | |
| 17:12:43 | sean-k-mooney | i.e. scsi contoler in this case but i think your hiiting that other code path | |
| 17:13:52 | dansmith | sean-k-mooney: I don't know that's true.. without the hw_scsi_model I can still request the disk_bus=scsi, and I get a lsilogic controller, I just don't have the drivers | |
| 17:14:08 | sean-k-mooney | dansmith: so i think that a bug | |
| 17:14:18 | sean-k-mooney | or libvirt defaulting is happeing | |
| 17:14:24 | sean-k-mooney | if you try doing that for stata | |
| 17:14:29 | sean-k-mooney | i dont think it will work | |
| 17:14:54 | dansmith | the docs for hw_scsi_model also don't say that you can request lsi, it only says that if it's set, you can set it to virtio, which kinda implies it's not virtio by default | |
| 17:15:55 | sean-k-mooney | my understanding was hw_scsi_model was only ment to be coniderd if hw_disk_bu, hw_cdrom_bus or hw_rescuse bus was set to scsi | |
| 17:16:33 | sean-k-mooney | i.e. i did not exepct it to be used just bey settign disk_bus=scsi in the bdms | |
| 17:16:38 | sean-k-mooney | evedently it can be | |
| 17:16:44 | dansmith | I guess it doesn't seem reasonable to force all block devices to scsi in order to be able to have one as scsi | |
| 17:16:57 | dansmith | meaning, sata for everything and scsi for this special direct lun volume makes sense, no/ | |
| 17:17:09 | sean-k-mooney | well we dont support having diffent disk on diffent busses in general | |
| 17:17:35 | sean-k-mooney | i.e. if you have root swap and multiple ephmeral volumes | |
| 17:17:51 | sean-k-mooney | then by default they are all specified vai hw_disk_bus | |
| 17:18:12 | sean-k-mooney | you could use the bdm api with destion_type=local | |
| 17:18:20 | sean-k-mooney | at leat for epmeral disk i think | |
| 17:18:30 | sean-k-mooney | but i have never seen that documented or recommended before | |
| 17:19:29 | dansmith | well, we do for ide cd and sata/scsi root disk right? | |
| 17:19:33 | sean-k-mooney | i always found block_device_mapping_v2.disk_bus (Optional) odd because i didnt knwo fo a supproted usecase wehre it could ever be diffent then the root disk | |
| 17:19:47 | dansmith | given the BDM takes a disk_bus, I think it's sort of implied that you should be able to ... you know, select it | |
| 17:19:48 | sean-k-mooney | for q35 ya | |
| 17:20:04 | sean-k-mooney | its implied but i dotn think we docuement or test it | |
| 17:20:31 | sean-k-mooney | like this has been somethign that has bugged me for years because i tied to do that in the past and it didnt appear to work | |
| 17:20:50 | sean-k-mooney | so i have alwasy wondered why its there if it does nto work | |
| 17:21:17 | sean-k-mooney | anyway you made it work but to me this still feels like a grey area | |
| 17:23:43 | sean-k-mooney | our docs https://docs.openstack.org/nova/latest/user/block-device-mapping.html#block-device-mapping-v2 still say "Leaving these empty is the most common thing to do" with regards to disk_bus and device_type | |
| 17:25:19 | sean-k-mooney | so i alwasy tough these we hold overs form bdm v1 with no reall usecase now outside fo device_type=cdrom for cinder vomues created form install isos | |
| 17:25:29 | dansmith | IMHO it shouldn't be grey.. it might be because of other problems we have, but I see no reason not to allow picking the bus per device | |
| 17:25:47 | sean-k-mooney | we can my issue is not with the feature | |
| 17:25:51 | sean-k-mooney | its with the testing fo that | |
| 17:26:11 | sean-k-mooney | i.e. i dont think we have tempest coverage of this in general | |
| 17:28:26 | sean-k-mooney | as far as im aware the only tempest test we hav efor attaching a device to a speicic disk bus is https://github.com/openstack/tempest/blob/ccd034eb3a916ce4d3955fa11fe905aa50cbc15d/tempest/api/compute/admin/test_volume.py#L93 | |
| 17:28:37 | sean-k-mooney | and that does it via the image properties | |
| 17:29:31 | sean-k-mooney | dansmith: with that said your partly adressing that now | |
| 17:32:21 | opendevreview | Dan Smith proposed openstack/nova master: Fix device_type=lun with boot_index https://review.opendev.org/c/openstack/nova/+/918470 | |
| 17:32:28 | dansmith | sean-k-mooney: this fixes the other problem ^ with BFV | |
| 17:32:44 | dansmith | I have a tempest change to test BFV with multi-attach type=lun, which seems to work fine | |
| 17:32:52 | dansmith | I'll get them all re-swizzled after this run finishes | |
| 17:33:30 | sean-k-mooney | sure no rush ah you had to add lun as a possible boot dev | |
| 17:33:43 | sean-k-mooney | i wonder if this was previously only "supported" for data voluems | |
| 17:33:48 | sean-k-mooney | based on that list | |
| 17:33:58 | dansmith | just never tried, I imagine | |
| 17:34:26 | dansmith | it would be easy to say "don't do that for root" but I'm sure someone will want it and the kinds of pets that want this sort of thing are likely to be in that boat | |
| 17:34:54 | sean-k-mooney | im not sure if there is any disadvantage ot having root on a lun | |
| 17:34:56 | dansmith | I think there are some potential performance improvements with this for root if you have a very static pet.. I was reading that it's common to do this on vmware | |
| 17:35:04 | dansmith | maybe something related to the OS knowing its root is basically an iscsi device | |
| 17:35:08 | sean-k-mooney | i mean you proably dont need the extra locking apis | |
| 17:35:18 | dansmith | right, not for locking, but for perf | |
| 17:35:24 | sean-k-mooney | and we dont supprot multiatcch BFV right | |
| 17:35:35 | dansmith | we do actually. it's already tested even | |
| 17:35:37 | dansmith | in tempest | |
| 17:35:48 | dansmith | so I'm doing this as multi-attach BFV just to make sure it's covered that way | |
| 17:35:49 | sean-k-mooney | oh well in that case you may want the locking apis | |
| 17:36:11 | dansmith | presumably for hot spare type things I guess | |
| 17:36:34 | sean-k-mooney | ya so we cant do the vmware "keep the memroy in sync" type of failover | |
| 17:36:48 | sean-k-mooney | but if your application can do that or the bits it needs | |
| 17:37:00 | sean-k-mooney | then i can see that use case kind of | |
| 17:37:26 | dansmith | or you just want another instance already configured potentially hanging at the bootloader screen ready to boot, recover journal and be the master | |
| 17:37:31 | sean-k-mooney | it would be interesting to here form anyone who has used BFV multi attach | |
| 17:38:30 | sean-k-mooney | ... using grub as a active/passive lock sound like a nightmare to debug | |
| 17:38:57 | sean-k-mooney | but i could see that | |
| 17:39:40 | opendevreview | Vasyl Saienko proposed openstack/nova master: [ironic] Fix rebooting instance https://review.opendev.org/c/openstack/nova/+/918195 | |
| 17:39:43 | sean-k-mooney | that feels like "hay this is how we did it in my enteriprise virt solution, make it work the same in cloud" | |
| 17:41:49 | dansmith | yep, that's what I mean by "these sorts of pets" :) | |
| 17:43:10 | dansmith | Because of the boot order thing, I opened https://bugs.launchpad.net/nova/+bug/2065084 for the combined "device_type=lun is broken" issue and will tag both fixes to it | |
| 18:19:11 | opendevreview | Dan Smith proposed openstack/nova master: Avoid setting serial on raw LUN devices https://review.opendev.org/c/openstack/nova/+/918089 | |
| 18:19:12 | opendevreview | Dan Smith proposed openstack/nova master: Fix device_type=lun with boot_index https://review.opendev.org/c/openstack/nova/+/918470 | |
| 18:19:12 | opendevreview | Dan Smith proposed openstack/nova master: Enable virtio-scsi in nova-next https://review.opendev.org/c/openstack/nova/+/918458 | |
| 18:49:29 | opendevreview | Dan Smith proposed openstack/nova master: Enable virtio-scsi in nova-next https://review.opendev.org/c/openstack/nova/+/918458 | |
| #openstack-nova - 2024-05-08 | |||
| 01:10:35 | opendevreview | Merged openstack/nova master: [ironic] Fix rebooting instance https://review.opendev.org/c/openstack/nova/+/918195 | |
| 05:14:25 | opendevreview | Vasyl Saienko proposed openstack/nova stable/2024.1: [ironic] Fix rebooting instance https://review.opendev.org/c/openstack/nova/+/918180 | |
| 09:33:22 | stephenfin | gibi: don't know if you've time but if you were able to get back to https://review.opendev.org/c/openstack/nova/+/821423 before this week is out I'd love to close it out | |
| 12:57:37 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reject AZ changes during aggregate add / remove host https://review.opendev.org/c/openstack/nova/+/821423 | |
| 12:58:05 | gibi | stephenfin: replied and fixed ^^ | |
| 13:55:27 | opendevreview | Merged openstack/nova master: Make overcommit check for pinned instance pagesize aware https://review.opendev.org/c/openstack/nova/+/631053 | |
| 15:04:06 | dansmith | gibi: could you look at this mostly trivial series to fix the direct lun attach? https://review.opendev.org/c/openstack/nova/+/918089 | |
| 15:04:36 | dansmith | turns out we can actually test this with LVM backend, which is cool, because that means we can also do this in upstream tempest | |
| 15:04:38 | gibi | lookoing... | |
| 15:05:18 | dansmith | sean-k-mooney: and I replied to your comment on the middle patch about the boot index | |
| 15:14:24 | opendevreview | Biser Milanov proposed openstack/nova master: Hardcode the use of iothreads for KVM. https://review.opendev.org/c/openstack/nova/+/918669 | |
| 16:29:02 | dansmith | gibi: thanks | |
| 16:32:34 | gibi | dansmith: it was simple indeed | |
| 17:57:50 | opendevreview | Dan Smith proposed openstack/nova master: Upload glance image with --file in ceph job https://review.opendev.org/c/openstack/nova/+/918689 | |
| 18:36:12 | opendevreview | Merged openstack/nova master: Avoid setting serial on raw LUN devices https://review.opendev.org/c/openstack/nova/+/918089 | |
| #openstack-nova - 2024-05-09 | |||
| 14:01:24 | WJeffs7508790194 | Hey, Random question for PCI passhthrough I have 2 models of the same GPUs with different product IDs, can I repeat the same alias again so they will both have the same name? or do they have to unique? thanks | |
| 14:51:37 | sean-k-mooney | WJeffs7508790194: you cant have a single alais refer to two diffent product ids | |
| 14:52:14 | WJeffs7508790194 | sean-k-mooney: Thanks for the clarification, I thought that might have been the case. | |