Open Stack

On 12/08/2015 08:46 PM, Monty Taylor wrote:
> 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.

Amen, Monty. I agree with 100% of what you write above.

-jay