To me it seems there are several possible levels of cloud-init
integration here
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. 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.
2) Another step may be modifying installation by cloud-config (ie users
configuration in installer derived from cloud-config values).
3) For both approaches we may want to generate/modify cloud-config via
GUI (addon?).
I have doubts about making cloud-init embedded in kickstart as
additional installer configuration using another format (2) above).
Keeping the domains of the tools strictly separated (ks for
installation, cloud-init for post-reboot configuration 1) above) seems
like less pain and cleaner way to me. But maybe the interference between
the two in installer is manageable easier than I imagine.
On 12/05/2014 10:36 PM, Colin Walters wrote:
Fedora right now has three products, and I'm going to ignore Workstation for this post.
Server: Download boot.iso, configure via kickstart
Cloud: Download qcow2 image, configure via cloud-init
Anaconda is used in generating the Cloud image (see my previous post about ImageFactory), with the resulting issues there.
But note the kickstart functionality is not accessible to the Cloud user. Instead, cloud-init is the pervasive way to configure cloud images.
But if you look at this, cloud-init actually has a lot of great features that *also* make sense on bare metal. A good example is ssh key provisioning. Look at the "ssh-authorized-keys" entry in the YAML here:
http://cloudinit.readthedocs.org/en/latest/topics/examples.html#including-users-and-groups
Kickstart has no declarative syntax to update the ssh keys for a user. And this lack of support is actually reflected in the Anaconda UI/framework logic - it won't let you proceed unless you have a root password or an administrative user (with a password) But ssh keys are *more* secure than passwords, and we should strongly encourage their use.
In the RHEL6 era, people of course did it in %post, but there was a common trap around SELinux labeling:
https://www.redhat.com/archives/rhelv6-beta-list/2010-November/msg00005.html
Basically I'd like to discuss pulling in cloud-init into the installation environment. Ideally, I could chain kickstart -> cloud-config.
Say a new toplevel verb like this in %kickstart:
%cloud-config
users:
- name: walters
ssh-authorized-keys: ssh-rsa ...
%end
The simplest way to implement this would be to simply dump the file into /var/tmp on the target system, and then have the cloud-init program execute it on boot.
But to fix the issue of anaconda being unaware of ssh keys as a valid way to log in would require parsing it in the install environment and looking at the users stanza.
At a high level, I think this is a good architectural match; both programs are Python 2, etc. (cloud-init is GPLv3 though...hmm)
cloud-init also has a lot of popularity due to its cross-distribution nature.
Finally, the reason I bring this up is because I work on Project Atomic, and as part of that one of the features we're investigating is a PXE-to-Live scenario. For that, cloud-init is a perfect match, because it's designed to configure an already existing system (versus kickstart which is designed to be processed for an installation). Laying the foundation with regular bare metal support for cloud-init would help this as well.
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
