Conversation
362566c to
e6feb8a
Compare
|
@sabaini, thank you for the pull request. If this change is still valid, please resolve the conflicts and we'll get this reviewed/landed. |
33d2493 to
f7d0b31
Compare
88ed2e6 to
633d43c
Compare
Create a dedicated passwordless ssh key for bootstrapping the local juju controller. The default key (id_ed25519) cannot be relied upon: it may already exist and carry a passphrase. Fixes https://bugs.launchpad.net/snap-openstack/+bug/2054328 Assisted-by: pi:openai/gpt-5.6-sol Signed-off-by: Peter Sabaini <peter.sabaini@canonical.com>
|
I'm on the fence for this change because I believe it's not a great idea to actually deploy Sunbeam on your work laptop directly. This provides a bit of friction, but it allows the end user to double check what they are doing. It's not a great feature, and we might want to address this another way. Juju and Sunbeam will take full root ownership of the machine. |
|
@gboutry there may be reasons a user puts an ssh key on the machine being used for sunbeam commands other than it's a work laptop. Since openstack is a strictly confined snap. Why are we putting data in a user's .ssh directory to begin with? Are we leaving pieces behind when
How does this work in the case of sunbeam bootstrap with an existing juju controller functionality, or the case of a MAAS config? No reason to take over an entire machine in that case. The prepare script is also too permissive if so. It needs to warn users when unexpected things exist. We cannot solve the entire problem in this one PR. I'd say that prepare sunbeam is doing the wrong thing per ssh files. |
3 participants
Create a dedicated passwordless ssh key for bootstrapping the local juju controller
Fixes https://bugs.launchpad.net/snap-openstack/+bug/2054328