[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