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?