Anaconda is used in many different ways, there's things like the Live versus traditional, multiple architectures, etc. One of those major axes is the difference between generating "images" or "templates" versus doing actual installations. Current examples of templating are: - Cloud image (via ImageFactory TinMan) - Docker base image (via ImageFactory TinMan) What's the difference between the two? A good example is /var/lib/systemd/random-seed: https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n190 I would argue that Anaconda should be taking on the role of assisting with things like this. It shouldn't be for people to hack up in kickstart files. Another *major* issue with Anaconda-as-templater is networking. See this thread for example: https://lists.fedoraproject.org/pipermail/cloud/2014-November/004663.html There needs to be some way to sanely distinguish between networking for the ImageFactory environment versus the *target* network configuration. There's of course other stuff you can see in the cloud base, like yum history. Another major bug we have is the systemd machine ID. This really needs to be generated on first boot, not hardcoded into the image. Systemd has bugs in this regard, but they're being fixed; see: http://lists.freedesktop.org/archives/systemd-devel/2014-December/025783.html High level strawman: A kickstart verb like: system --template This would instruct anaconda to perform the equivalent of: http://libguestfs.org/virt-sysprep.1.html I'm not sure how to handle the networking issue. Perhaps a reasonable first step would be network --template-environment=dhcp # for the ImageFactory run network ... # applies to target _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
