On Fri, Dec 5, 2014, at 08:34 PM, Brian C. Lane wrote: > Projects could do a much better job of maintaining and distributing > their kickstart snippets. Kickstart even supports including other > kickstarts. Yes. I'm doing that when generating Vagrant images, which inherit from the cloud image. Though I did run into a small issue there that confused me for a while with services --enabled vs disabled; see: https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?id=de8e30948143f48d9cafe1c76c2e589ddae5fb0b > Look at the number of switches there. There is no one right way for us > to know which way the user wants it setup. For this specific case it > would be useful if virt-sysprep could run from %post, letting the user > configure the image the way they want. Right. Though doing it in %post requires it to be in the install tree, which I think most users won't want. Hmm, to make this really work we'd have to extract the "delete files from a target filesystem" part of virt-sysprep from the "mount and inspect VM disks using libguestfs" part. I haven't looked to see how hard that would be. CC'd rjones. Richard: This discussion is about anaconda-for-templating versus anaconda-as-installer, and for the former we want a lot of the "sysprep" aspects of virt-sysprep. Anyways, I see your point. Of these issues though, I think the one that could really use fixing in anaconda-for-templating is the networking issue. It's still possible to hack it in kickstart, but the fewer places we have writing "initscripts" style ifcfg files, the better. As far as priorities go though, good cloud-init integration is much higher. It'd enable some cool new user-facing features, whereas this is mostly internal and for the much smaller audience of people generating disk images. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
