<div dir="ltr">Agree.<div><br></div><div>Regards</div><div>-steve</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 7:55 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/28/2017 11:27 PM, Steven Dake wrote:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Wed, Jun 28, 2017 at 2:50 PM, Monty Taylor <<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a> <mailto:<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>>> wrote:<br>
<br>
On 06/28/2017 09:50 AM, Thierry Carrez wrote:<br>
<br>
Hi everyone,<br>
<br>
Two weeks ago, as a result of a discussion at the Board+TC+UC<br>
workgroup<br>
working on "better communicating what is openstack", I started a<br>
thread[1] about moving away from big tent terminology. The<br>
thread went<br>
in a lot of directions, including discussing GitHub mirroring<br>
strategy,<br>
what makes projects want to be official, the need for returning to a<br>
past when everything was (supposedly) simpler, and naming fun.<br>
<br>
[1]<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2017-June<wbr>/118368.html</a><br>
<<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-June/118368.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pi<wbr>permail/openstack-dev/2017-Jun<wbr>e/118368.html</a>><br>
<br>
Many agreed that the "Big Tent" name (as a synonym to "official<br>
openstack projects") is hurting more than it helps, and we<br>
should stop<br>
using it. The issue is, merely stopping using it won't be enough. We<br>
have tried, and the name sticks. You need to replace the name by<br>
something that sticks more, or address the root cause directly.<br>
<br>
The central issue being discussed here is an issue of external<br>
perception. It's hard for newcomers to the OpenStack world to<br>
see what<br>
is a part of OpenStack and what's not. If you google "openstack<br>
machine<br>
learning", the first hits are Cognitive and Meteos, and it's<br>
impossible<br>
to tell that those are actually not OpenStack projects. One of<br>
those has<br>
been dead for 2 years -- having people think that those are official<br>
projects hurts all the OpenStack projects, by lowering expectations<br>
around what that means, in terms of quality, maintenance, or<br>
community.<br>
<br>
The confusion mainly stems from the fact that OpenStack project<br>
infrastructure is open to any open source project (and it's<br>
nobody's job<br>
to clean up dead things). So you can find (on our wiki, on our<br>
mailing-list, on our cgit farm, on our gerrit, on our GitHub<br>
organization...) things that are actually not OpenStack, even<br>
with the<br>
expansive "are you one of us" definition. Arguably the most<br>
confusing<br>
aspect is the "openstack/" prefix in the git repository name, which<br>
indicates some kind of brand association.<br>
<br>
I'd say we have two options. We can address the perception issue<br>
on the<br>
edges, or you can treat the root cause. Neither of those options is<br>
really an OpenStack governance change (or "big tent" change) --<br>
they<br>
are more about what to do with things that are actually *not* in our<br>
governance.<br>
<br>
Addressing the perception on the edges means making it clearer when<br>
things are not official. The thread above discussed a lot of<br>
potential<br>
solutions. We could give unofficial things a catchy group name<br>
(Stackforge, Opium, Electrons...), and hope it sticks. We could<br>
find a<br>
way to tag all projects on GitHub that are not official, or<br>
mirror them<br>
to another organization, or stop mirroring them altogether. We could<br>
remove the openstack/ prefix from all the projects we host. We could<br>
actively mark all wiki pages that are not about an official<br>
project. We<br>
could set up a separate Gerrit or separate ML for hosted projects<br>
development discussions. The main issue with that approach is<br>
that it's<br>
a *lot* of work, and it never completely eliminates the confusion.<br>
<br>
Removing the root cause would be a more radical move: stop offering<br>
hosting to non-OpenStack projects on OpenStack infrastructure<br>
altogether. We originally did that for a reason, though. The<br>
benefits of<br>
offering that service are:<br>
<br>
<br>
I disagree that this is removing the root cause.<br>
<br>
I believe this is reacting to a misunderstanding by hiding from it.<br>
I do not believe that doing this provides any value to us as a<br>
community.<br>
<br>
Even though we do not actually use github for development, we have<br>
implicitly accepted the false premise that github is a requirement.<br>
It is suggested that the existence of git repos in the openstack/<br>
github org is confusing to people. And our reaction to that is to<br>
cut off access to our Open Source tools that we set up to<br>
collaboratively develop cloud software and tell people to go use the<br>
thing that people suggest is one of the causes of people being confused?<br>
<br>
* People are not 'confused' by what OpenStack is.<br>
<br>
Being "confused" is a passive-aggressive way of expressing that they<br>
DISAGREE with what OpenStack is. We still have _plenty_ of people<br>
who express that they think we should only be IaaS - so they're<br>
still going to be unhappy with cloudkitty, congress and karbor.<br>
<br>
<br>
Monty,<br>
<br>
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.<br>
<br>
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".<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></div></div>
YES x1000<br>
<br>
(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)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
-ETOOMANYCHOICES (or -EAGAIN to be more precise:).<br>
</blockquote>
<br></span>
++<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
</blockquote>
<br></span>
++<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.)<br>
</blockquote>
<br></span>
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.<br>
<br>
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)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I felt the tagging process was supposed to help fill the taxonomy gap; ultimately that didn't seem to happen.<br>
<br>
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".<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
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'<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
><br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Its a shame we can't find a way to make the "stackforge namespace" concept strategically sound to solve the external confusion problem.<br>
<br>
Regards<br>
-steve<br>
<br>
<br>
<br>
<br></span><span class="">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>