Can Red Hat Do For OpenStack What It Did For Linux?

Brandon Butler writes "Red Hat made its first $1 billion commercializing Linux. Now, it hopes to make even more doing the same for OpenStack. Red Hat executives say OpenStack – the open source cloud computing platform – is just like Linux. The code just needs to be massaged into a commercially-hardened package before enterprises will really use it. But just because Red Hat successfully commercialized Linux does not guarantee its OpenStack effort will go as well. Proponents say businesses will trust Red Hat as an OpenStack distribution company because of its work in the Linux world. But others say building a private cloud takes a lot more than just throwing some code on top of a RHEL OS."

Comments

RedHat be unsmart?

[mwvdlee]

But others say building a private cloud takes a lot more than just throwing some code on top of a RHEL OS

And somehow those "others" also believe Red Hat to be incapable of doing any more than just throwing some code on top of RHEL?

Re:RedHat be unsmart?

[AvitarX]

Red Hat better hope that throwing on the code isn't all it takes. Being an Enterprise Linux company takes more than throwing code on top of the kernel, and that's why Red Hat made a billion dollars, and Slackware didn't (not trying to knock Slackware, just trying to contrast two fairly early distros I used 15 or so years ago).

If all it takes is the code, Red Hat is screwed.

Re:RedHat be unsmart?

[Lumpy]

Remember those two are different targets.

Redhat is an enterprise Distro. Slackware is a hobbiest Distro Tow very different things. IT's like comparing Boeing to Cessna. They both make airplanes... but they both target completely different markets.

Re:RedHat be unsmart?

[eric_herm]

Well, that's the point, ie you need more than hobbyist. IE, when it come to be "enterprise" ready, people expect documentation, training, certification, support, and this is not free ( because while some people enjoy writing documentation or making support, there isn't that much people doing it for free ). And also, when you start to pay, you tend to expect someone to handle the sales, someone to negociate, etc, etc.

Re:RedHat be unsmart?

[Arker]

"Redhat is an enterprise Distro. Slackware is a hobbiest Distro Tow very different things."

True that they are two different things, sure. Though they are actually extraordinarily similar (to the point I usually get modded down when I say that they should be treated as two different, though closely related, Operating Systems, rather than being carelessly referred to as 'Linux'.)

"IT's like comparing Boeing to Cessna. They both make airplanes... but they both target completely different markets."

A very misleading analogy. It's more like if Boeing and Cessna were both building a plane based on the same chassis and engine. Slackware just produces one that lifts off a thousand pounds lighter, has engines that produce more thrust, and a stark, functional control layout, and gives it away for free expecting whoever uses it to have pilots, airplane mechanics, etc. on staff and to do their own due diligence and accept their own liability, while Redhat produces a much heavier version on the same airframe that they essentially rent to you, under a support contract where their mechanics keep it flying and they accept (some of the) liability.

That analogy isnt great either actually but it's a lot better than one that implies that RHE is somehow going to 'lift more weight' than Slackware. Given the same hardware the opposite would be true.

The headline is a question and the answer is Yes

[Attila Dimedici]

I think this is a headline that breaks the law of headlines which says the answer to a headline that is a question is always no. Red Hat certainly CAN do for OpenStack what they did for Linux. That does not mean that they will do so, even if they put the necessary effort into it. The last statement of the summary is irrelevant because Red Hat certainly knows that and almost certainly understands the magnitude of the project they are undertaking here. Red Hat is the sort of company that can do this. However, the project is complicated enough that they may fail.

Cloud computing platform

[ArcadeMan]

After all these years I still don't know what that is supposed to mean. I know about servers, FTP, server-side languages, etc. But "cloud computing platform" just sounds like a buzzword clusterfuck from the marketing department.

If I look on wikipedia then even a simple website with a CMS is "cloud computing".

Re:Cloud computing platform

[ADRA]

Self managed OS based hosting entirely from the internet (no physical access). That's it bud. Anything else is just window dressing.

Re:Cloud computing platform

[asmkm22]

Cloud computing is less of a definition about what it is, and more about how it's used. The general idea of cloud computing is to offload storage and applications from your local setup (workstation, network, etc) onto something "in the cloud" which basically means the internet.

