[openstack-dev] [StarlingX] StarlingX code followup discussions

Jay Pipes jaypipes at gmail.com
Wed May 23 17:48:56 UTC 2018

On 05/23/2018 12:49 PM, Colleen Murphy wrote:
> On Tue, May 22, 2018, at 10:57 PM, Jay Pipes wrote:
>> Are any of the distributions of OpenStack listed at
>> https://www.openstack.org/marketplace/distros/ hosted on openstack.org
>> infrastructure? No. And I think that is completely appropriate.
> Hang on, that's not quite true. From that list I see Mirantis, Debian, Ubuntu, and RedHat, who all have (or had until recently) significant parts of their distros hosted on openstack.org infrastructure and are/were even official OpenStack projects governed by the TC.

I believe you may be confusing packages (or package specs) with 

Mirantis OpenStack was never hosted on an openstack infrastructure. Fuel 
is, as are deb spec files and Puppet manifests, etc. But the 
distribution of OpenStack is the collection of all those specs/build 
files along with a default configuration and things like project deltas 
exposed as patch files. Same goes for RDO, Canonical OpenStack, etc.

> It's also important to make the distinction between hosting something on openstack.org infrastructure and recognizing it in an official capacity. StarlingX is seeking both, but in my opinion the code hosting is not the problem here.

Yep, you're absolutely right that there is a distinction between hosting 
and consuming the foundation's resources and recognizing StarlingX in 
some official capacity. I'm concerned about both items.

My concern with the former item is that I believe this is setting a 
precedent that the foundation's resources are being used to host a 
particular OpenStack distribution -- which is something I don't believe 
should happen. Vendor products/distributions [1] should be supported by 
that vendor, IMHO. [2]

My concern with the latter item is more an annoyance with what I see as 
Intel / Wind River playing the Linux Foundation against the OpenStack 
foundation to see which will bear the burden of supporting code that I 
feel is being dumped on the upstream community. I fully understand that 
Dean has been put into a very awkward situation with all of this, and I 
want to be clear that I mean no disrespect towards any Intel or Wind 
River engineer/contributor. My gripe is with the business/management 
decisions that led to this. Dean was very gracious in answering a number 
of my questions on the etherpad linked in the original post. Thank you 
to Dean for being gracious under fire.

Finally, I'd like to say that I did read the long discussion thread the 
TC had about this [3]. A number of the TC folks brought up interesting 
points about the subject at hand, and I recognize there's a bit of a 
damned-if-we-do-damned-if-we-don't situation. Jeremy pointed out concern 
about the optics of having the Linux Foundation hosting a fork of 
OpenStack and how bad that would look. A number of folks, including 
Jeremy, also brought up the potential renaming of the OpenStack 
Foundation to the Open Infrastructure Foundation and what such a rename 
might do to ease concerns over things like Airship and StarlingX. I 
don't personally feel a rename would ease much of the discontent, but 
I'm also clearly biased and recognize that I am so.

One point that I brought up on the etherpad was whether folks have 
considered an "edge constellation" instead of a fork of OpenStack? In 
other words, the edge constellation would be a description of an 
opinionated build of OpenStack (and other supporting services) that 
would be focused on the mobile/edge cloud use cases, but there would not 
be a fork of OpenStack. Anyway, I think it's worth considering at least; 
it's a sticky and awkward situation, for sure.


[1] Yes, even if that vendor has now chosen a different strategy of open 
sourcing their code versus keeping it proprietary

[2] For the record, I believe it was a mistake to put Mirantis' Fuel 
product (and let's face it, Fuel was a product of Mirantis) under the 
openstack.org's hosting.


More information about the OpenStack-dev mailing list