Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-12
15:40:46 dansmith the admin password is always generated in the API and passed to driver.spawn().. if libvirt is creating a config_drive, it will put it in there.. no injection enabling required
15:40:56 sean-k-mooney oh ok was not aware of that. i assuem we only do that on windows images base on the os_type value in glance
15:41:00 dansmith if cloudbase-init was running, sees it and honors it then...
15:41:16 dansmith no, I'm testing this with a linux guest
15:41:36 sean-k-mooney oh ok. perhasp we shoudl add a flag for that somewher then
15:43:09 dansmith admin_pass": "CExk4PUfQLgA",
15:43:09 dansmith $ grep -Po admin_pass.*?, /mnt/openstack/latest/meta_data.json
15:43:34 dansmith well, it doesn't matter for linux guests regardless because cloud-init won't use it
15:43:49 dansmith and for windows guests, if they rely on that, it has to work
15:43:58 sean-k-mooney dansmith: do you know what other palthforms do. i asume aws and kubvirt have a similar issue
15:44:21 dansmith it's not really related to what I'm doing so it doesn't matter, I just thought I'd point it out based on the conversation above
15:44:35 sean-k-mooney ack
15:46:04 dansmith FWIW, I don't see anywhere that we allow a POST/PUT from cloudbase-init via metadata to locally generate and set it
15:46:12 dansmith do you know that's a thing for sure?
15:53:41 sean-k-mooney it is but its hard to find ill grab a link
15:54:12 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/api/metadata/password.py#L58
15:54:51 sean-k-mooney dansmith: it can only be set once via that flow
15:55:22 sean-k-mooney https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89
15:55:39 dansmith oh thanks.. how does that get linked from the actual handler that services the GET? I didn't see it ... (don't answer, I can dig)
15:56:24 dansmith so it already has to be encrypted in the way we're expecting in that case I guess.. all we do is split it into pieces
15:56:27 sean-k-mooney my guess is that handeler is jsut alwasy used for both but not sure
15:57:09 dansmith this stuff is so gross
15:58:00 sean-k-mooney that was my reaction when i rediscoved it exested a few years ago i dont know if i have the linke to the cloudbase init code but i thikn its useing the keypair to encyrpt it
15:58:33 dansmith it has to if it wants horizon to be able to use it I think
15:58:47 dansmith well, horizon lets the user choose a private key to decrypt with so.. I guess that could be something else, IDK
15:59:02 dansmith the cloudbase-init code is available, I haven't gone looking through it yet but I will
16:01:40 sean-k-mooney it has to be the private key that releated to the publick key for the server
16:02:52 sean-k-mooney https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/metadata/services/httpservice.py#L71-L81
16:03:30 sean-k-mooney https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/plugins/common/setuserpassword.py#L50
16:03:55 sean-k-mooney https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/metadata/services/base.py#L115-L126
16:04:32 dansmith yep, so same as nova basically
16:04:35 sean-k-mooney so it alwasy the first public key in the list which for opentack is where we put the ssh/x509 pub key form the servers keypair
16:05:09 sean-k-mooney yep so it shoudl be end to end encypted
16:05:57 sean-k-mooney althogh i hate the idea that horizon has a view where you can send it your private key ever
16:06:18 sean-k-mooney hopefully they do that clint side with javascript of somehtign liek that
16:07:04 dansmith yep they do
16:07:18 dansmith and yep, showing the password in cleartext ever seems like an anti-pattern anyway
16:07:35 dansmith I assume there has to be some windows-specific workflow that requires it be generated on the instance at first boot or something
16:07:44 dansmith like maybe post-sysprep or some such
16:07:49 dansmith post-un-sysprep I mean
16:09:51 opendevreview Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584
16:24:32 opendevreview Merged openstack/nova master: Update compute rpc alias for Gazpacho https://review.opendev.org/c/openstack/nova/+/979008
16:24:54 opendevreview Merged openstack/nova master: Add Gazpacho prelude section https://review.opendev.org/c/openstack/nova/+/979023
17:59:34 opendevreview Merged openstack/nova-specs master: Amend vTPM live migration spec https://review.opendev.org/c/openstack/nova-specs/+/980165
21:25:28 Matko[m] Would anybody know if the ironic driver can or ever consumed in any shape or form the memcache_servers and memcache_secret_key configs from the ironic section in nova.conf?
21:25:31 Matko[m] I'm doing some cleanup in openstack-helm and found those configs are configured in the ironic section: https://opendev.org/openstack/openstack-helm/src/branch/master/nova/templates/configmap-etc.yaml#L166-L172
21:25:39 Matko[m] I want to remove them as I couldn't find anything consumed them, even through libraries. I want to cover all bases and confirm with the Nova team this is actually not used.
21:26:25 sean-k-mooney Matko[m]: the ironic driver used to use tooz to provide a distibute hash ring
21:26:35 sean-k-mooney i think tha tmight have eben able to use memcache to store it
21:27:07 sean-k-mooney https://opendev.org/openstack/tooz/src/branch/master/tooz/drivers/memcached.py
21:27:17 sean-k-mooney so maybe if it was integrated via that
21:27:45 sean-k-mooney Matko[m]: it woudl proably be better to also check with the ironic folks
21:28:09 sean-k-mooney this i beilve is what it sued form that lib https://opendev.org/openstack/tooz/src/branch/master/tooz/hashring.py#L30
21:29:37 sean-k-mooney Matko[m]: thos ecould also be commign form the keystoneAuth optiosn we add
21:29:44 Matko[m] yes, I found the usage of tooz. However there is nothing feeding the config to tooz
21:30:06 Matko[m] I did look into keystoneauth too
21:30:09 Matko[m] No dependency on oslo.cache or dogpile that might consume the config: https://github.com/openstack/keystoneauth/blob/master/requirements.txt
21:30:09 Matko[m] There is no trace of memcache in keystoneauth project: https://github.com/search?q=repo%3Aopenstack%2Fkeystoneauth+memcache&type=code
21:30:37 Matko[m] I'll ask the Ironic team then.
21:30:54 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/conf/ironic.py
21:31:10 sean-k-mooney that is where that config section is regeistered and its not an option we are addign explcitly
21:31:37 sean-k-mooney so that measn it coming from either keystoen auth or the sdk i think
21:31:46 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/conf/ironic.py#L128-L131
21:32:42 sean-k-mooney so if those have any effect i suspect it via the sdk/keystoneAuth common logic not anythin ironic specific
21:33:10 Matko[m] I looked into those as well and couldn't find anything. The openstack-helm code I linked to was added 9 years ago. And I wonder/suspect if it was a bad copy/paste from similar code in the chart for keystone_authtoken which has memcache configs.
21:33:38 sean-k-mooney did you check our current config ref
21:33:43 Matko[m] yes
21:33:47 Matko[m] I would also assume list_opts would list and include all the supported configs in the docs.
21:34:03 sean-k-mooney ya we generate the config ref form that
21:34:09 Matko[m] https://docs.openstack.org/nova/latest/configuration/config.html#ironic
21:34:37 Matko[m] if it doesn't ring a bell to anybody, then I'll conclude it was a bad copy/paste.
21:34:43 sean-k-mooney i dont see them there
21:34:49 sean-k-mooney so i think they are not used any more
21:35:13 Matko[m] alright, thanks for your help and time
21:35:14 sean-k-mooney i suspect they may have been used when we use the python-ironic client
21:35:22 sean-k-mooney we swapped to the sdk about 3-4 releases ago
22:33:50 opendevreview Ashish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures https://review.opendev.org/c/openstack/nova/+/980179
#openstack-nova - 2026-03-13
06:31:57 opendevreview Ashish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures https://review.opendev.org/c/openstack/nova/+/980179
09:04:57 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron Ports https://review.opendev.org/c/openstack/nova/+/969298
09:56:13 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron Ports https://review.opendev.org/c/openstack/nova/+/969298
10:14:25 opendevreview OpenStack Release Bot proposed openstack/nova stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/nova/+/980404
10:14:29 opendevreview OpenStack Release Bot proposed openstack/nova stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/nova/+/980405
10:14:32 opendevreview OpenStack Release Bot proposed openstack/nova master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/nova/+/980406
10:51:41 opendevreview ribaudr proposed openstack/nova-specs master: Move Gazpacho implemented specs https://review.opendev.org/c/openstack/nova-specs/+/979283
10:58:29 zigo What service is impacted for this? I
10:58:29 zigo The default value of [DEFAULT]/graceful_shutdown_timeout has been changed from 60 to 180 seconds for all Nova services. This means that when a Nova service receives SIGTERM, it will now wait up to 180 seconds for a graceful shutdown before being forcefully terminated.
10:58:29 zigo From Gazpacho Nova's release notes, I can read:
10:58:29 zigo Hi there!
10:58:39 zigo I'm guessing: nova-compute and nova-conductor, right?
10:58:44 zigo But scheduler as well?
10:59:24 zigo To me, it looks like, yes (reading the code).
11:02:13 zigo I think it'd be nicer for Nova to read what's in systemd, using the d-bus interface. Would this kind of patch be accepted (if made optional, since not everyone uses systemd) ?
11:16:07 gibi gmaan: ^^
11:16:42 zigo Am I missing something?
11:16:42 zigo oslo_service.backend.exceptions.BackendAlreadySelected: Backend already set to 'eventlet', cannot reinitialize with 'threading'
11:16:42 zigo Also, when attempting to run Nova unit tests, I get failure during test discovery:
11:17:13 gibi zigo: I think we agree that synchorizing the timeouts between systemd / k8s liveness probe / etc with the nova's shutdown timout is needed. But it is hard to automate it as it depends on how nova is deployed. It is not always systemd
11:17:31 gibi zigo: which python version are you using for the unit test?
11:18:02 gibi zigo: I think the graceful shutdown timeout change effects all nova sevices except the APIs. But gmaan can confirm
11:20:19 gibi zigo: we see similar unit test issue in py3.14 https://zuul.opendev.org/t/openstack/build/156fe0f67bff4e4da43a31bd0f02e667

Earlier   Later