The industry does a really poor job explaining that not all cloud experiences are the same, however. I've seen some cloud providers basically just offering seats to a Windows RDP server, which may not sound all that special to you or I, but they've managed to carve a business out of it.

Re:Cloud computing platform

[pLnCrZy]

What you're describing is virtualization.

"Cloud" is a stupid buzzword that quite simply means "resides on someone else's stuff."

Whether it's Amazon's stuff, Rackspace's stuff, or Microsoft's stuff -- it's not your stuff. You don't worry about physical servers, disks, or OS (in many cases.) Take it a level higher and if your cloud service includes databases or middleware, you don't worry about that either. Or even applications. Amazon's Elastic Beanstalk basically lets you publish your website code directly to it and the rest is magic that you don't have to mess with.

Then we turn it all around and create "private clouds" which means "we want to be trendy but don't trust someone else's stuff."

The pundits and pedants will mix in all kinds of semi-fabricated points about things that "must" be true in order for something to qualify as a "cloud," private or not, such as auto-provisioning and/or automated management, etc.

We used to call it "hosted services." Some marketing knob decided that the industry needed a more bandwagonny word for people to latch onto. Thus the term "cloud" was born, and it continues to be confused, misunderstood, and abused in perpetuity -- a condition that illustrates what a huge failure the very forces that coined this nonsense have done in making it clear to the consuming public what it actually is supposed to be about.

Probably won't....

[Junta]

RHEL has been angling at shooting down vmware in the enterprise space. They have made a go of it with RHEV-M and thusfar have failed to get traction. This is despite RHEV-M having a lot of the most common capabilities available that vmware offers. It's a tad different and in some ways exposing users to quirks that don't make a lot of sense (vmware has its own quirks, but being first has advantages). Openstack in general is aimed in a pretty divergent direction than where vSphere went and isn't particularly well off in heading even in that direction. If RH couldn't dislodge vSphere with a solution that matches capabilities, I can't imagine how they come back with a less resilient architecture and suddenly be view favorably...

NIST definition - Cloud computing

[dwheeler]

You might look at "The NIST Definition of Cloud Computing": http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf - it's one-and-a-half pages once you skip the boilerplate.

Re:NIST definition - Cloud computing

[ArcadeMan]

The fact that "cloud computing" needs 1.5 pages for definition alone is proof that the concept was created by the Marketing Department of the Sirius Cybernetics Corporation.

Re:NIST definition - Cloud computing

[Burning1]

It doesn't really need 1.5 pages of description.

Cloud computing is a strong abstraction layer between the physical machine and the logical machine. It's very similar in concept to memory virtualization - each process is given it's own address space, and really doesn't understand or care how that address space maps to physical memory. In a cloud computing environment, you request a new machine, and the cloud computing infrastructure automatically allocates a machine based on your requirements. The abstraction layer allows your physical hardware to be treated as a pool of resources, that can be expanded, repaired, or replaced without much concern about the impact to the logical machines it supports.

Cloud computing doesn't necessarily require virtualization either; physical computers can be provisioned using cloud infrastructure; https://wiki.openstack.org/wiki/Baremetal

Re:Show what an inferior OpenStack might look like

[Archangel Michael]

What? You data isn't backed up ... three times?

And you patched a production server, without testing?

You're screwed because you didn't do your job. For the crap that happens with RedHat, if you're paying for that support, pointing fingers at RedHat for their part of the blunder is why you pay for that service. Everything else, is your problem.

If you did that while working for me, I'd fire you. Quit trying to impart your mom and pop Linux views on Enterprise environments.

Do what they did for Linux?

[Anonymous Coward]

You mean ruin it?

I kid, I kid...

Re:Show what an inferior OpenStack might look like

[bluefoxlucid]

Ubuntu inherits Debian policy. Anything--supported or not--is not updated in any way that breaks things. You might not be able to get security patches for stuff in Universe or Multiverse in a timely manner without rolling and submitting it yourself; but they won't go releasing a package that no longer does X when X worked before. The idea is that, if your configuration works, it will continue to work *exactly* the way you have it without modification no matter which version of the package you have across the entire lifecycle of a stable release--if it doesn't, that's a bug and they need to undo that breakage. Extending is fine, breaking is *not* acceptable.

