Re: [gentoo-dev] Enterprise Installer [was "LWE Aftermath" on -core]

[Joshua J. Berry]

On Fri, Aug 06, 2004 at 05:05:12PM -0400, Chris Gianelloni wrote:
> On Fri, 2004-08-06 at 15:26, Joshua J. Berry wrote:
> > No, a profile a la Gentoo's Portage profile probably isn't ... I just used the
> > term "profile" to mean a specific set of installed packages and configuration
> > options (e.g. have a "mailserver" profile, a "webserver" profile and perhaps a
> > "workstation" profile).
>
> You mean something more of an installation type, rather than a "profile"
> then... Make sure we don't re-use terminology that could be ambiguous in
> meaning.

No, I do mean a profile-ish thing ... install is just the first step in maintenance.
Suppose you have a bunch of preinstalled workstations and you want to push out
another app.  How do you do it?  Add it to the profile-ish thing.

> I guess I am saying the process to create a LiveCD is a bit more
> involved than needed for most cases.  Using a network boot method plus
> some scripts would be much quicker and cleaner.  It also wouldn't
> require lugging around a CD, which means the CD must be kept up-to-date
> with changes and other such problems.  Definitely not the best way for
> the enterprise to go about it.

You're right.

> This isn't designed for the guy wanting a few machines, though he would
> be able to utilize it.  It would probably still be quicker than creating
> a custom boot CD.  Especially since if we were to create it, we would
> make it simple for the user.  It would probably end up no harder than
> creating a catalyst .spec file to begin with, so why take the time to
> make a CD out of it?

The point I was trying to make is, we should--eventually--support both options.
We don't need to do it immediately, of course, but it should be there.

> Also, stick with scope here.  Are we talking the guy with 10 machines or
> are we talking the ENTERPRISE where we're considering hundreds or
> thousands of machines.  Having to go to each of a thousand machines with
> a CD can be tedious.

Enterprise, for now, which can eventually be scaled down to work with the guy
who has 10 machines and want to use it at home.

> > Some admins may wish to perform their own QA on the Portage tree before pushing
> > things out to their userbase, or perhaps create custom ebuilds for proprietary
> > software they have purchased and want to run on Gentoo.
>
> What makes this different than one of several methods:
>
> - The admin runs his own rsync mirror with only his "QA certified"
> ebuilds in it.
> - The admin NFS mounts his "QA certified" portage tree.
> - The admin pushes out his "QA certified" portage tree as an overlay.
>
> Personally, I think the first is the best.  Remember, the admin does not
> have to offer up *our* tree for rsync.  If he decides to standardize on
> KDE and doesn't want anyone running games, he can rm -rf
> /usr/portage/gnome-* and /usr/portage/games-* and even add them to his
> RSYNC_EXCLUDES.

The first is pretty much what I was suggesting.

I realize this can be done now, but there should--eventually--be tools to make
management of custom trees easier.

> I'm not sure you understand the scale of such a project.

I think I do.  I explored this idea (on a more limited scope, of course) when I
was working for Cal Poly's CSC dept last year.

> Something like this would require an enormous dedication and a very
> far-reaching plan.  To be honest, even if you're just starting school, I
> wouldn't expect to see this even at a remotely close to completed stage by the
> time you graduate without some serious financial and manpower backing.

I understand that.  But if we don't start somewhere, such a project will never
be completed.

> > If enough people are willing to work on this, we should start (yet) a(nother)
> > project.
>
> Instead, what needs to be done rather than start yet another project
> which will go dormant in 6 months, is to get everyone interested
> involved, including any other projects that would be encompassed, such
> as the installer guys, and actually put something together and stick
> with it.

How is this different from creating a project?

> The real problem is that these sort of things are pretty boring to bring
> about.  Interest wanes quite easily when working on a project of such a scope.
> Rather than come up with these huge, elaborate plans, what needs to be done is
> baby steps need to be achieved.  Take everything step by step.

Portage wasn't written in a day.  I understand your point about baby steps, but
how do you expect to get anywhere if you have no idea of where you're going?

> > This means--and this has been brought up repeatedly before--there needs to be
> > some sort of for-profit company, separate from the non-profit, that has at least
> > a few full-time Gentoo devs on its staff.  Or so it seems to me.
>
> Gentoo Linux is run by a not-for-profit company for a reason.  We do not
> want corporate interests guiding us.
>
> What would need to be done, is a separate entity would need to be
> established.  This entity could be owned by the Gentoo Foundation, or
> completely separate.  It could be manned by Gentoo devs, or just users,
> it doesn't matter.

Yes.  This is pretty much what I was suggesting.

> The main problem with doing this and PAYING people
> to work on the system is the sheer amount of capital that would be
> required to operate such a venture.  I would guess that you would be
> paying the entire staff for at least 2 years just to get to the point of
> being able to offer a supportable product.  After all, every single bit
> of the supported tree would require developers to back port fixes.

I don't know enough about how companies work, or how much it would take to get
the Portage tree into a "supportable" state.  If this is the case, then perhaps
creating a separate for-profit company wouldn't be feasible, and the list of 3rd
party supporters is a better idea.

> > The first step is always to figure out where you want to go ... I think we're
> > doing that now.  Then we just need to break the problem down into small pieces.
>
> We figured out where we wanted to go the last time this came up... and
> the time before that... and the time before that... and the....

Where's the plan, then?  Has anybody written up a coherent plan, broken the
tasks down into small steps, and posted it somewhere?

> I've given a good starting point, a frozen tree.  Since such a thing
> would require buy-in from -releng (not a problem), -infra and the mirror
> admins, and the management, it needs to be brought up at a manager's
> meeting and voted on, preferably with some idea of the additional mirror
> space and some initial feedback from all the parties involved.

I certainly don't have a problem with a frozen tree; I think it's a good idea.

But I guess I'm not entirely sure how a frozen tree would help us here ... I
think we might be talking about two different things.  I was talking mainly
about providing a way for large sites to painlessly configure/install/maintain
Gentoo on lots of machines.

> > > > On a related note, avenj did mention the Installer project to me, and gave me a
> > > > link to their CVS, but it hasn't been touched in a few months.  Anyone know what
> > > > their status is, and what specifically they're trying to accomplish?
> > >
> > > I believe their charter was to create a nice installer that could be
> > > used to install Gentoo in various fashion, using GRP as a base and
> > > allowing for rapid deployment of servers and workstations based on
> > > pre-defined criteria.
> >
> > That sounds like it's the first (big) step then.  Let's get an installer
> > working.
>
> What would the installer *do* exactly?  That is a VERY large step to
> take... or at least I think so.  Does the installer perform a stage1
> install? stage3? GRP? GRP + more packages?  Does it use the portage
> snapshot each arch lead makes for his release?

Well, it is a big step.  We're not really ready to start doing that yet.  

Like you said, we need to take baby steps.  Let's get/make a list of those for
the installer.

> Wouldn't it be easier to do with a frozen -release tree? (In case you're
> not getting it, I want a frozen tree... *grin*)

OK, so let's make a frozen tree.  But that doesn't have much to do with
configuration/installation/maintenance of lots of machines. ;)

-----------------------------------------
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

NOTE: Please do not submit this email address to any mailing
lists or websites without prior permission.  Thank you.