WARNING:
Danger, Will Robinson! Strong opinions ahead!
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).
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). 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.
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 *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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
