> I'm offering to take on the administrative aggravation side of it if someone > will take on the "actual work" side. :) I think we've been chipping away at the work for a while now, so I think as a group it can get dealt with. > > It feels like you might need some sort of wrapper around anaconda that > > does the argument passing for --dirinstall --kickstart= etc. and then > > bundles the results up into a tarball. > > And actually, there is an imagefactory plugin which provides that wrapper, > so that might be sufficient. It'd be nice, though, to have something > built-in for simplifying the case of running it by hand. Well it could be a wrapper distributed with anaconda. I guess I see anaconda's role as taking an input specification (kickstart, though that kickstart may take the form of UI interaction these days) and producing as output an installation to some destination. If you want to further process that destination (in this case, by packing it up into a tarball) then that should be done by some other program. We've got other anaconda wrappers laying around (liveinst being the most visible example) so it's not that weird of a suggestion. > > > * don't add any packages not in the explictly-given package set + rpm reqs > > I think at this point you're talking about this line: > > packages = storage.packages + ["authconfig", "firewalld"] + ksdata.realm.packages > > Yeah, that line, and some sort of general expectation that it won't grow. We don't often add to this list. > Actually the firewalld case is already fixed. So I guess it's just > authconfig left. Where are you seeing that firewalld is fixed? > > > * Create /dev/tty1 and /dev/loop# devices statically > > > * soft-link /dev/tty1 to /dev/console > > > * anonymize images with no /var/lib/random-seed or other supposed-to-be- > > > unique elements (/etc/hosts?) > > > * disable /tmp on tmpfs > > These are all awfully specific things that I would prefer to keep out of > > anaconda. Remember that kickstart files can %include stuff. You can > > distribute a base one that does all the fancy stuff and then tell people > > to %include it in their own. > > Hmmm. I'm looking for something that's as lightweight and user-focused as > possible. Otherwise, someone is going to come along and write yet another > image creation tool which _does_ cover those cases, and we'll be back to > appliance-creator all over again. Well I certainly do want to cut off more not-quite-installer tools from getting written. But there's a couple things that worry me here. First, like I said, it's a pretty specific set of tasks that applies to one specific function - making images for docker to use. I don't like the idea of adding something so very specific into code that's trying to handle a variety of installations. Second, this feels like something that's going to grow and shrink over time. We're going to be constantly chasing it. Or, we can put someone who knows what's needed in charge of maintaining it. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
