Slashdot Mirror

← Back to Stories (view on slashdot.org)

OpenStack To Crack Down On Incompatible Clouds

Posted by ryuzaki0 on from the you're-outta-here dept.

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."

20 of 30 comments (clear)

  1. Save you the reading... by Anonymous Coward · · 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.

    1. Re:Save you the reading... by maxwell+demon · · 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.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    2. Re:Save you the reading... by nametaken · · 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.

    3. Re:Save you the reading... by stephanruby · · Score: 1

      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.

    4. Re:Save you the reading... by marcello_dl · · Score: 1

      > 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 :)

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    5. Re:Save you the reading... by GPLHost-Thomas · · Score: 1

      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 here! :)

  2. OpenStack cracking down on Rackspace? by Anonymous Coward · · 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.

    1. Re:OpenStack cracking down on Rackspace? by Anonymous Coward · · Score: 5, Informative

      I'm not sure what HP's excuse is, though.

      HP doesn't need an excuse 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.

    2. Re:OpenStack cracking down on Rackspace? by tqk · · Score: 2

      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.

      --
      "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
    3. Re:OpenStack cracking down on Rackspace? by Anonymous Coward · · 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 you measure customer usage? OpenStack has only recently begun to address this with Ceilometer. We're contributing to and helping shape this project. If you're going to OpenStack next week, you'll see lots of presentations from HP (and, of course, Rackspace).

      Public cloud providers must invent their own ways to do things OpenStack doesn't do yet. Thus, proprietary functionality is created.

      Usually these are extensions that don't make us incompatible with core OpenStack. We try to contribute them back to OpenStack, but they aren't always receptive. Were it not for the contributions of Rackspace and HP, OpenStack would be much less viable.

  3. Re:we have to be realistic by BButlerNWW9564 · · Score: 1

    and paying $400 a month for gold support package

  4. sticky situation by BButlerNWW9564 · · Score: 2

    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.

  5. Does the API affect operational model? by Skapare · · Score: 1

    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
    1. Re:Does the API affect operational model? by GPLHost-Thomas · · Score: 1

      What you are asking for is the default in Openstack. I have just finished writing a howto about Openstack networking in here:
      https://wiki.debian.org/OpenStackHowto/Quantum

      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 Openstack, if your provider is using Nova and Quantum in a normal setup. The problem is that Rackspace is half in the past (with their own previous implementation which they want to stay compatible with), and half in the future (with implementations of things which aren't in the mainstream project yet because this takes time, cells is a very good example that turned out very well since it is now integrated). As for HP, it is a very different story. They decided to stick with the Diablo release for a long time, and basically forked it, also working on features away from the project (eg: healthmon).

      Finally, I strongly believe that both Rackspace and HP are committed to have these problems solved, as this is very problematic for them also (eg: maintaining their own branch means a big loss in terms of human hours of development). So I am convinced that in the long run, these problems will go away.

    2. Re:Does the API affect operational model? by Skapare · · Score: 1

      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 be a gateway which is NOT one of your instances.

      I'd rather have a NO-NAT access to the internet. That means my interface would have the actual internet address bound on its interface, or in the system (in addition to the LAN addresses). But the current model of using routers doesn't make that easy (I have a different model design that would do this, but it would mean replacing the firmware on routers and I don't know how OpenStack would handle it).

      Companies going their own way can be a problem. But less flexible standards, open or not, can be just as bad. The best standards define ways to do things with greater flexibility to innovate.

      --
      now we need to go OSS in diesel cars
  6. Just pick new names and call it a day by davidwr · · Score: 1

    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.
  7. Cloud interoperability == race to the bottom? by swb · · Score: 1

    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.

    1. Re:Cloud interoperability == race to the bottom? by GPLHost-Thomas · · Score: 1

      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.

  8. OpenStack by Anonymous Coward · · Score: 1

    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.

  9. Re:Half done stack by GPLHost-Thomas · · Score: 1

    While the implementation (eg: the distribution packages and the code behind it) are moving a lot, and in a very rapid way (and I quite know it, since I'm the Debian Developer working on Openstack packaging), the API clients stays and is quite stable. And that is what counts for a user: you would always use either the python-client modules, or the shell command line tools associated with it.