Agree. Regards -steve
On Thu, Jun 29, 2017 at 7:55 AM, Monty Taylor <mord...@inaugust.com> wrote: > 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-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-requ...@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-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