Slashdot Mirror
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."
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?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Breaks one day because snapshots are a "Technology preview" and destroys all your disk images when RedHat releases a new update to RHEL7 production stable feed.
Support my political activism on Patreon.
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.
The truth is that all men having power ought to be mistrusted. James Madison
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".
Get free satoshi (Bitcoin) and Dogecoins
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...
XML is like violence. If it doesn't solve the problem, use more.
I hope Openstack will become less hype and more usable now that RedHat is on it.
Then we will all be sad.
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.
- David A. Wheeler (see my Secure Programming HOWTO)
If it wasn't for SuSe, Slackware, Mandrake and a few others Red Hat would have gone under. Commercialization of Linux was a team effort, despite the shameless historical revisionism of the article lead.
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.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
You mean ruin it?
I kid, I kid...
Can Red Hat do for Open Stack what it did for Linux?
If by that, do you mean can Red Hat break things that have worked perfectly for years (clustering in FC13-16 vs 17+, and the godawful mess that is systemd replacing perfectly servicable and reliable UNIX mainstays such as sysv init, etc.), then the answer is most definitely:
YES
On a recent conference call with Red Hat, they dismissed Open Stack and touted their own proprietary products for "cloudy" type infrastructure. Bringing fuel into the fold won't be any different...they'll downplay open source fuel and tout their own version, with layers of proprietary, opaque add-ons of questionable value. The RH version will lag a version or two behind the upstream free version, and probably suffer some breakage due to RH addons. Same song as before, different day.
The Future of Human Evolution: Autonomy
Let's face it, OpenStack isn't the easiest thing to work with. Like the early Linux days, things were changing by the day/release. Red Hat (and other distros too) were able to tame it a bit and make it stable enough for people who needed it to work. They've already got an 'in' with lots of fortune 500 companies, and they're likely at a state where they have a lot of hardware but are starting to look at cloud computing. Giving those companies an easy way to turn their hardware into a private cloud for less (or easier) than VMWare becomes a real opportunity for them.
I've been tinkering with the Red Hat RDO on CentOS. While installation is a lot easier than when I tried devstack a few months ago, there's still a lot of work to be done, but it's getting there.
Red Hat plans to integrate OpenStack with oVirt Node (oVirt Node becoming a target for OpenStack deployments besides just oVirt clusters).
Red Hat is putting Swift to bed and attempting to replace it with UFO (Swift APIs atop Gluster).
The end result might look like Red Hat gutting OpenStack and replacing components with its more mature Emerging Technologies Lab products.
The cloud is dead. Dump your stock, and move your stuff back inhouse before your vendor goes broke, and stuff just stops working in the middle of the night and YOUR phone starts to ring because it is YOUR problem.
This is only one of the massive repercussions.
"A phantom limb is the sensation that an amputated or missing limb (even an organ, like the appendix) is still attached to the body and is moving appropriately"
The undenied Snowden leak makes the massive spying official. It is no longer a myth, a conspiracy theory. It is public record. It must be dealt with.
So can the 'oh they have been doing it for years' crap. And the if 'everybody else is doing it' as an excuse for committing crimes against humanity.
Don't dress the cloud up in 'open source' and 'linux' and try to steal the good will and Karma of Linux either.
THE CLOUD IS DEAD.
Fives Stages of Grief
1. Denial
2. Anger
3. Bargaining
4. Depression
5. Acceptance.
But the industry is still in the DENIAL stage, has a long ways to go yet. I know. I understand. It's hard. Especially when they did it too themselves.
Microsoft, Apple, Yahoo and the rest destroyed trust, violated privacy, but they still expect to sell a Cloud? Clouds are based on massive trust and privacy!
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.
Support my political activism on Patreon.
As was written in the article – openstack is the perfect opportunity for Red Hat. Red Hat can't sell products on a brand name (it's still smaller than Oracle, SAP or Microsoft). Its sweet spot is to get a tech adopted on its own merits, and then emerge as the best supplier. I'm quite certain it would sell more JBoss software if there existed a credible second JBoss source on the market (like suse exists in the linux enterprise space). As it stands a lot of fortune 500 companies will give part of their market to Oracle or IBM even if they like JBoss, because JBoss is Red Hat-only and they want an exit strategy.
Now, kvm was the same kind of opportunity and it let journalists and its own marketing portray it as a Red Hat technology. So instead of a no-brainer open solution, kvm became just another proprietary software trap in the mind of lots of CIOs (and VMWare is a lot better than Red Hat at selling proprietary stuff). The RHEV branding was IMHO a huge mistake. Red Hat should have emphasized kvm, not its own name.
To succeed, Red Hat needs to invest enough in Openstack to be the most likely to win Openstack tenders, but not so much as to crowd out other credible Openstack suppliers. It's an incredibly difficult dance. It's totally contrary to the training of all its salespeople (they will try to capture all of it because of bonuses, and frighten customers). And I expect we'll see many 'Openstack, this Red Hat-only solution' from vmware/microsoft-sponsored journalists, if it starts to work.
Red Hat needs a Suse for openstack quickly. It can not play nicer/better openstack supplier otherwise.
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.
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.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
Support my political activism on Patreon.
I thought RedHat was throwing its weight behind oVirt. OpenStack from the beginning has been very cobbled together and even still is a major pain to set up from scratch. Although oVirt hasn't been around as long, it definitely has a more mature interface as far as I'm concerned. It was my understanding that RedHat was the major player behind oVirt and was looking to make it their cloud platform of choice.
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.
Red Hat's quality has gone down the tubes in recent releases of Fedora. I don't mean the experimental side (wow, someone thought Gnome 3 was a good idea), I mean breaking stuff that's always worked and creating a gigantic awful mess like having to download packages to upgrade Fedora when you have an install DVD. The goal of Fedora seems to be to create the most brokenness possible. So if they apply this to OpenStack, they're going to be in a world of hurt. Red Hat ought to sit down and have a quality control meeting before they do anything else. (I say this as a long, long time user of Fedora/Red Hat Linux going back to version Red Hat Linux 5 or whatever. I'm a loyal Red Hat person, at least until recently.)
Developers need a "Fedora" version of OpenStack to test with before deploying to the real cloud. How do I get a test instance running on my Linux box?
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...
I did some testing with it. Its good, but its clearly work in progress, and a technical marvel. But its also lacking the tools and toolset for deployment, and management. The only cloud winners will in the end be the ones that have great toolsets and management. If something in the end remains a huge mass of spagetti that only finite skilled souls can pull together and run, then it will be eaten alive.
I have not tested JuJu, but that seems to be like the kind of deployable real world end user tooling that this is going to require.
We`re all equal
...t 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.
Can't their Openstack product just use Red Hat's existing build, test, and QA processes? Development still happens in the community, they just have to track/patch bugs and offer support, populate some new channels in RHN with software, figure out how to charge for their build. Perhaps they'll hire some Openstack project leaders - heck, maybe they already work at Red Hat.
In the end, I think the biggest winner may be RHEV. If greater focus on Openstack development and support means that some of the Openstack components (like networking, one of the areas where RHEV desperately needs more flexibility/functionality) end up in RHEV, it'll truly be a competitor to VMWare.
https://access.redhat.com/support/offerings/techpreview/
What part of "no garantee" is hard to understand ?Seriously, if you cannot spare a system to test, that's not a reason to test it on production when the vendor explictely say "do not do it".
Why do the /. editors/storywriters/shills/voices of the people/etc. keep making this comparison? What marketer somewhere decided "Let's call it the new Linux!" ?
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 )
I don't see any reason to expect Red Hat to fail, but I can think of several ways that they could fail (one of them being reinventing the wheel when it comes to build, test and QA processes rather than using the processes they already have).
The truth is that all men having power ought to be mistrusted. James Madison
Technically, JBoss has compatible competitors with Websphere and others.
And there is plenty of competitor on openstack, be it Suse openstack offering, or stuff like cloudstack.
Ubuntu has many schoolboy errors. They broke X completely in an LTS and don't fix any bugs whatsoever regardless of anything.
Debian fixes bugs if they are severe enough. Redhat fixes them (And does other stuff like backporting hardware support etc). As long as you follow the best practices docs from Redhat for whatever release then you won't have problems. If you don't want to do that don't use Redhat (Or Software that is only certified on it).
Ubuntu ships a lot of packages, but very few are actually supported.
The company I'm with uses both redhat and centos (as well as other paid and free linux vendors).
Sometimes you want the paid-for support of a RedHat license. Other times it's an unnecessary expense.
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?
I think his point is that with Debian, you do not need to hire additional staff just to work around breakage caused by your linux distribution.
It is insane to run a business where your "vendor", by policy, is actively breaking things on you.
We have _many_ Debian boxes and a few RH boxes (where a commercial vendor would only support their product running on RH). It is true where I work too that the RH boxes require disproportionate resources to maintain. It is pretty sad. But, if you do not have any qualified staff, then perhaps a support contract is worth the extra pain of using RH?
That would be terrible.
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.
A sig is placed here
To display how futile
English Haiku is
"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.
As a dev, I LOVE it when users break my code during UAT. Absolutely LOVE it. That's because I'd prefer to get my ass chewed over when the code is in UAT and we can (relatively) leisurely get it fixed.
The alternative, of course, is having to fix it in production, with 87 layers of management and critsit nazis breathing down our necks asking for a status update every seven point two seconds.
That's NOT so nice :-)
Not everybody has a dev environment for everything.
True. But the context is professional. You know - how business should be run.
Ubuntu has many schoolboy errors.
Please try and remember that Debian is what Ubuntu was before the retards fucked with it. The sort of retards who can't work with Slackware or RedHat, who don't run backups or test before deploying updates. Change control - it separates the wannabes from the professionals.
Sure JBoss has competitors. But they aren't JBoss the way Suse is still Linux.
That means anyone selecting JBoss has already selected Red Hat, and needs to think about what will happen if relationship with Red Hat sours at once, while Linux can be selected way before any supplier is chosen (and Red Hat/Suse/Debian junkies can all hope their pet variant will be chosen at this stage).
Don't underestimate the amount of obstruction people with "anyone but foo supplier" attitude can mount (when foo is not dominant enough you can't escape it anyway).
What part of "we don't support this -at- -all-, but there will be no updates in current production stable release that break it" is hard to understand?
RedHat's tech preview include any sort of fail-over mechanism. That means you have to chose between the risk of running without high-availability and the risk of RedHat breaking your shit. When you do dev testing, and you find it breaks, you now have to deal with the risk of protracting your update cycle longer than would have been necessary if they had taken the liberty to ensure that updates will specifically not break what once worked. That means you're forced to take on greater risk no matter what you do.
RedHat Enterprise Linux is a giant beta testing field.
Support my political activism on Patreon.
Our company policy is non-existent and SOP is insane. We'll leave it at that. I've suggested jumping off RHEL repeatedly because it's such a shit heap, but I get arguments about how "the industry knows RedHat is a good product" when it's really not.
The fact is this "technology preview" is a critical feature for a huge business case--fail-over servers. You have to supply 99.999% SLA, so you have 3 servers, and when one fails it transfers its IP address to another one and there's barely a flicker. Yes, they broke that; and when they wrote the release documents, they didn't mention that they removed an entire configuration system.
On Ubuntu you have the guarantee that they won't fucking break release. They won't break release. They. Won't. Break. Release. Oh, shit, bzr isn't a thing anymore? Well, the current releases of Ubuntu that have bzr won't lose that until they've gone out of support cycle! LTS is supported 5 years? Everything in LTS is going to be there, working as-is, for 5 years! Guaranteed 100% absolutely! It won't be there in next release, so start migrating your shit off now; but it won't vanish overnight!
Support my political activism on Patreon.
The pacemaker packages have been upgraded to upstream version 1.1.8, which provides a number of bug fixes and enhancements over the previous version. (BZ#768522)
To minimize the difference between the supported cluster stack, Pacemaker should be used in combination with the CMAN manager. Previous versions of Pacemaker allowed to use the Pacemaker plug-in for the Corosync engine. The plug-in is not supported in this environment and will be removed very soon.
They at least warn that Corosync won't start Pacemaker in a future release--that's normal; we have the pacemaker init.d script running it, not the Corosync plug-in. Removing it during release would be a mistake, though.
They don't mention that they've removed crmsh and added PCS. They do give this warning:
With this update, Pacemaker provides a simpler XML output, which allows the users easier parsing and querying of the status of cluster resources.
Status, but not configuration. Nothing about configuration input, which was previosuly handled by crmsh but now is handled by pcs. pcs isn't even installed by default; you have to figure out that you need it, then install it. crmsh is removed by default when you upgrade.
How wonderful that they've been so clear.
Support my political activism on Patreon.
How about [...]
Are you still here, whining about how they removed features for a Technology Preview (which you inexplicably deployed into a production environment) between point releases? Some people just won't let go and admit their own mistakes. Good luck with that.
Redhat is too slow at providing "officially supported" packages of the software versions that have been around for a while. Take Apache as an example where they latest version they have is over 2 years old and doesn't address vulnerabilities such as CRIME (The 2.2.x branch has this at Apache but Redhat doesn't).
Ubuntu seems to be the distro of choice for OpenStack. Third party management tools such as Puppet are the latest way to manage it in an enterprise.
Yes. Much better in test than in prod. I have to agree with you there.
A sig is placed here
To display how futile
English Haiku is
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.
I call bullshit. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561578#61
Its pretty sad when a commercial OS ships a debugger with their system but no compiler.
-- System Information:
Debian Release: squeeze/sid
SID is the unstable Debian--the development branch where anything can change, anything can break, and eventually it gets snapshot and marked "RELEASE". This isn't really a release anymore than Fedora Rawhide.
Nice job trying to counter-example my argument about how stable production releases work by showing that shit breaks in unstable alpha development cycle. You'll convince a few dumb people who don't know anything about Debian or can't decipher what's in the e-mail at all that way.
Support my political activism on Patreon.