Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-12
15:35:49 sean-k-mooney oh you mean in the guest rather then on the host
15:35:52 dansmith yes
15:36:07 sean-k-mooney ack
15:36:22 dansmith I meant expose your root password to any random untrusted thing that is running that can read world-readable things on the filesystem
15:36:22 sean-k-mooney i tought you ment an operator or soemoen with acess to read the file on the host
15:36:42 sean-k-mooney but yes so it wont automoutn by default however cloud init will do that
15:37:00 sean-k-mooney so if you have a clodu iamge i think its bindmounted in o /etc/cloud/config....
15:37:38 sean-k-mooney i have never looked at hwo that is doen in the guest really so im not sure what permissison it will use
15:37:53 dansmith Windows will "mount" it automatically and a general-purpose OS would automount it
15:38:06 dansmith like ubuntu-desktop would end up with it mounted
15:38:32 sean-k-mooney oh right the DE(gnome) ectra woudl
15:39:02 sean-k-mooney not really sure now to avoid that other then contineut to advise agians enabling the fature
15:39:03 dansmith since cloud-init won't set the root password from that (AFAICT) then it's not a big deal there, but on Windows where cloudbase-init would/did it'd be readable
15:39:27 dansmith advise against enabling what, configdrive?
15:39:43 sean-k-mooney the admin password injection
15:39:49 sean-k-mooney not config drive
15:40:04 dansmith there's no way to disable that part AFAICT
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 $ grep -Po admin_pass.*?, /mnt/openstack/latest/meta_data.json
15:43:09 dansmith admin_pass": "CExk4PUfQLgA",
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] There is no trace of memcache in keystoneauth project: https://github.com/search?q=repo%3Aopenstack%2Fkeystoneauth+memcache&type=code
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: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

Earlier   Later