Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-05-07
17:02:06 sean-k-mooney then that answer my quetion regrading data voluem with a data volume we take the info form the root disk
17:03:01 sean-k-mooney basically i was wondering if in teh tempest test we coudl create a volmue form the glance image
17:03:07 gmann gibi: sean-k-mooney: RE on SG BP. I cannot join the Nova meeting as it conflicts with the time I drop my son to school. I checked the BP/code change https://blueprints.launchpad.net/nova/+spec/shared-security-groups
17:03:09 sean-k-mooney then update the image properites on teh volume to add it
17:03:20 sean-k-mooney and then boot form the volume
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 sean-k-mooney gmann: so its always possibel that this would fail the way it is now
17:05:27 gmann sean-k-mooney: yeah
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: Enable virtio-scsi in nova-next https://review.opendev.org/c/openstack/nova/+/918458
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: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

Earlier   Later