RedHat on the other hand released RHEL 6.4 and removed crmsh, the configuration system for Pacemaker, to be replaced with PCS. This wasn't documented in the release notes, either. Suddenly things that configure high-availability fail-over on RHEL 6 don't work. Running the same tools/scripts/whatnot breaks. This is still RHEL 6 stable, and under Debian policy that's not supposed to happen. RedHat doesn't have such a policy, so it happens.

That means you're persistently at risk of reaching a situation where your patching priority demands increased resources: I can continue to patch Ubuntu while my dev team comfortably works on readying our stuff for the next LTS or the next 9 month release, usually; but one day RHEL has patches and I either don't upgrade as my company's security policy dictates OR we find resources (meaning, sometimes, hire more people) to step up the porting process.

With RHEL, the risk is that we may need more manpower (labor cost--salaries) to support the same security policy; and that we may still not be able to keep in step as quickly as with a Debian-style update policy (i.e. there may be greater lag time as we rewrite scripts and configurations and do more dev testing before releasing patches). On top of that, we're faced with the risk of more frequent large roll-outs--things that worked in dev might not work in production, and now we're rolling out a patch that breaks production along with a bunch of patches to production to un-break it, and hoping that it all works in production.

Yes, I blame RHEL for this.

They will face some steep competition

[brunes69]

IBM is investing big into OpenStack. They talk about it all over the place.

Rackspace is also investing big into OpenStack.

Both of these players dwarf RedHat.

Re:They will face some steep competition

[thule]

I thought Rackspace works closely with RedHat. So Rackspace probably gets a pretty good deal if they run RHEL.

Re:Show what an inferior OpenStack might look like

[Archangel Michael]

So, basically you patch production machines without testing. Gotcha.

Hell, I don't even do this(patch w/o testing) with Ubuntu OR Windows systems. Patching breaks things. Eventually.

Re:Show what an inferior OpenStack might look like

[bluefoxlucid]

Not everybody has a dev environment for everything.

Not everything works because it's been tested. Every time we release something out of software in-house dev, it goes through a month of dev testing. Then... it breaks 15 minutes after it's released, and takes 3 hours to un-break.

Re:Show what an inferior OpenStack might look like

[Anonymous Coward]

Not everybody has a dev environment for everything.

Why the hell not? It's 2013 and virtualization is cheap.

Not everything works because it's been tested. Every time we release something out of software in-house dev, it goes through a month of dev testing. Then... it breaks 15 minutes after it's released, and takes 3 hours to un-break.

It sounds like your team is pretty bad at testing, then. Do you have dev or staging servers? Do they mirror the production setup? Is software versioning equivalent between the two (I'm talking distribution + supporting packages, clearly, not the software you're releasing)? Have you load tested to make sure your new shit isn't introducing something that will crush all resources in its path as soon as X people hit it? Do you have proper tests set up?

"Every time" is terrible, and I don't know your organization, but I'm pretty sure you should feel terrible, if only for having to work in such an environment.

Re:So what's up with ovirt?

[cblack]

Yeah well, before that they were the major player behind what, Xen?

Xen: yes, they were behind Xen for a while years ago. The community and experts moved on to KVM, so did RedHat.

And had the only decent management tools for it?

I don't see how this is a question. Maybe they did, idunno. Hardly matters now that relatively few people still use Xen.

They change their mind about this every week. I'll believe it when I see it.

No they don't. And you won't believe it when you see it because you won't recognize it.
Because you're dumb.

Re:The headline is a question and the answer is Ye

[atom1c]

I concur.

I took OpenStack for a spin last week and I like where they're going. It brings the CLI access from the AWS world with the mature web-based deployment tools of Azure -- and allows for GCE-type sophisticated apps to run within their contexts. This unique combination has made it appealing for me -- and surely whets the appetites for tons of onlookers who are waiting for the chips to fall before making any company-wide commitments.

Ostensibly, they'll have to endure 2-3 major outages in the next few years before seeing the commitments its customer base truly has with them. Hopefully they don't endure any major outages... although they do run atop the AWS IaaS platform...

Re:Show what an inferior OpenStack might look like

[eric_herm]

