What is an OpenStack Powered Compute?

news

Author: stefano
Source: Planet OpenStack

The OpenStack Technical Committee voted a resolution suggesting to the OpenStack Board to modify the definition of “OpenStack Powered Compute” to include statements such as

An `OpenStack Powered Compute`_ Cloud MUST be able to boot a Linux Guest

This is quite a change in OpenStack DefCore efforts, since as Rob says

The fundamental premise of DefCore is that we can use the development tests for API and behavior validation

DefCore has always been about the OpenStack API and carefully avoided checking the implementation of clouds, leaving enough space for vendors to differentiate their products without harming consumers. An ironic twist of fate is now forcing the whole program to take a stand on implementation, too.

Stating that an OpenStack cloud MUST be able to boot a Linux Guest  is the most controversial and I see why the TC is going into this direction: as a OpenStack user, I expect to be able to upload my images in any OpenStack cloud. Given that Linux is the OS of choice for the vast majority of today’s cloud workloads, booting my Linux image is a must have. It’s a practical choice and one that makes a lot of sense.

The problem is that forcing implementation details by the TC is a slippery slope. Will the TC suggest also that any OpenStack cloud must offer a routable IP or boot a VM in less than 5 seconds or that flavor names are always the same across all OpenStack clouds? Granted, all these requests make sense from the perspective of at least some users: there are already lots of unnecessary complications for putting workloads on OpenStack right now.

The question is if those mandates make sense for OpenStack as a whole and I’m not convinced they do. I tend to lean towards two complimentary positions:

  1. make sure that OpenStack Compute Powered clouds are transparent and their behavior is discoverable. Like the OpenStack Foundation exposes the results of the DefCore API compatibility on the Marketplace, I think DefCore should test the implementation of the clouds, public clouds especially and expose the results. This way a user would know that a cloud passes DefCore tests, runs OpenStack upstream code (as done now) and allows uploading/booting Linux guests, offer IPv6 by default, boot in x seconds, has XYZ flavors, allows custom flavors, etc.
  2. DefCore should consider public clouds, hosted private clouds and distributions as different beasts. To me it makes more sense to expect a public cloud to allow uploading Linux guests than mandate the same for a private clod… even less sense for a distribution. The buying process for these is different and the needs for users are different, too.

Thoughts?

I’m a candidate for OpenStack Foundation Board of Directors: if you like what you read, remember to vote for me at the 2016 elections

Powered by WPeMatico