Re: [gentoo-dev] Re: where goes Gentoo?

["Brian D. Harring" <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 8194 bytes --]

Long one kiddies... responses inlined, bit more interested in 
discussion of what's required/desired then "your definition of 
enterprise sucks"... (throws on the flamesuit)...


On Thu, Aug 04, 2005 at 02:35:08PM -0400, Chris Gianelloni wrote:
> On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote:
> > Every business application of Gentoo I've done has been different.  I don't think I could generalize my needs into a single ebuild.  Although generally I have used rsyncd and apache, I never use them in the same way.  What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use).
> 
> You completely missed the management aspect here.  I'm talking about
> some form of actual enterprise-ready management framework for
> controlling a set of Gentoo servers centrally from deployment to
> maintenance and upgrades.

Elaborate on what you explicitly want out of portage please- the 
domain concept (aside from being useful design wise) *should* allow 
groupping of boxes (groupping of domains really) behind it, so you can 
effectively have a set of boxes, pushing changes to each.

Mind you no code written, but current design is intended to allow 
remote chunks to be swapped in/out of portagelib on the fly 
(including the actual portage configuration).

> > About automating updates and etc-update:  you can rsync your config file sometimes and just bypass all of the portage stuff.  You could mount some config dirs over nfs even.  You could even remove config_protect on some dirs and roll your own custom packages.
> 
> You can... You can... You can...
> 
> All I heard here was a bunch of excuses about how a person can take the
> time to implement something that's been implemented by countless other
> people, because Gentoo does not provide a framework for doing this.  The
> whole idea of being enterprise-ready is having a drop-in solution that
> works right off the bat, with minimal to no configuration for basic
> services.  All of your solutions requires manpower to accomplish that
> not every enterprise can afford to spend.  Once again, this is why
> Gentoo is currently not used in these situations.

Better angle of discussion rather then "we aren't there yet" is the 
specifics of what is needed to *get* there in peoples opinion.

It's not an overnight thing, glep19 (stable portage tree) addresses a 
chunk of concerns when/if it's implemented, but I'm a bit more 
interested in the the other tools people desire alongside.

Re: a drop-in solution, considering that gentoo is effectively all 
over the map (seriously, look at the tree), define the profile for the 
drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc.

Specifics...

Hell, I have yet to see what I would define as a proper solution for 
config manamagent for N gentoo boxes.  NFS solution possibly, but that 
seems a bit hackish to me.

> > This brings me to your last point about calling someone when there are problems:  There are companies that provide Linux services, even Gentoo specific services.  Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there.
> 
> I don't think I would stake my company's infrastructure on the reliance
> on Bob and Joe's Gentoo Support Hotline, sorry.  Not to mention you
> haven't actually given a single example of someone who can provide this
> level of enterprise support.  There's a reason why you haven't given an
> example.  None exists.

Moot point frankly, considering we're all volunteers; someone 
*could* get off their butts and start up an attempt to provide hand 
holding (effectively what you're coloring the management arg as) 
services, but even if they did, the followup arg would be that you 
can't yet trust this new support company, because they're new.
Etc.

Basically, we don't have control over that portion, so... what 
can be mangled that we *do* have control over, and has an effect?


> 
> [snip]
> In the computer industry, an enterprise is an organization that uses
> computers. In practice, the term is applied much more often to larger
> organizations than smaller ones.
> 
> We are using this in practice.  Therefore, we are speaking of large
> organizations, and not just *any* organization.

That's a really crappy description, rather nebulous. :)
And... nobody probably cares about loose definitions, 'cause loose 
definitions are moving targets.  Again, specific suggestions/requests 
would rock.

Mentioned management tools, well, get into specifics; pxe network 
installs/imaging?  Single tree/cache for N servers?  Ability to push 
updates out to a specific box, or set of servers?  Integration of 
portage contents db with IDS tools?


> Novell has several tools, that when used in combination, form a cohesive
> framework for deploying, managing, and upgrading systems.  What's even
> better, is it isn't just limited to Linux, but I'll leave that as an
> exercise for the readers... ;]  Novell uses a combination of these
> components, such as eDirectory and ZENworks, to form this framework.
> 
> > Maybe we can't rely on portage so much in scenarios where replication is the goal...
> 
> Portage really has nothing to do with deployment or management.  In
> fact, the only thing it really does is package management, which is
> probably why it is called a package management tool, and not an
> enterprise resource manager.

Any enterprise resource manager is going to have to fool with pkgs at 
some point- that's my line of interest in this.


> Sorry, but I'm not calling vapier and listening to him tell me about his
> wang when I have an issue with LDAP replication that I need resolved
> immediately as my customers are starting to call in quite irate.  I
> would want a company with a dedicated staff on-hand to support my needs
> that is available when I need them.

See bit above about being (effectively) outside of our control (a 
niche someone with a brain could exploit also).

Besides, it would be pointless to call vapier to hear wang tales; just 
stick your head in #gentoo-dev, you get them for free there...

> > I wouldn't refute my manager's claims if he controlled my paycheck :D
> 
> Haven't you ever been in a meeting?  You know, where they ask your
> opinion.  Are you a drone?  Do you just do everything that you're told
> and question nothing?
[snip]

If it's going to descend into a bit of flaming (has it already?), I'll 
gladly go back to poking at portage- I'd rather see something constructive out of this, 
you obviously see areas where gentoo isn't up to snuff (as do I)... 
so... what would be useful to implement *now*, what would be required 
*down the line*, etc.

Mind you, our hands aren't bound, their are areas that work can be 
done in.


> Gentoo is currently unmaintainable at this scale without a significant
> investment in infrastructure and development to make the system
> manageable.  Think of it this way, if I can pay 4 developers to work on
> this project for 6 months, and each developer makes $50,000 a year, or I
> can pay Novell $100,000 and have the system in place in 2 weeks, which
> do you think I would do?  This is the exact reason why Gentoo is not
> used in the enterprise more.  There is simply too high a barrier of
> entry into making a usable and manageable Gentoo deployment.
Or, you find a collection of trained coder monkeys who are oddballs 
who might have an interest in implementing this stuff on their own 
time, and try to nudge them in the correct direction; no, this isn't a 
solution, but again, having an ent. solution (going by your statement) 
isn't going to be funded by anyone.

Ok, fine.  So it goes.

Meanwhile, reiterating my point, I'd rather see a discussion of what 
people *want* in the way of tools, then "we aren't there yet".  
Generally known that you have to roll your own somewhat for tools, 
well, would rather know what people want then see then another round 
of kicking the dead horse.


~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]