[pve-devel] Cloud Init Questions

[Wolfgang Bumiller]

On Tue, Mar 13, 2018 at 11:27:31AM +0100, Dominik Csapak wrote:
> Hi,
> 
> since the cloud init patches got recently applied, i had a few questions to
> any one actually using cloud init
> 
> currently the instance-id is the hash of the config (afaics)
> so we trigger the cloud-init code for a new instance
> each time we have a differing config
> 
> isn't this a little too much? e.g. the ssh host key gets regenerated
> the sudoers file gets an additional entry (ok this is stupid on the cloud
> init side, but still),...

For reference - IIRC we initially did this because back when we started
it was the only way to get it to actually read the updated config when
changing something.

> 
> would it not be better to use the vmid for this?

If cloud-init in the versions usually found on current images
(debian-stable etc.) actually behave, then I'm all for it. Otherwise we
have to find some other way to deal with things like cloudinit's ssh
server key regeneration behavior...

> (e.g. having a cloud init vm which i clone would trigger that code
> only once after cloning, which is exactly what i want?)
> 
> since i am working on the gui portion for this, are
> there any special request from anyone for the gui?
> 
> should we include the password setting mechanism on the gui?
> (i would rather not)

For containers we currently only deal with passwords at create-time.
Since we cannot really go that way with VMs we may have to accept that
this needs to be part of the GUI. But even if not, we probably do want
the ability to *remove* via the GUI.
Personally I wouldn't recommend using this option anyway since you
either have plaintext passwords in the config (because "older" versions
(such as the one included in debian-stable) don't support pre-hashed
passwords) and that pre-hashed passwords - when not rate limited by
some server/client protocol - are pretty easily cracked anyway...
So this is mostly an option for private servers or test setups IMHO.

Also for reference: we did consider a password option for `qm start`
(iow. without storign it in the config) but the disk image would still
be stored on a storage other users may have read-access to in order to
create the ISO image read by cloud-init at run-time...