[PATCH 3/3 rhel7-branch] atomic: set up atomic specific partitioning defaults

Vratislav Podzimek vpodzime at redhat.com
Thu Oct 23 07:32:33 UTC 2014


On Wed, 2014-10-22 at 19:34 -0400, Colin Walters wrote:
> On Wed, Oct 22, 2014, at 06:16 PM, Brian C. Lane wrote:
> 
> > Not that I know of. They are actually just updates.img but are loaded
> > automatically when found in the images/ directory.
> 
> That would only work for PXE though - someone couldn't just download an
> ISO and go, right?
The product.img is downloaded automatically from the repository's
images/ directory. So an ISO pointing to the right repository would
work.

> 
> > Ah, ok, host setup. From reading those it looks like there is no
> > consensus on it, so that would fall into the realm of using kickstart
> > commands to set it for that admin's particular case.
> 
> No consensus about what?  So filesystems are going to evolve over time -
> there's overlayfs coming down the pipe, and who knows, maybe BTRFS.
> 
> But at the *present* (EL7, Fedora 21/22) there is a consensus of direct
> LVM space for Docker.  It's the technology we have now that works (with
> SELinux, among other things).
> 
> And the user experience really needs to be that for Atomic installers,
> they have optimal defaults when clicking in the UI via an installer ISO.
> 
> Theoretically with LVM + ext4 you *could* fix things up after the fact
> by shrinking the rootfs and then carving up the remainder for direct
> Docker.  But for XFS-based install classes - XFS doesn't support
> shrinking.    That means the Anaconda defaults are far more critical.
I understand your point, but adding quite a lot of code to Anaconda that
would try to reflect current "state of the art for Docker" doesn't seem
like a great idea to me.

Do you expect people deploying big numbers of mutually different
machines/setups as Docker hosts? And aren't current capabilities of
kickstart 'part' syntax enough? What beyond 'part --size=SANE_DEFAULT
--grow' is needed?

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list