[openstack-tc] Request for comment on requiring running Linux as DefCore capability

Monty Taylor mordred at inaugust.com
Tue Dec 8 17:46:13 UTC 2015


On 12/03/2015 05:12 AM, Thierry Carrez wrote:
> Chris Hoge wrote:
>> [...] The DefCore
>> committee would like to bring this topic for formal discussion to the
>> next TC meeting on December 8 to get input from TC on this issue.
>
> Added to next week agenda.
>

I'm going to lay out my thoughts here, because they are slightly more 
wordy and I'm sure as much as people enjoy me typing furiously in TC 
meetings, it might be nice to read them in a structured manner.

I have a VERY strong view on this topic, it is thus:

- An OpenStack cloud MUST allow Image Uploads
- An OpenStack cloud MUST be able to boot a Linux guest
- An OpenStack cloud MAY provide non-Linux, non-VM flavors

Furthermore, today:

- An OpenStack cloud SHOULD be able to boot any OS that can run on x86 
architecture

because today we do not expose discoverable processor architecture in a 
sane way. Once we add that ability, I would change that to:

- An OpenStack cloud SHOULD be able to boot any OS that can run on the 
processor architecture is provides


(please note that the architecture one is unlikely to be in conflict 
with the must-linux because linux runs EVERYWHERE)

Now - with those statements, I should provide some reasoning. It is as 
follows:

Images as provided by cloud deployers diverge, and cause pain for our 
end users from an interoperability standpoint. At the massive number of 
TWO public clouds, the differences in provider images were great enough 
to justify a rather massive rewrite of the image portions of Infra's 
nodepool so that we could upload consistent images to our accounts. It 
is, in fact, the single greatest point of divergence between clouds. As 
a TC that cares about our end users, it is imperative that we take a 
stand and express the essential nature of image uploads in the cloud 
interoperability landscape.


In order to take a strong stance on that, we must be able to test the 
inbound interfaces that clouds provide to images running in them. This 
is, btw, the SECOND largest point of divergence between clouds. So in 
order for us to test that a cloud is providing inbound interfaces that a 
user of an OpenStack cloud should be able to expect (for instance, does 
config-drive show up, does the instance have the IP that neutron says it 
has)  we have to be able to have tests in the gate. Since OpenStack 
follows the Four Opens:  https://wiki.openstack.org/wiki/Open - that 
means that our tests must be Open Source. That means, to put a very 
blunt point on it, that an alternate test implemented on a Solaris 
guest, which certainly could be implemented to test the same inbound 
interfaces, is NOT something we can run in our gate, because Solaris is 
not Open Source and has not had an Open Source version since November 
12, 2010.

Linux is not an undue burden to ask someone to run. It runs on IBM 
z-Series mainframes, x86, power, Ssarc, mips, alpha, atom and arm 
processors. It runs on my phone, my TV and on Devananda's watch. It is 
free and anyone can get an operational image. The utilities our tests 
require of a Linux guest are standard and available.

Asking someone to boot a Linux guest in order to test inbound interfaces 
is, therefore, not only completely reasonable, it's the MOST reasonable 
and MOST obvious thing possible.

An OpenStack cloud that has Solaris-zones based flavors is pretty neat, 
and I'm sure there are users who will find value in it. We should not 
prevent such a thing from existing, and indeed, I do not believe we are. 
Such a cloud, if it only presents Solaris Zones, however, is not 
inter-operable with other OpenStack clouds, as linux images prepared for 
those clouds - or Windows images, for that matter, will not work if 
uploaded to it.

As an Open Source project, we have gone out of our way to enable 
productization and differentiation by our vendors. Our 3rd Party CI 
system is massive and Open- and our pluggability is almost cripplingly 
comprehensive.

However, to give up on interoperable image uploads simply because there 
is one vendor who would like to do one thing that a little bit different 
isn't just wrong, it would be giving up the ENTIRE effort.

We take a stand on very few things. We should take a stand on this.

Thank you.

Monty



More information about the OpenStack-TC mailing list