Open Stack

On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor <mordred at 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
>>
>> 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.

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 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".

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170628/b95b6d71/attachment.html>