Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-08-21
10:21:10 sean-k-mooney[m] so that all vms had a unique fqdn
10:21:37 sean-k-mooney[m] but with neutron and designate im not sure what the usecase for global or project uniqness is
10:25:58 sean-k-mooney[m] IPO: if other cores think this should be supported and fixed then thats fine we can proceed with the patch its just not something i personally think we should spend time on but if you have a usecase that needs it i dont want to block that
10:26:30 sean-k-mooney[m] i just dont really want to invest much of my time in advocating for it when i dont really belive in it
10:34:23 IPO sean-k-mooney: thank you for extra comments. I have clear view of your point of view about this issue. One of reasons we faced - we have naming convention for VMs. It is maintained by our self-made portal. But there is extra ability to work with cloud - via CLI or API and we can't control names users can choose for VMs
10:42:02 IPO sean-k-mooney: I will try to collect additional reasons with our team, to have more items in list.
11:05:08 IPO sean-k-mooney: Thank you, Sean! I will return to this topic as soon as will have additional info. Have a good day !
11:05:29 sean-k-mooney ok
11:05:58 sean-k-mooney as i said its just not a priority for me but if others are happy to proceed then im ok with that
11:12:21 IPO sean-k-mooney: ok, I see, thank you for your time.
11:55:19 opendevreview Jan Gutter proposed openstack/placement master: DNM -- testing fix in external PR https://review.opendev.org/c/openstack/placement/+/926743
12:02:16 sean-k-mooney gmann: melwitt: https://review.opendev.org/c/openstack/nova/+/925163 is a fairly simple review if ye have time later
12:18:14 opendevreview Jan Gutter proposed openstack/placement master: DNM -- testing fix in external PR https://review.opendev.org/c/openstack/placement/+/926743
13:52:34 opendevreview Jan Gutter proposed openstack/placement master: DNM -- testing fix in external PR https://review.opendev.org/c/openstack/placement/+/926743
15:30:08 stephenfin Just for lolz, I attempted to create a BDM with boot_index=0 and destination_type=local (i.e. the root disk). Nova ignores/overwrites it. Is the fact that it accepts it in the first place a bug in our validation code?
15:30:12 stephenfin e.g. https://paste.openstack.org/show/bFOXilnynfyoGM2CCp7v/
15:30:30 stephenfin (that's the output from my hacked OSC)
15:41:53 opendevreview Merged openstack/nova stable/2023.2: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/911396
15:55:10 melwitt sean-k-mooney: fyi in case you missed it, I updated https://review.opendev.org/q/topic:%22bp/unified-limits-nova-unset-limits%22+is:open+project:openstack/nova after we chatted about [workarounds] and a release note
15:58:19 sean-k-mooney stephenfin: i dont think that is a bug
15:58:28 sean-k-mooney the bdm are not just for cinder
15:59:01 sean-k-mooney you use them ot create multiple ephermaal disk, swap disk and for the root disk
15:59:42 stephenfin Right, I know all that (that's what 'destination_type' is there for, after all). My point is that the nova-api/nova-compute ignores what the user is giving rather than spitting it back at them
16:00:03 sean-k-mooney right so the api is corect to accept it
16:00:09 sean-k-mooney the comptue proably has a bug
16:00:30 sean-k-mooney or there is a bug in how we are merging the bdm and the image
16:00:44 stephenfin Interesting. Are you suggestion I should be able to override $flavor.disk with a BDM?
16:00:50 melwitt yeah, I checked and the api-ref example actually shows boot_index=0 (https://docs.openstack.org/api-ref/compute/#id11) however I think what stephenfin is saying is nova isn't taking the disk size from the BDM and is instead using what's in the flavor in the local case?
16:00:52 stephenfin s/suggestion/suggesting/
16:01:04 stephenfin melwitt: Yes, thanks Mel :)
16:01:30 sean-k-mooney im sayiung that passing image_ref and also providing bdms for the root disk is proably undfiend right now
16:01:51 sean-k-mooney im incined to say that that might be something to reject with a 400
16:02:01 melwitt seems like a nova bug although if flavor and bdm are in conflict then I guess maybe it should reject it saying conflict because we can't assume which one they really wanted
16:02:07 stephenfin Not so. If I pass destination_type=volume instead of destination_type=local, things work just fine (that's a BFV instance)
16:02:24 sean-k-mooney right
16:02:35 sean-k-mooney but im not sure you should be passsing an image uuid
16:02:59 sean-k-mooney and bdms with srouce type image and a uuid
16:04:08 stephenfin Yeah, fair point. I'm thinking about OSC but from a pure API level, you'd set imageRef to nll and set uuid in the relevant BDM instead
16:04:16 sean-k-mooney https://paste.openstack.org/show/bnHpudm9QI1H7gj7aVAm/
16:04:22 sean-k-mooney that a pretty print of the payload
16:04:45 sean-k-mooney stephenfin: so what exactly happens in this case
16:05:04 sean-k-mooney i think the result should be the same since its the same uuid
16:05:30 sean-k-mooney are you expeciting the size to be 6 and your getting the flavor size
16:06:11 sean-k-mooney "destination_type": "local", is really intended only for the addtional ephmeral disks and volume
16:06:18 sean-k-mooney *volume_size
16:06:25 sean-k-mooney in that case is for when you want to have multiple
16:06:42 stephenfin just checking now
16:06:50 sean-k-mooney destination_type=volume volume_size is obvioulsy the cinder volume size
16:07:52 melwitt I guess if we consider how it works for volume (bdm disk size takes precedence) maybe we should do that with local too? rather than it being treated as invalid
16:08:23 sean-k-mooney yep i would expect the bdm to have precidence but it shoudl not be able to exceed flavor.disk_gb
16:08:30 melwitt that would make it consistent. I assume that flavor disk size is ignored for BFV
16:08:31 sean-k-mooney for the non bfv case
16:08:47 sean-k-mooney melwitt: yes and no
16:08:54 sean-k-mooney it mostly is
16:09:02 stephenfin sean-k-mooney: so the answer is it depends :)
16:09:04 sean-k-mooney you shoudl set it to 0 for bfv flavors
16:09:15 stephenfin if I pass an imageRef, then the BFV is totally ignored
16:09:33 sean-k-mooney in older release we used to claim it if not but in newer release if its BFV even if the falvor is not 0 we 0 it in placment ectra
16:09:42 stephenfin if I do not pass an imageRef, then the server goes to error state due an ImageNotFound error
16:09:43 sean-k-mooney so it depend on how old your nova is
16:09:50 melwitt I see
16:09:54 sean-k-mooney but like train did the right thing
16:10:18 sean-k-mooney so its been correctly ignoring it for bfv for a long time
16:10:22 stephenfin this is using a relatively recent deploy of DevStack (commit 8c4a2e1b4759b9932bcad10810143e61ec9b4c36 from Jul 20)
16:11:30 stephenfin sean-k-mooney: I was thinking that I would get a disk size of 6, but idk if that's necessarily something we want to support. Flavors are there for a reason and allowing users to do this provides a way to side-step what the operators want them to use
16:11:57 stephenfin then again, they could just request N ephemeral disks, so it probably doesn't matter: the operator has to reply on quota to save them
16:12:04 sean-k-mooney stephenfin: they kind of alreayd have that however
16:12:16 stephenfin you mean with Cinder?
16:12:21 sean-k-mooney and we do allow you do do it for the addtional ephmeral disk and for bfv
16:12:42 sean-k-mooney no so you can have a flavor with ephmeral_disk=100GB
16:12:51 stephenfin oh, yes
16:12:55 sean-k-mooney and hten you can subdevided that into multiple disks via the bdm
16:13:09 stephenfin me trying to figure out whether I could do that is what led me down this rabbit hole :)
16:13:17 sean-k-mooney https://docs.openstack.org/nova/train/user/launch-instance-from-volume.html#create-volume-from-image-and-boot-instance
16:13:46 stephenfin fwict, it's not really subdividing it so much as completely ignoring what's in the flavor
16:14:12 sean-k-mooney well if its using 6GB i think that is correct
16:14:37 sean-k-mooney provided the flavor is > 6GB
16:14:42 sean-k-mooney well >=
16:15:49 sean-k-mooney https://docs.openstack.org/ocata/user-guide/cli-nova-launch-instance-from-volume.html
16:16:13 sean-k-mooney the note makes it pretty clear for swap and ephermeral
16:16:15 sean-k-mooney "The flavor defines the maximum swap and ephemeral disk size. You cannot exceed these maximum values."
16:16:30 sean-k-mooney so it looks like we wanted the bdms to have precednce over the flavor
16:16:48 stephenfin Yup. That's what I'm seeing. Good point. I'd missed that nuance
16:18:44 sean-k-mooney i assume you followed the BFV example but changed source ot image and dest to local
16:18:48 sean-k-mooney $ openstack server create --flavor FLAVOR --block-device \
16:18:50 sean-k-mooney source=SOURCE,id=ID,dest=DEST,size=SIZE,shutdown=PRESERVE,bootindex=INDEX \
16:18:52 sean-k-mooney NAME
16:19:51 stephenfin sort of - I hacked in a `--root` option to OSC
16:20:05 stephenfin it was easier than figuring out a `--block-device` invocation 0:)
16:20:21 sean-k-mooney ok is there a reason yoru doing this
16:20:40 stephenfin <stephenfin> me trying to figure out whether I could do that is what led me down this rabbit hole :)
16:20:53 sean-k-mooney ok there are some things you can only do via the bdms
16:21:23 sean-k-mooney im confilictedc if i should tell you what those are
16:21:31 sean-k-mooney on one hand you might make it easy to do
16:21:52 sean-k-mooney on the other hand you might make it easy to do and ill have to support people doing it :)
16:22:57 sean-k-mooney the only way to specify a per disk device type is block_device_mapping_v2.device_type i.e. disk, cdrom.
16:22:58 stephenfin that ship has sailed. There are already a load of newish BDM-related options that I added over the past few years (like the `--block-device` option you refer to)
16:23:05 sean-k-mooney you can also set block_device_mapping_v2.disk_bus pre bdm
16:23:20 sean-k-mooney allowign diffent disks to have specific disk bus "fdc, ide, sata, scsi, usb, virtio, xen, lxc and uml."
16:24:08 sean-k-mooney so if you wanted your root disk to use stata and the rest to use virtio-blk or virtio-scsi

Earlier   Later