Slashdot Mirror
OpenStack To Crack Down On Incompatible Clouds
itwbennett writes "OpenStack is calling shenanigans on companies that call their services OpenStack but aren't truly interoperable. (HP, Rackspace, we're looking at you.) Josh McKenty, CTO of Piston and an OpenStack Foundation board member said that the board has 're-fired up' the interoperability working group, and though he admits it will take some time before the hammer falls, he called out HP and Rackspace as two offenders: 'Neither of their public clouds could be called OpenStack under current interoperability guidelines,' he said. For their part, HP has denied the claims, while Rackspace said in a blog post that it is on track for interoperability by the end of the year."
moving to GCE :)
Guy said both aren't interoperable. HP says they are, supporting the core api and with no proprietary api extensions. Rackspace says they're not there yet, but they'll be there soon. Both say that every OpenStack implementation, regardless of where you go, will have its own bells and whistles.
Which makes sense... everyone wants to differentiate.
As someone who worked at Rackspace when we first announced that we were creating OpenStack, I have to at least chuckle at the idea. OpenStack likely would not be where it is now if Rackspace had been focused on complete interoperability too early. Rackspace implemented what they had, showed off the features that worked, and helped drive other companies to jump on the OpenStack bandwagon. They certainly deserve some time to get themselves in line.
I'm not sure what HP's excuse is, though.
"calling shenanigans".
Dear oh dear. A wasted education.
"turn of phrase" is equally dated and obscure.
A fool throws a stone into a well and a thousand sages can not remove it.
This is a tough situation for OpenStack - the project is still young, so it wants to be liberal in terms of who it lets in and be careful not to alienate big companies that are investing a lot of money it in. At the same time, OpenStack enthusiasts want to make sure the project doesn't fork into a million directions and doesn't allow for the promise of what they beleive OpenStack can be - a federated hybrid cloud ecosystem, which requires interoperability.
"turn of phrase" is equally dated and obscure.
Hardly. I hear it, and use it, often.
"Calling shenanigans" was coined by a person/persons unfamiliar with the correct usage of shenanigans. That this phrase continues to occur shows that they still don't know how to employ the word and misunderstand it.
I have a concern that is based on deficiencies in Amazon Web Services. The AWS model lacks certain abilities that I am looking for in another cloud provider. But I am concerned that the operational model behind the scenes might affect the API compatibility. It certainly would affect what actually happens when certain operational requests are made as different operational models would end up behaving differently. I have contacted half a dozen providers, but I cannot get any straight answers from them.
In AWS, there are two "places" to run instances in a given zone. One is called EC2-classic. The other is called EC2-VPC. The problem with these is that the features I need are split up between them. In EC2-classic, an instance gets a random IP address that can reach the internet. In EC2-VPC it does not, and only gets an IP address in the VPC subnet. For an EC2-VPC to get an IP address to the internet, it has to get an "elastic IP" and associate that. But that has a limit and cannot scale with instances. You can have 20 instances in AWS without getting an extension, but only 5 elastic IPs.
I want instances that each have their own IP address to the internet (optionally ... users should be able to choose NOT to have one, and maybe not having one should be the default) ... and specifically NOT bottlenecked through a gateway instance ... but also have their own IP address in a VPC style local address space that is assignable like VPC is.
I don't know if Open Stack can do this or not. What would be disturbing is, if it cannot do it, but a vendor wanted to have an operational model like the type of instance I want, would that break compatibility? Is the compatibility issue strictly an API "talking mode" issue, or does it extend to the operational models of the infrastructure, too? Does the compatibility issue block vendors from innovating?
now we need to go OSS in diesel cars
HP can call theirs the OpenHighPile. RackSpace can call theirs OpenRackStack, etc.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
It strikes me that the primary value to cloud operators of non-interoperable clouds is vendor lock-in -- once you're on their cloud, migrating to another is more work, downtime, etc. It forces you stay put unless you REALLY want to change.
However, a truly interoperable cloud environment sounds like a race to the bottom for vendors -- who can be the cheapest?
It's not hard to see people running management software that figures out what the cheapest vendor is on some regular basis and doing migrations to other vendors as soon as there's enough price break to make it worth what downtime there might be or to build a presence in many compatible clouds, keep your data synced and just move your workloads to whoever's cheapest.
It's not hard to see this kind of thing happening in near real-time for people with the management tools and architecture.
Wiki: In July 2010, Rackspace Hosting and NASA jointly launched a new open source cloud initiative known as OpenStack.
RackSpace is a co-founder of OpenStack and the "version" of OpenStack that RackSpace uses is free to download and use. RackSpace said they are currently working on it. They should get a bit of slack when getting Interop up to par.
Is what it should be called. The base version seems to be evolving at an extremely rapid pace. Fast enough that the configuration docs, and modules in the system are being changed fast enough that someone who just wants to install a private cloud for testing or whatever totally gets screwed because its like learning a new system every 6 months.
Call me when the public API's have been fairly stable for a year, and they haven't replaced/rewritten any of the modules in 6 months. Otherwise its a waste of time, as you spend 1/2 the time just keeping up with the openstack developers rather than solving any problems.