[Novalug] RHN Satellite

James Ewing Cottrell 3rd JECottrell3@Comcast.NET
Tue Jan 17 23:56:41 EST 2012


On 1/17/2012 6:28 PM, greg pryzby wrote:
> Since it keeps disappearing-- I DO NOT SPEAK FOR MY EMPLOYER
Well, you're doing a damn good job at not embarrassing them.
> On Tue, Jan 17, 2012 at 5:27 PM,<jecottrell3@comcast.net>  wrote:
>> Most places I have worked at ran very thin...it's hard to get money for ANYTHING, no matter how good or badly needed.
>>
>> Hmmm, I wonder why RH backed off the DB business. Probably some interesting tales there.
> Nope. if you don't have engineers working on the code, you can't
> provide the level of service required for an enterprise solution, in
> my experience. I don't believe there is conspiracy.
But that is RedHat's game...tinker with the Good Stuff and Make it 
Better. So why did RHT abandon Postgres?
>> When I said Poor Design, I mean in Tightly Coupling a Database Client to a Database Server.
>>
>> The DML part of SQL is easy, and libraries such as Perl's DBI/DBD, JDBC, and probably ODBC handle normal Operations well.
>>
>> More complex operations, like Starting, Stopping, Load, Dump, Clone, Snapshot, Whatever can be handled by PlugIn Scripts.
> Did you do any database work on the 90s?
No.
> Just curious. I know MySQL did not support transactions. I don't
> recall when PostgreSQL did. Choices were limited, very limited for
> enterprise. Without transactions, you can't trust a database. At least
> I wouldn't.
Well, it's not clear that RHNSS even *needs* transactions, but there ARE 
other ways to accomplish the same thing.
>> More to the point, it should have been designed with Multiple DBs in the first place. And Oracle should have been the third DB looked at.
>
> My recollection is in the 90s the database that ran on Linux that did
> transactions were VERY limited-- Oracle and Sybase.
Why are we talking about the 90s?
>> Are you seriously telling me that Oracle is required for anything less than 1000 machines? Heck...many site top out at a few hundred.
> Nope. I didn't make any claim about # of machines or any such thing.
No, I just made the assumption that number of records and or queries was 
a concern.
>> Ten years to me is Just Yesterday.
> It seems like yesterday to my memory, but in the computer world and
> what I can and do do with computers has changed drastically. I hope
> you didn't mean you are doing the same thing from 10 years ago w/ the
> same technology.
OK, I was just reading a discussion from Two Years ago ...

http://magazine.redhat.com/2008/05/07/a-special-note-for-red-hat-network-satellite-users/

...that discussed the lack of an alternative to Oracle. That was almost 
Four Years Ago! There should be Postgres and MySql support in RHNSS by now!

Yes, Open Sourcing SpaceWalk is definitely a Cool Move, but *please* 
re-import the code, OK?

>
>> One more thing...RHT salesman must not be Proud of the fact that SS uses Oracle...they never mention it...nor do the blurbs...you have to drill down into the docs to find that out.
> It is an appliance. It shouldn't matter.
You're telling me that I can run this thing and never have to touch the 
Oracle Inside?
> There is a need to provision, patch, manage and report on the servers
> in your infrastructure. There is a cost (time, salary, etc) to make
> that happen. RHT offers an appliance that assist with that and saves
> you money. If it is a turnkey solution that requires little/no
> maintenance, the how shouldn't matter. If it does, then roll your own
> because you won't be happy with a black box.

Yes, and that is MY salary you are talking about. Provisioning via 
Kickstart is pretty easy. My strategy is "Just Patch Everything ASAP", 
and my strategy on Reporting is "Assume that everything is Up To Date". 
Many people Never Patch Anything, and simply assume that The Original 
Code Works. Most everything is Behind Firewalls anyway.

I'd rather be the one rolling my own scripts where necessary.

Sure, the "turnkey solution requires little or no maintenance", but 
managing your systems is still a job, even if it's an easier one.

> So if an appliance doesn't work for you, don't use it.
I'm not knocking the Total Solution...I am knocking the Partial 
Solution...the Database inside.

And even if Oracle *was* the Only choice at the time...Hooks should have 
been added for Future Options.

Tight Coupling Is Bad.

JIM



More information about the Novalug mailing list