Open Stack

On 27/06/18 07:55, Jay Pipes wrote:
> WARNING:
> 
> Danger, Will Robinson! Strong opinions ahead!

I'd have been disappointed with anything less :)

> On 06/26/2018 10:00 PM, Zane Bitter wrote:
>> On 26/06/18 09:12, Jay Pipes wrote:
>>> Is (one of) the problem(s) with our community that we have too small 
>>> of a scope/footprint? No. Not in the slightest.
>>
>> Incidentally, this is an interesting/amusing example of what we talked 
>> about this morning on IRC[1]: you say your concern is that the scope 
>> of *Nova* is too big and that you'd be happy to have *more* services 
>> in OpenStack if they took the orchestration load off Nova and left it 
>> just to handle the 'plumbing' part (which I agree with, while noting 
>> that nobody knows how to get there from here); but here you're 
>> implying that Kata Containers (something that will clearly have no 
>> effect either way on the simplicity or otherwise of Nova) shouldn't be 
>> part of the Foundation because it will take focus away from 
>> Nova/OpenStack.
> 
> Above, I was saying that the scope of the *OpenStack* community is 
> already too broad (IMHO). An example of projects that have made the 
> *OpenStack* community too broad are purpose-built telco applications 
> like Tacker [1] and Service Function Chaining. [2]
> 
> I've also argued in the past that all distro- or vendor-specific 
> deployment tools (Fuel, Triple-O, etc [3]) should live outside of 
> OpenStack because these projects are more products and the relentless 
> drive of vendor product management (rightfully) pushes the scope of 
> these applications to gobble up more and more feature space that may or 
> may not have anything to do with the core OpenStack mission (and have 
> more to do with those companies' product roadmap).

I'm still sad that we've never managed to come up with a single way to 
install OpenStack. The amount of duplicated effort expended on that 
problem is mind-boggling. At least we tried though. Excluding those 
projects from the community would have just meant giving up from the 
beginning.

I think Thierry's new map, that collects installer services in a 
separate bucket (that may eventually come with a separate git namespace) 
is a helpful way of communicating to users what's happening without 
forcing those projects outside of the community.

> On the other hand, my statement that the OpenStack Foundation having 4 
> different focus areas leads to a lack of, well, focus, is a general 
> statement on the OpenStack *Foundation* simultaneously expanding its 
> sphere of influence while at the same time losing sight of OpenStack 
> itself -- and thus the push to create an Open Infrastructure Foundation 
> that would be able to compete with the larger mission of the Linux 
> Foundation.
> 
> [1] This is nothing against Tacker itself. I just don't believe that 
> *applications* that are specially built for one particular industry 
> belong in the OpenStack set of projects. I had repeatedly stated this on 
> Tacker's application to become an OpenStack project, FWIW:
> 
> https://review.openstack.org/#/c/276417/
> 
> [2] There is also nothing wrong with service function chains. I just 
> don't believe they belong in *OpenStack*. They more appropriately belong 
> in the (Open)NFV community because they just are not applicable outside 
> of that community's scope and mission.
> 
> [3] It's interesting to note that Airship was put into its own 
> playground outside the bounds of the OpenStack community (but inside the 
> bounds of the OpenStack Foundation).

I wouldn't say it's inside the bounds of the Foundation, and in fact 
confusion about that is a large part of why I wrote the blog post. It is 
a 100% unofficial project that just happens to be hosted on our infra. 
Saying it's inside the bounds of the Foundation is like saying 
Kubernetes is inside the bounds of GitHub.

> Airship is AT&T's specific 
> deployment tooling for "the edge!". I actually think this was the 
> correct move for this vendor-opinionated deployment tool.
> 
>> So to answer your question:
>>
>> <jaypipes> zaneb: yeah... nobody I know who argues for a small stable 
>> core (in Nova) has ever said there should be fewer higher layer services.
>> <jaypipes> zaneb: I'm not entirely sure where you got that idea from.
> 
> Note the emphasis on *Nova* above?
> 
> Also note that when I've said that *OpenStack* should have a smaller 
> mission and scope, that doesn't mean that higher-level services aren't 
> necessary or wanted.

Thank you for saying this, and could I please ask you to repeat this 
disclaimer whenever you talk about a smaller scope for OpenStack. 
Because for those of us working on higher-level services it feels like 
there has been a non-stop chorus (both inside and outside the project) 
of people wanting to redefine OpenStack as something that doesn't 
include us.

The reason I haven't dropped this discussion is because I really want to 
know if _all_ of those people were actually talking about something else 
(e.g. a smaller scope for Nova), or if it's just you. Because you and I 
are in complete agreement that Nova has grown a lot of obscure 
capabilities that make it fiendishly difficult to maintain, and that in 
many cases might never have been requested if we'd had higher-level 
tools that could meet the same use cases by composing simpler operations.

IMHO some of the contributing factors to that were:

* The aforementioned hostility from some quarters to the existence of 
higher-level projects in OpenStack.
* The ongoing hostility of operators to deploying any projects outside 
of Keystone/Nova/Glance/Neutron/Cinder (*still* seen playing out in the 
Barbican vs. Castellan debate, where we can't even correct one of 
OpenStack's original sins and bake in a secret store - something k8s 
managed from day one - because people don't want to install another ReST 
API even over a backend that they'll already have to install anyway).
* The illegibility of public Nova interfaces to potential higher-level 
tools.

> It's just that Nova has been a dumping ground over the past 7+ years for 
> features that, looking back, should never have been added to Nova (or at 
> least, never added to the Compute API) [4].
> 
> What we were discussing yesterday on IRC was this:
> 
> "Which parts of the Compute API should have been implemented in other 
> services?"
> 
> What we are discussing here is this:
> 
> "Which projects in the OpenStack community expanded the scope of the 
> OpenStack mission beyond infrastructure-as-a-service?"
> 
> and, following that:
> 
> "What should we do about projects that expanded the scope of the 
> OpenStack mission beyond infrastructure-as-a-service?"
> 
> Note that, clearly, my opinion is that OpenStack's mission should be to 
> provide infrastructure as a service projects (both plumbing and porcelain).
> 
> This is MHO only. The actual OpenStack mission statement [5] is 
> sufficiently vague as to provide no meaningful filtering value for 
> determining new entrants to the project ecosystem.

I think this is inevitable, in that if you want to define cloud 
computing in a single sentence it will necessarily be very vague.

That's the reason for pursuing a technical vision statement 
(brainstorming for which is how this discussion started), so we can 
spell it out in a longer form.

cheers,
Zane.

> I *personally* believe that should change in order for the *OpenStack* 
> community to have some meaningful definition and differentiation from 
> the broader cloud computing, application development, and network 
> orchestration ecosystems.
> 
> All the best,
> -jay
> 
> [4] ... or never brought into the Compute API to begin with. You know, 
> vestigial tail and all that.
> 
> [5] for reference: "The OpenStack Mission is to produce a ubiquitous 
> Open Source Cloud Computing platform that is easy to use, simple to 
> implement, interoperable between deployments, works well at all scales, 
> and meets the needs of users and operators of both public and private 
> clouds."
> 
>> I guess from all the people who keep saying it ;)
>>
>> Apparently somebody was saying it a year ago too :D
>> https://twitter.com/zerobanana/status/883052105791156225
>>
>> cheers,
>> Zane.
>>
>> [1] 
>> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-26.log.html#t2018-06-26T15:30:33 
>>
>>
>> __________________________________________________________________________ 
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev