| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-21 | |||
| 10:01:29 | sean-k-mooney[m] | because it allow you to probe for information you otherwise should not have. i.e. the hostname of other tenants vms | |
| 10:03:44 | sean-k-mooney[m] | the way the fix is proposed its also pretty expensive | |
| 10:04:48 | sean-k-mooney[m] | every instqance create would result in a db query to alll cells. | |
| 10:07:11 | IPO | sean-k-mooney: Thank you for comment. Interesting point. But in this case maybe the some way of variant, which was proposed earlier, should been implemented. But this will allow to check VMs name in one cell, but for all projects, which is not allowed either | |
| 10:09:32 | IPO | sean-k-mooney: And finally it looks like this feature maybe be cancelled at all as a potential security risk ? | |
| 10:11:19 | sean-k-mooney[m] | what use case made you interested in supporting this across cells? | |
| 10:17:27 | IPO | sean-k-mooney: Good question ! Basically we don't use cells in prods and some case of fix, implemented before (https://review.opendev.org/c/openstack/nova/+/860938) suits our needs. But there was the comment that we need fix to check it for all cells. Thant is why we start to impliment new fix | |
| 10:19:30 | sean-k-mooney[m] | thats not quite what i was asking. why to you enable project or global uniquness? | |
| 10:19:53 | sean-k-mooney[m] | the security issue is minor and its something that deployers opt into for there cloud | |
| 10:20:36 | sean-k-mooney[m] | thats why im not -1, the operator made a delibverate choice to opt in | |
| 10:20:57 | sean-k-mooney[m] | i could understand why this was useful for nova networks | |
| 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:) | |