I am sure that your company policy should include "do not use Technology preview on production servers". If it doesn't, then I suggest to add it, and then complain that using RHEL do not have the packages you need, if you want to switch to Debian. That would be much more smoother. than trying to blame the vendor for your lack of clue regarding what is supported and what is not ( especially when comparing to Ubuntu, where you do not even have the guarantee that Mark will not change his mind and just stop the project, or focus it on something else, like they did on the desktop, on bzr, and several stuff )

Re:Will it be as broken as Fedora?

[eric_herm]

You can try openstack on Fedora, or look at RDO ( http://openstack.redhat.com/Main_Page ).

And Fedora is as broken as the community make it broken. If there is no one to make bug reports, triage them, make QA, then yeah, this slip. There is lots of way to help on this part, from giving karma to update testing and testing prerelease.

"technology preview" not for production use

[Chirs]

What part of "...these features are not fully supported under Red Hat Enterprise Linux Subscription Level Agreements, may not be functionally complete, and are not intended for production use." didn't make sense?

Why were you using a technology preview feature in production when they explicitly say not to?

Re:Obama, PRISM, NSA killed the cloud

[aztracker1]

In this case we're talking about products and infrastructure for building in-house clouds... in a lot of ways cloud-style infrastructure management on internal servers makes sense, as you can allocate resources generically, as needed so long as your IT systems departments keep a margin of available infrastructure so that departments can spin up/down projects as needed.

Re:Break things that used to work? Sure

[Anonymous Coward]

This post is so full of misinformation it's ridiculous.

RH dismissed OpenStack in a recent conference call? That seems kind of odd seeing that they are contributing heavily to it now, and Red Hat Summit was just last week where they, you know, didn't dismiss it.

Re:Show what an inferior OpenStack might look like

[TENTH SHOW JAM]

You don't have a dev environment... Go grab 2 workstations and a switch and MAKE ONE NOW!

It also sounds like your testing regime needs working on. Devs do not say the code is ready. Users do. They get to break it 15 minutes into the test. They don't have to follow the Official Tests. This is called User Acceptance Testing. Devs will whinge about this because their mistakes are hi-lighted and "It worked for them" I speak from experience. I hate when users fail my code. But it's my fault, and I need to make my code better.

Re:Break things that used to work? Sure

[Anonymous Coward]

He didn't say anything of substance. Anyone who uses Fedora (hasn't been core since ... 7 or 8) and expects it to never break is a moron. IT'S A DEVELOPMEN DISTRO. That's as stupid as me using Gentoo and being mad that I have to wait for shit to compile. Use the right distro moron.

Second, it reeks of "They changed my stuff, I'm mad. You young people will never implement something better than good old Unix how I used it" Guess what, SYSVInit is shit. It needs to be replaced. If you don't want to, keep using it. Redhat wants to implement a decent replacement (which won't be perfect on first release obviously,) so they gradually implement it in their testbed distro to eventually use it as the base in their stable distro. And guess what, systemd is awesome. Is it the same shit we've gotten used to? no. Will we need to learn new stuff? yes. Is it for the better? yes.

Anyone who doens't want to deal with change shouldn't work in IT. The field will never stop changing. I like stability just as much as the next guy, which is why I use RHEL on my servers, not Fedora. So yes,
TLDR; blah blah blah, get off my lawn.

Re:Show what an inferior OpenStack might look like

[AdamWill]

"RedHat on the other hand released RHEL 6.4 and removed crmsh, the configuration system for Pacemaker, to be replaced with PCS. This wasn't documented in the release notes, either. Suddenly things that configure high-availability fail-over on RHEL 6 don't work. Running the same tools/scripts/whatnot breaks. This is still RHEL 6 stable, and under Debian policy that's not supposed to happen. RedHat doesn't have such a policy, so it happens."

Well, that's not entirely accurate. Pacemaker is a Technology Preview in RHEL 6. This is a term with a very precise meaning (documented in your support contract and whatknot): https://access.redhat.com/site/solutions/21101 .

"Technology Preview features are currently unsupported, may not be functionally complete, and are not suitable for deployment in production. However, these features are provided to the customer as a courtesy and the primary goal is for the feature to gain wider exposure with the goal of full support in the future."

Given those attributes, it's not generally considered a big deal to change TPs in non-compatible ways in point releases. A change to an actual supported RHEL feature would be a much bigger deal.