On 12/08/2014 03:25 PM, Colin Walters wrote:
On Mon, Dec 8, 2014, at 08:16 AM, Radek Vykydal wrote:
1) first step would be to allow configuration of cloud-config source and
its application after reboot - by means of ks or gui, by specifying URL
or supplying the configuration values.
Below you mention doubting the "embed cloud-init in kickstart" approach,
so how would a user specify a cloudconfig?
My concern here was not specifying cloudconfig in kickstart (be it
poniting URL
or by embedding the yaml) which is OK, but using the content
of cloudconfig "as additional installer configuration" (vs using
post-reboot only)
by which I mean parsing it in installer and changing installation data
(eg those concerning user settings) based on it.
I could imagine an
inst.cloudconfig=http://example.com/blah.yml
kernel commandline option?
This seems like it could work quite well if cloud-init covers everything
you need. Conversely, looking at the feature overlap of kickstart
and cloud-init, the latter is lacking sophisticated storage management.
In other words, you could only use inst.cloudconfig if you were happy
with autopart. Even that strikes me as a bit too magical.
This sort of thing is why I was thinking it was most realistic to combine
the strengths of the two and support embedding cloud-init in kickstart.
Yes, definitely using both. But again, kickstart for installation,
cloud-config for first boot configuration. I am not sure if
benefits of using cloud-config as another installation configuration
source are worth it. I mean are there enough reasons we should
make anaconda care about content of cloudconfig (read and
use it during installation)? Do we have any other examples
then users / ssh keys case?
Then it's only for PXE-to-Live that you can skip kickstart and use
cloud-init alone.
Anaconda would just add
appropriate boot option (eg ds="nocloud-net;seedfrom=<URL>" for
cloud-init --url=<URL> in kickstart) and perhaps drop the cloud-config
to the target filesystem for the configuration created in installer. No
processing of cloud-init would happen in installer. So for users/keys
case we'd then probably need a way to configure users in ks saying that
they will be configured by other means so incomplete configuration is
valid. Users/keys in kickstart and cloud-config need to be kept in
accord by the user.
Yeah. I think we want a way to declare this in kickstart regardless of the
cloud-init effort.
2) Another step may be modifying installation by cloud-config (ie users
configuration in installer derived from cloud-config values).
This is an interesting topic on its own; what would be the value of
doing useradd at install time versus on first boot?
I think my example was misleading, creating users seems more like a job
for cloudinit. Anaconda shouldn't just require creating of users in case
cloudinit takes care of it. The difference between 1) an 2) level of
cloud-init
support here would be that, having users configuration in cloudinit,
in 1) user would need to specify something like users --otherconfig in
kickstart, while
in 2) anaconda would automagically, based on reading the cloudconfig, not
require a user created in installer.
Radek
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
