On Fri, 2014-12-05 at 16:36 -0500, Colin Walters wrote: <snip> > > 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. Do they have a Python 3 version/support as well ? We are in the process of dropping Python 2 only dependencies (pyblock, urlrgrabber, etc.) so that Anaconda can run with Python 3, as a needed by the Fedora 22 "Python 3 as Default" system-wide change[0]. So adding new Python 2 only dependencies would not make much sense. > (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. [0] http://fedoraproject.org/wiki/Changes/Python_3_as_Default _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
