| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-16 | |||
| 14:33:17 | dansmith | sean-k-mooney: what min_disk are you talking about? | |
| 14:34:02 | sean-k-mooney | on the image | |
| 14:34:20 | sean-k-mooney | you can spcify the min disk for an instance or voluem | |
| 14:34:29 | sean-k-mooney | that is defiend in the api ref as in GB | |
| 14:34:52 | sean-k-mooney | which is why i was confused the quota woudl be in MiB when the api either uese bytes or GB elsehwere | |
| 14:34:56 | sean-k-mooney | anyway not imporant | |
| 14:36:16 | dansmith | isn't that a nova thing? | |
| 14:36:25 | dansmith | or nova/cinder anyway | |
| 14:38:20 | sean-k-mooney | https://docs.openstack.org/api-ref/image/v2/index.html#create-image | |
| 14:38:41 | sean-k-mooney | its a filed in the respocne | |
| 14:39:02 | sean-k-mooney | oh and the request | |
| 14:39:06 | dansmith | yeah those aren't core glance properties, I think those were added for nova/cinder and probably inherited the units | |
| 14:40:16 | sean-k-mooney | they have been there since i worked on openstack and have never been called out as any diffent then name | |
| 14:40:37 | dansmith | yeah I'm just sayin' they're not glance-specific :) | |
| 14:47:28 | zigo | Hi there! One quick question: how can I decrypt the output of "nova get-password <server>" knowing that I don't have access to my private key (it's stored in my yubikey...) ? | |
| 14:48:38 | sean-k-mooney | dansmith: but it considerd a base property by glance "https://github.com/openstack/glance/blob/705b145ab83defb3cb2f8d3243e1ce900fe337b9/glance/api/v2/images.py#L1121" proably becasue of how old and wid spread it is | |
| 14:49:02 | sean-k-mooney | zigo: its encypted with the serverers keypair | |
| 14:49:19 | zigo | sean-k-mooney: Yeah, I know, but with what command do I decrypt it? | |
| 14:49:21 | sean-k-mooney | zigo: so you can use your ssh private key | |
| 14:49:32 | zigo | It's in my yubikey ... | |
| 14:49:38 | zigo | I don't have it as a file. | |
| 14:49:53 | dansmith | sean-k-mooney: in how it's stored, because of age yeah | |
| 14:51:47 | sean-k-mooney | zigo: i guess you cant unless you can use ssh to do the decyption somehow | |
| 14:52:56 | zigo | sean-k-mooney: novaclient uses in novaclient/crypto.py: cmd = ['openssl', 'rsautl', '-decrypt', '-inkey', private_key] | |
| 14:52:56 | zigo | Though rsautl is deprecated ... :/ | |
| 14:53:23 | sean-k-mooney | yep and im not sure we ever supproted it in osc | |
| 14:53:32 | sean-k-mooney | because we dont want to main that | |
| 14:53:48 | bauzas | huzzah it worked | |
| 14:53:59 | bauzas | upping the registered limit, I mean | |
| 14:54:35 | bauzas | size | 25571885056 | |
| 14:54:38 | bauzas | voila the reason | |
| 14:54:54 | bauzas | 25GB | |
| 15:26:32 | clarkb | zigo: https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/hsm2-openssl-libp11.html this is for their hsm product but maybe similar for regular yubikeys | |
| 15:27:22 | clarkb | alternatively ssh using the key then change the password and don't bother involving nova at all? | |
| 15:36:42 | zigo | clarkb: There's no such thing as sshd in our windows instances, just cloud-base-init. I'm trying to figure out what format "nova get-password" is giving out, and if I can unencrypt it with my yubikey... | |
| 15:37:44 | clarkb | zigo: got it (I think you can run an sshd on windows now fwiw, but that makes sense). Maybe those yubikey hsm docs are the clue you need for using the hardware to decrypt | |
| 15:38:05 | zigo | Thanks. I'm reading it. | |
| 15:38:06 | dansmith | yep sshd on windows is trivial now | |
| 15:38:10 | dansmith | built-in almost | |
| 15:42:40 | opendevreview | Merged openstack/nova master: Make python 3.12 unit and functional voting https://review.opendev.org/c/openstack/nova/+/919767 | |
| 16:54:39 | bauzas | melwitt: I want to demonstrate VGPU quota usage on my demo next week | |
| 16:55:02 | bauzas | when setting unifiedlimits driver in nova.conf, which services are using it ? n-sch and n-api right? | |
| 16:55:29 | bauzas | none from the conductor or the compute ? | |
| 16:56:01 | melwitt | bauzas: I think only n-api. I'll double check | |
| 16:56:24 | bauzas | I quickly looked at the code, I only found the scheduler and the api were importing nova.quota | |
| 16:58:44 | melwitt | bauzas: there's a "recheck" in nova-conductor that enforces "strict quota" like races | |
| 16:59:06 | bauzas | then I need to also update nova_cell1.conf | |
| 17:00:41 | bauzas | Unable to initialize OpenStackSDK session: An auth plugin is required to determine endpoint URL: keystoneauth1.exceptions.auth_plugins.MissingAuthPlugin | |
| 17:00:48 | bauzas | humpf, I probably need to set something else | |
| 17:01:29 | bauzas | melwitt: do you know what I missed ? ^ | |
| 17:01:56 | bauzas | (that's the API exception I get when wanting to create a new instance) | |
| 17:02:02 | melwitt | looking.. | |
| 17:02:48 | bauzas | oh, I have nothing | |
| 17:02:55 | bauzas | devstack doesn't automatically set it | |
| 17:04:00 | melwitt | yeah.. maybe something switched to using the sdk since then? I don't remember seeing anything like this | |
| 17:04:18 | melwitt | I need to lookup what's needed for sdk. though it seems surprising it wouldn't be done automatically in devstack like you said | |
| 17:08:46 | melwitt | oh huh that's actually coming from oslo.limit. so likely something needed in an [oslo_limit] conf section. still looking | |
| 17:09:03 | bauzas | yeah, still getting the api exception | |
| 17:09:21 | bauzas | after restarting n-api (and setting [keystone] section)à | |
| 17:10:04 | melwitt | https://docs.openstack.org/oslo.limit/latest/user/usage.html#configuration | |
| 17:10:09 | bauzas | https://docs.openstack.org/oslo.limit/latest/user/usage.html#configuration | |
| 17:10:13 | bauzas | heh | |
| 17:11:14 | melwitt | I'm just confused how/where this got missed. and I'll will add stuff to the quota docs | |
| 17:12:17 | melwitt | ok, here it is in devstack, it should have configured it for you https://github.com/openstack/devstack/blob/85b8d2ccab53bb2b38090c8801404072fae2f7ab/lib/nova#L817 | |
| 17:12:26 | dansmith | do we not have a job with unified limits enabled? | |
| 17:12:32 | melwitt | (I'll still add to docs) | |
| 17:12:39 | melwitt | we do, it's on in nova-next | |
| 17:13:13 | dansmith | ack, so it must be in devstack unless we're hacking it all on in our job config right? | |
| 17:14:02 | melwitt | yeah I just linked the devstack stuff above | |
| 17:14:25 | melwitt | bauzas maybe didn't do the config through devstack or something (?) | |
| 17:14:27 | dansmith | I know, I'm just talking about the assertion of it being missed or not supported | |
| 17:14:28 | dansmith | right | |
| 17:14:33 | melwitt | NOVA_USE_UNIFIED_LIMITS=True should do the stuff | |
| 17:14:52 | melwitt | oh, sure | |
| 17:15:42 | bauzas | no, I just modified nova.conf directly | |
| 17:16:27 | bauzas | I don't want to set quotas for all resources but only VGPU | |
| 17:16:51 | bauzas | I know it will mean that all the quotas limits will be unlimitied :) | |
| 17:17:16 | melwitt | ok cool. I'll propose a patch to add the oslo_limit config info to the docs, that's what I missed | |
| 17:18:02 | melwitt | bauzas: make sure you set a limit for DISK_GB otherwise it will treat it as 0 limit | |
| 17:18:27 | melwitt | that's the only new "core" quota resource | |
| 17:18:59 | bauzas | melwitt: oh ok | |
| 17:19:20 | melwitt | oh wait, actually you have to set all of them bc you didn't do in devstack. but you can just copy what's in devstack | |
| 17:20:01 | melwitt | https://github.com/openstack/devstack/blob/85b8d2ccab53bb2b38090c8801404072fae2f7ab/lib/nova#L789-L812 | |
| 17:20:20 | melwitt | and then this to make the nova service user able to read the quotas https://github.com/openstack/devstack/blob/85b8d2ccab53bb2b38090c8801404072fae2f7ab/lib/nova#L827-L829 | |
| 17:24:21 | bauzas | yup, I'm done now, I just need to tweak the registered limits | |
| 17:24:24 | bauzas | Project 1471d08833d141c583b5f04344476ebd is over a limit for [Resource class:DISK_GB is over limit of 0 due to current usage 80 and delta 40, Resource class:MEMORY_MB is over limit of 0 due to current usage 16384 and delta 8192, Resource class:VCPU is over limit of 0 due to current usage 2 and delta 1, Resource class:VGPU is over limit of 0 due to current usage 2 and delta 1, Resource servers is over limit of 0 due to current usa | |
| 17:24:26 | bauzas | ge 2 and delta 1] (HTTP 403) (Request-ID: req-980c41e8-6f18-4e12-984b-7eb5daa7d9e8) | |
| 17:24:53 | bauzas | so, I not only need to add a limit for DISK_GB but also the other classes | |
| 17:29:09 | melwitt | yes. any class that's going to be requested has to have a registered limit else oslo.limit treats it as zero | |
| 17:30:02 | bauzas | yup I know it :) | |
| 17:30:04 | melwitt | (which is why we were discussing at the PTG about how to make an unlimited option in nova) | |
| 17:30:27 | bauzas | yeah my brain fried | |
| 17:31:13 | bauzas | sometimes my brain can't reconcile two things :) | |
| 17:31:13 | melwitt | :) | |
| 17:35:08 | bauzas | yay that works | |
| 17:35:31 | bauzas | I have everything now for my demo, I just need to record it :) | |
| 17:35:51 | bauzas | my next nights => bye bye | |
| 17:36:01 | melwitt | \o/ | |
| 17:36:05 | bauzas | thanks melwitt for the quick resolution and the help | |
| 17:36:38 | bauzas | CERN will be more happy to test unified limits for VGPU if they haven't done it yet :) | |