Open Stack

Agree.

Regards
-steve

On Thu, Jun 29, 2017 at 7:55 AM, Monty Taylor <mordred at inaugust.com> wrote:

> On 06/28/2017 11:27 PM, Steven Dake wrote:
>
>
>>
>> On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor <mordred at inaugust.com
>> <mailto: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
>>         <http://lists.openstack.org/pipermail/openstack-dev/2017-Jun
>> e/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-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170629/cce448e6/attachment.html>