Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for November

[Robin H. Johnson]

On Fri, Nov 03, 2006 at 08:47:52AM +0000, Steve Long wrote:
> As to why I don't just do it myself, I think it's a bit silly to duplicate the
> compile that devs do anyway.
My compiles as a dev are of very minimal use to anybody except me.
There are too many things that are specific to my systems.

> I appreciate that many will be against this idea, but I'd still like to
> discuss it: a binary repository for gentoo.
>
> Yes, I know gentoo is a meta-distro. And that there isn't loads of bandwidth.
> That's easily got round. The main problem I see is USE flags (devs already
> compile with standard C-flags right?) but I was thinking about standardising
> for 2 or 3 types of network- SOHO, medium and large enterprise (eg for LDAP
> etc) would solve most cases. We can always tag pkgs with USE flags.
>
> If gentoo is still serious about enterprise adoption, it needs a binary repo
> (so we can avoid system breakage) which would of course be a little bit
> behind. I'd be happy to contribute time, as I'm sure many other users would.
From all of the large Gentoo deployments I've done (one of which
exceeded 200 machines), you're approaching this the wrong way.

1. Consider where each enterprise needs customization: USE-flags, CFLAGs
This might be for example an LDAP or Kerberos-based shop, so they would
have their stuff built with those, or a hardened or selinux place. Or
SASL, or Java or any of a hundred different variables. This was after
all the point of USE flags in the first place.
2. From point one, it is clear that each enterprise needs to be able to
customize. They also need binaries. So we need a solution that combines
the two.
3. The solution is for each enterprise to have their own tinderbox /
build-machine. Tinderboxing is supported under catalyst, and I believe
there is at least one other tinderbox implementation around.
4. (Assuming catalyst, as it's the only tinderbox I'm familiar with) The
enterprise defines a specfile that describes each of their unique
environments, and feeds these to tinderbox. Tinderbox generates sets of
binpkgs for each environment, which the enterprise then deploys.

The above plan works perfectly - I use it in my enterprise deployments.
To use the example of my largest deployment that I mentioned above, my
specfiles were for the following:
- cluster nodes [128 machines]
- cluster master [1 machine]
- web servers [~60 machines]
- ldap servers [2 machines]
- dedicated file serving (network homedirs) [4 machines]
- infrastructure management [3 machines] 
- desktops [~60 machines]

The build-box role was actually undertaken by one of the infrastructure
management machines, since it doesn't need a dedicated machine.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85