On 06/28/2017 11:27 PM, Steven Dake wrote:
On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor <mord...@inaugust.com
<mailto:mord...@inaugust.com>> wrote:
On 06/28/2017 09:50 AM, Thierry Carrez wrote:
Hi everyone,
Two weeks ago, as a result of a discussion at the Board+TC+UC
workgroup
working on "better communicating what is openstack", I started a
thread[1] about moving away from big tent terminology. The
thread went
in a lot of directions, including discussing GitHub mirroring
strategy,
what makes projects want to be official, the need for returning to a
past when everything was (supposedly) simpler, and naming fun.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html
<http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html>
Many agreed that the "Big Tent" name (as a synonym to "official
openstack projects") is hurting more than it helps, and we
should stop
using it. The issue is, merely stopping using it won't be enough. We
have tried, and the name sticks. You need to replace the name by
something that sticks more, or address the root cause directly.
The central issue being discussed here is an issue of external
perception. It's hard for newcomers to the OpenStack world to
see what
is a part of OpenStack and what's not. If you google "openstack
machine
learning", the first hits are Cognitive and Meteos, and it's
impossible
to tell that those are actually not OpenStack projects. One of
those has
been dead for 2 years -- having people think that those are official
projects hurts all the OpenStack projects, by lowering expectations
around what that means, in terms of quality, maintenance, or
community.
The confusion mainly stems from the fact that OpenStack project
infrastructure is open to any open source project (and it's
nobody's job
to clean up dead things). So you can find (on our wiki, on our
mailing-list, on our cgit farm, on our gerrit, on our GitHub
organization...) things that are actually not OpenStack, even
with the
expansive "are you one of us" definition. Arguably the most
confusing
aspect is the "openstack/" prefix in the git repository name, which
indicates some kind of brand association.
I'd say we have two options. We can address the perception issue
on the
edges, or you can treat the root cause. Neither of those options is
really an OpenStack governance change (or "big tent" change) --
they
are more about what to do with things that are actually *not* in our
governance.
Addressing the perception on the edges means making it clearer when
things are not official. The thread above discussed a lot of
potential
solutions. We could give unofficial things a catchy group name
(Stackforge, Opium, Electrons...), and hope it sticks. We could
find a
way to tag all projects on GitHub that are not official, or
mirror them
to another organization, or stop mirroring them altogether. We could
remove the openstack/ prefix from all the projects we host. We could
actively mark all wiki pages that are not about an official
project. We
could set up a separate Gerrit or separate ML for hosted projects
development discussions. The main issue with that approach is
that it's
a *lot* of work, and it never completely eliminates the confusion.
Removing the root cause would be a more radical move: stop offering
hosting to non-OpenStack projects on OpenStack infrastructure
altogether. We originally did that for a reason, though. The
benefits of
offering that service are:
I disagree that this is removing the root cause.
I believe this is reacting to a misunderstanding by hiding from it.
I do not believe that doing this provides any value to us as a
community.
Even though we do not actually use github for development, we have
implicitly accepted the false premise that github is a requirement.
It is suggested that the existence of git repos in the openstack/
github org is confusing to people. And our reaction to that is to
cut off access to our Open Source tools that we set up to
collaboratively develop cloud software and tell people to go use the
thing that people suggest is one of the causes of people being confused?
* People are not 'confused' by what OpenStack is.
Being "confused" is a passive-aggressive way of expressing that they
DISAGREE with what OpenStack is. We still have _plenty_ of people
who express that they think we should only be IaaS - so they're
still going to be unhappy with cloudkitty, congress and karbor.
Monty,
I think you are right on the money on this second point although it is
missing a salient point. There really are two problems here.
If we as a community disagree about the answer "What is OpenStack?" how
should we expect a Google search to answer this question for us? Most
people that have been working on OpenStack for a long time might agree
there is a "common core" of projects that make up OpenStack. I'll call
this as what you refer to as "OpenStack should only be an IaaS".
I'll pick on Heat for a moment. I personally think Heat is a
fundamental component of an IaaS. Others disagree that Heat is a
fundamental component of an IaaS. Other people may take offense at the
idea of any such classification. OpenStack in general struggles to
define itself in a taxonomy that mere mortals can understand because as
you mentioned, we are big.
I could see big long contentious debates about just one project (Heat)
being part or not part of the "IaaS". Multiply that by the number of
projects that are clearly not part of an IaaS.
I just defined what an IaaS was. And my definition may differ from
yours. Even answering the basic questions of "What is an IaaS" and "If
OpenStack is IaaS only, what projects are part of it?" is extremely
complex. Mix in other SAAS services in the definition of "What is
OpenStack?", and we don't really make any forward progress on one of our
two problems - passive-aggressive disagreement.
YES x1000
(Incidentally, I think it's unworkable to have an IaaS without DNS.
Other people have told me that having an IaaS without LBaaS or a message
queuing service is unworkable, while I neither need nor want either of
those things from my IaaS - they seem like PaaS components to me)
It is clear this is a problem for OpenStack, that as an Operator (or a
CIO who employs operators to operate a cloud), sorting out which
software I wish to deploy and which software I don't wish to deploy
becomes fraught with complex lengthy evaluations that ultimately
overwhelm the folks making the decision on what projects to deploy or not.
-ETOOMANYCHOICES (or -EAGAIN to be more precise:).
++
There is a reason some projects are more highly adopted than others in
the user survey. They provide a service a majority of Operators really
need to fundamentally operate a cloud. A slew of projects in OpenStack
really don't help an Operator do their job. They cost time to evaluate
and there is always that "one person" who needs "project X" where X is
something that operationally, a very few people benefit from in a CIO's
target organization.
I think solving the problem you outlined is pretty important, but I
don't really have any good answers. We have seen the threads suggesting
a taxonomy, and I think that could be made much more fine-grained, and
maybe that would help. Taking 3 projects through either integration or
into big tent, I can't tell you how important it was for a project to
move from stackforge to openstack on github. It was monumental for a
project to make that progression. Otherwise the project wasn't
considered legitimate and companies struggled to justify investment in it.
++
While I personally felt stackforge was a painful experience (project
renames - groan), it did provide some taxonomy that people could
understand. And it didn't present a google search for Cognitive with 4
commits related to machine learning. I understand to some degree how
painful dealing with stackforge was for the Infra team (The few project
renames I went through were very annoying.. out of thousands that were
likely renamed by the rockin Infra team.)
I mean - honestly repo renaming is painful- but it's also only a code
problem. If, as a community, we decided it was helpful to have the
ability to re-introduce a stackforge-like area and then to be able to
"promote" things- then someone could fund a human to add online-rename
functionality to gerrit.
I say if because at this point, with over a thousand things already in
the official bucket, I'm not sure a return to the model will help
anymore (it's not like when we promoted heat and ceilometer and they
were joining a set of 12 repos)
I felt the tagging process was supposed to help fill the taxonomy gap;
ultimately that didn't seem to happen.
Earlier you mentioned it was a false premise that github was a
requirement. I disagree. It seems that, for better or worse, the
organizational namespace in github is how people identify "What is
OpenStack" and "What is not".
Oh - I agree it has become a de facto thing. The problem is that we put
mirrors in github because if when we didn't put mirrors in github other
people were putting them in github with poorly maintained bots.
It's sad that having done so has communicated information to people that
was never intended to be communicated... but I agree, that has happened.
The removal of stackforge took something away from OpenStack - and that
was that link to the world that says "Here is what OpenStack is".
Previously the TC made the judgement about what was in openstack
namespace and what was in stackforge. General technologists understood
the difference - even the 99% of people that Lauren mentioned. When
that clearly obvious taxonomy was removed, it did result in external
confusion.
Right - but there were two changes that happened related to the removal
of stackforge. It wasn't only removing that badge of officialness- it
was also that we redefined 'official' from being 'part of a limited set
of software that people think we have blessed to be good quality' to
'software that is made by people who are the OpenStack community'
So that we don't forget - the analog to this problem that we had before
the Big Tent was that people were upset with us for accepting things
into the Integrated Release before they were Production Ready. They
wanted us to tell them the EXACT same thing they want us to tell them
now - which bits are good and which bits are not yet good.
The problem we STILL haven't solved pre-dates the Big Tent. This is one
of the reasons I'm so violently pushing back on the idea that anything
related to git namespaces or categorizations will somehow magically
solve any of this.
As you said before, we do not have an answer for "WHAT is OpenStack". We
have an answer for WHO is OpenStack, HOW is OpenStack made, WHY
OpenStack is made and even WHERE it is made. But because we do not run
the TC like a team-version of a BDFL, we thus far have not had any
person or persons who sit in a position who actually have both the
authority and the context to answer that question prescriptively.
What we do have is a community - both vendor and user - who can answer
that question organically. The main five IaaS projects (nova, keystone,
glance, neutron, cinder) are in- and have been defined that way by our
community. Everyone running an OpenStack runs them. Swift and Heat are
both pretty much in for similar reasons, although they're still not as
ubiquitous as the other five. Ironic and Manila and Barbican and Horizon
and Magnum have love - and then the bottom falls out because people
either don't like the implementation or it's a project that doesn't fill
their needs.
So really we do have external confusion for the 99% of folks looking for
a cloud solution that have minimal exposure to OpenStack and also we
struggle as a community to define what we want OpenStack to be.
Sometimes these problems overlap, compounding the problem.
>
Its a shame we can't find a way to make the "stackforge namespace"
concept strategically sound to solve the external confusion problem.
Regards
-steve
__________________________________________________________________________
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
