[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: feature for building docker base images in anaconda

On Wed, Mar 19, 2014 at 02:15:22PM -0400, Chris Lumens wrote:
> > I'd like to create a fedora feature for this, but I, um, don't intend to
> > actually do any of the coding. I can talk about what's needed until I turn
> > blue, though, and test things and so on. Would anyone like to raise their
> > hand to help?
> I don't think you're going to find anyone here that has the patience to
> do an official feature.  That's not to say we're not interested in doing
> the coding work, just that we can do without the administrative
> aggravation that comes with it.

I'm offering to take on the administrative aggravation side of it if someone
will take on the "actual work" side. :)

> > Basically, we need something that:
> >  - takes a kickstart in
> >  - outputs a tarball of /
> 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.

> >  * 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.

> You're not going to have ksdata.realm.packages unless you specifically
> ask for support.  storage.packages is likely only going to be e2fsprogs
> unless you specify partitioning with lvm or btrfs or multipath.  So that
> just leaves authconfig and firewalld, both of which are listed as
> default in core.
> The reason those two are required by anaconda right now is that we need
> to be able to run them on the target system.  authconfig, at least, we
> always pass some arguments to.  I guess firewalld will always do
> something even if we're telling it to disable the firewall.

Actually the firewalld case is already fixed. So I guess it's just
authconfig left.

> >  * 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.

> > Bonus:
> >   * anaconda run in its non-vm mode to reduce build time and resources.
> >     In fact, it'd be ideal to be able to run this _inside a docker 
> >     container_.
> I guess you would have to try anaconda --dirinstall like this and see
> what happens.  I've not, so I don't know if it would work or not.

I'll try. Thanks.

Matthew Miller    --   Fedora Project    --    <mattdm fedoraproject org>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]