OpenStack To Crack Down On Incompatible Clouds 30
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."
Re: (Score:1)
Save you the reading... (Score:3, Informative)
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.
Re:Save you the reading... (Score:5, Interesting)
Well, I assume that OpenStack is a trademark owned by the OpenStack Foundation. Therefore the OpenStack Foundation has the right to grant or deny others to use that trademark.
I guess they have clear guidelines for the conditions on when you may use the trademark (if not, it's about time). Those conditions certainly should include an exact specification of the APIs which have to be supported.
Ideally they'd release a test suite, and anything that passes the test suite may be called OpenStack, while anything that fails may not. That would be a simple, objective criterion.
Re:Save you the reading... (Score:5, Informative)
Ideally they'd release a test suite, and anything that passes the test suite may be called OpenStack, while anything that fails may not. That would be a simple, objective criterion.
It looks like Rackspace made, and open sourced, the test suite.
Re: (Score:2)
> It looks like Rackspace made, and open sourced, the test suite.
So, vendors can extend the open source test suite to alter the parameters of compliance :)
Re: (Score:2)
Ideally they'd release a test suite, and anything that passes the test suite may be called OpenStack, while anything that fails may not. That would be a simple, objective criterion.
If they did truly value their reputation among developers, they'd just release a standard test suite that everybody would fail initially.
Using a test-driven approach would make sense in this case.
Re: (Score:2)
Ideally they'd release a test suite, and anything that passes the test suite may be called OpenStack, while anything that fails may not. That would be a simple, objective criterion.
You are talking about tempest [github.com] here! :)
OpenStack cracking down on Rackspace? (Score:5, Informative)
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.
Re:OpenStack cracking down on Rackspace? (Score:5, Informative)
HP doesn't need an excuse [itworld.com] because they're already compliant with the current definition of "interoperable".
The original story was misleading: OpenStack want to extend the definition to things that would mean HP would not be in compliance, but HP have already said they'd be happy to come into compliance once that definition has been set. Don't forget HP have people on staff who are heavily involved in OpenStack for precisely these kinds of reasons.
Re: (Score:3)
The original story was misleading: OpenStack want to extend the definition to things that would mean HP would not be in compliance, but HP have already said they'd be happy to come into compliance once that definition has been set.
So, samzenpus lies to its readers, is a credulous shill (or can be bribed? has sticks in this fire? just hates HP on principle?) for any sensationalist who comes around, and itwbennett spreads disinformation (or can be bribed? has sticks in this fire? just hates HP on principle?) presumably to discredit competitors. Astroturfing on /.; thanks a lot.
Good job, both of you. :-P I now know how much weight to give your stories in the future.
Re: (Score:1)
HP is the 6th biggest contributor to the OpenStack codebase. We always try to work in harmony with them because it's in our interest. Many customers want a cloud provider that offers a no-lock-in open source alternative to Amazon or Azure.
OpenStack was made for the private cloud. HP, RAX, Microsoft and others are among the few big public cloud providers. A public cloud presents problems that just aren't in a private implementation. We're running the OpenStack as a live, public business.
Example: how do
Re: (Score:1)
"turn of phrase" is equally dated and obscure.
sticky situation (Score:2)
Does the API affect operational model? (Score:2)
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
Re: (Score:2)
https://wiki.debian.org/OpenStackHowto/Quantum [debian.org]
So, basically, you first add a virtual router with a NIC on a public IP address, and the other NIC on your virtual LAN. Then if you need a public IP address for a VM, you just add a "floating IP address", which basically means that you will have NAT port redirections going to that IP in the LAN.
All this is completely standard in Open
Re: (Score:2)
I'm not sure what you describes matches what I ask for, yet. Let's see. What happens if you leave out the virtual router with a public IP. Now you should have a LAN (VPC in AWS terms) but NO WAY OUT (a good thing if you want security). Each instance can still talk to each other. None cal talk to the internet. NOW add that "floating IP address" to some of the instances. THOSE can now talk to the internet, whether it is by NAT or direct. If the "get to the internet" address is NAT, then there should b
Just pick new names and call it a day (Score:1)
HP can call theirs the OpenHighPile. RackSpace can call theirs OpenRackStack, etc.
Cloud interoperability == race to the bottom? (Score:2)
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 oth
Re: (Score:2)
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.
First of all, what you are talking about already exists, and some people already do that (eg: migrating to the cheapest). There is even a market place to trade compute workload, with future market and all, just like with Enron!!! Though considering only price for a hosting provider is a big mistake IMO. There are lots of other parameters that comes into consideration, like quality of the support, bandwidth, overcommitting of the compute nodes, etc.
OpenStack (Score:1)
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.
Re: (Score:2)