On Thu, Oct 23, 2014 at 08:48:19AM -0400, Colin Walters wrote:
On Thu, Oct 23, 2014, at 03:32 AM, Vratislav Podzimek wrote:
> 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.
There are 2½ different cases of ISO:
1) boot.iso - you download content from the network, requires networking
Fedora/RHEL/CentOS all have this.
2a) installer.iso - content is embedded, works offline, but no software
selection
CentOS has this for a minimal package set, and it's *very* popular.
We want this for [distribution] Atomic.
2b) DVD - lots of content is embedded, works offline
This is the old-school vision from Red Hat Linux days. Has its uses
where internet connectivity is poor.
product.img is fetched from images/ for all these cases. The code lives
in dracut/anaconda-lib.sh in anaconda_live_root_dir if you're curious.
Right now Fedora does not generate an installer.iso, but we definitely
want one for Atomic. Which as far as I can see precludes the online
product.img approach.
Note, it isn't always online, it pulls it from the same place it finds
squashfs.img
So...since we're already running lorax with custom layout to embed the
content (as well as brand), we could certainly dynamically inject code
at that point. But I'm wary of maintaining this over time. Now, I do
understand your concerns about maintaining many autopart variants over
time. Except I don't see it as having to be such a hard and fast "you"
versus "we". I'm on this list too, even if 95% of my time is on other
projects. But I certainly don't plan to just drop some code and then
disappear.
> 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?
Yes - I expect well-maintained production deployments to PXE +
kickstart, but it's also important to have a good default experience
from an offline ISO installer. If nothing else, that's what the media
tend to review =)
My point in the previous message was that it looks like every user of
docker is going to have their own ideas about how their host is setup,
how to divide up storage, how to name things, use thinp or btrfs, etc.
These are the things that kickstart excels at, letting the admin decide.
From what I've read so far it looks like any kind of docker
autopart we
decided to implement would be wrong for a significant number of users,
which makes it better to just teach them how to use kickstart commands
to get what they want.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)