[openstack-dev] [tc][fuel] Making Fuel a hosted project

Samuel Cassiba s at cassiba.com
Fri Jun 16 20:51:01 UTC 2017



> On Jun 16, 2017, at 07:28, Jay Pipes <jaypipes at gmail.com> wrote:
> 
> On 06/16/2017 09:57 AM, Emilien Macchi wrote:
>> On Thu, Jun 15, 2017 at 4:50 PM, Dean Troyer <dtroyer at gmail.com> wrote:
>>> On Thu, Jun 15, 2017 at 10:33 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>>>> I'd fully support the removal of all deployment projects from the "official
>>>> OpenStack projects list".
>>> 
>>> Nice to hear Jay! :)
>>> 
>>> It was intentional from the beginning to not be in the deployment
>>> space, we allowed those projects in (not unanimously IIRC) and most of
>>> them did not evolve as expected.
>> Just for the record, it also happens out of the deployment space. We
>> allowed (not unanimously either, irrc) some projects to be part of the
>> Big Tent and some of them have died or are dying.
> 
> Sure, and this is a natural thing.
> 
> As I mentioned, I support removing Fuel from the official OpenStack projects list because the project has lost the majority of its contributors and Mirantis has effectively moved in a different direction, causing Fuel to be a wilting flower (to use Thierry's delightful terminology).

It is not my intention to hijack this, but reading the thread compelled me to respond, maintaining the #4 deployment tool per the recent user survey and all. To be frank, Chef is almost right where Fuel is heading. I’m a little surprised we haven’t been shown the door yet, since people keep saying we’re dead. When Chef finally did cut Newton, we said our size as a team limited what we could produce, and that we were effectively keeping the lights on. To borrow the analogy, if Fuel is a wilting flower, Chef is a tumbleweed. Against all odds, it just keeps on tumbling. Some even think it’s dead. :)

> 
>>> I would not mind picking one winner and spending effort making an
>>> extremely easy, smooth, upgradable install that is The OneTrue
>>> OpenStack, I do not expect us to ever agree what that will look like
>>> so it is effectively never going to happen.  We've seen how far
>>> single-vendor projects have gone, and none of them reached that level.
>> Regarding all the company efforts to invest in one deployment tool,
>> it's going to be super hard to find The OneTrue and convince everyone
>> else to work on it.
> 
> Right, as Dean said above :)

Operators will pick what works best for their infrastructure and their needs, so let them, and be there for them when they fuck up and need help. Prescribing a One True Method will alienate those who might otherwise become the biggest cheerleaders. If OpenStack wants to become a distro, that’s one thing. If not, we’re swinging the pendulum pretty hard.

> 
>> Future will tell us but it's possible that deployments tools will be
>> reduced to 2 or 3 projects if it continues that way (Fuel is slowly
>> dying, Puppet OpenStack has less and less contributors, same for Chef
>> afik, etc).
> 
> Not sure about that. OpenStack Ansible and Kolla have emerged over the last couple years as very strong communities with lots of momentum.
> 
> Sure, Chef has effectively died and yes, Puppet has become less shiny.

Ahem. We’re not dead, just few, super distributed and way stretched. We’re asynchronous to the point where pretty much only IRC and Gerrit makes sense to use. I can understand how you might misconstrue this as rigor mortis, so allow me to illuminate. We still manage to muddle through a review or three a month. Sure, there isn’t the rapid cadence we’d all hoped there would be, but my last rant highlighted on some of those deficiencies. Deployment tools, in this case, Chef, really lack a solid orchestration component to build from nothing, which has become more of an essential thing to have in the development of OpenStack. Compound this by an overly complex CI process to resemble something close to the real world, and you have what we have today. Please, don’t start sweeping Chef out the door with Fuel. I won’t sugar coat: it’s bad, but not to the point where we should say Chef has “died”. To say Chef has “died”, when we’re still pushing reviews, is mighty exclusionary and disrespectful of those that still do dedicate time and resources, even if that wasn’t the intention. I do what I can to help new users along their path, when they come across my radar. We still have newcomers. We still have semi-active contributors, no matter how many days between change sets.

Some things need a One True Path, but more so in what goes into the tools than tooling options themselves.  A set of standards would go well in that direction, but I refer you to the XKCD on standards in that case. I say this, lest we start alienating operators that can’t easily change the universe to turn their $10MM+ production clouds on a dime. Even at the Boston Summit, there were whispers of some people still using Chef. Chef hasn’t “effectively died”, just become way less shiny, boring even, without marketing and a strong team advocating for it. Downstream Chef users seem to be happy to maintain forks and wrappers, so long as there is an upstream to track when it’s time to jump to the next release. Downstream cares that things work and that they don’t give sudden surprises. Slashing the ecosystem, or whatever label you want to give it today, is a huge surprise to those who don’t have time track openstack-dev or master branches.

> 
> But the deployment and packaging space will always (IMHO) be the domain of the Next Shiny Thing.
> 
> Witness containers vs. VMs (as deployment targets)
> 
> Witness OS packages vs. virtualenv/pip installs vs. application container images.
> 
> Witness Pacemaker/OCF resource agents vs. an orchestrated level-based convergence system like k8s or New Heat.
> 
> Witness LTS releases vs. A/B deployments vs. continuous delivery.
> 
> Witness PostgreSQL vs. MySQL vs. NoSQL vs. NewSQL.
> 
> Witness message queue brokers vs. 0mq vs. etcd-as-system-bus.
> 
> As new tools, whether fads or long-lasting, come and go, so do deployment strategies and tooling. I'm afraid this won't change any time soon :)

Not unless things get way more delightful. In my infrastructure, I like for things to Just Work and to not have to shake up the landscape every major release, especially at the current release cadences, and I’d be surprised if you found someone who didn’t share that sentiment. The user survey says there are still downstream users of all of the deployment projects, even the one currently being shown the door; and now those downstream Fuel users are out in the cold without an obvious path forward, save for “lol deal with it". From my point of view, we mustn’t lose sight of that just because a given project doesn’t have enough throughput, or enough developers, just because a vendor moves on to something newer and shinier.

> 
> Best,
> -jay
> 
> __________________________________________________________________________
> 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


--
Best,

Samuel Cassiba


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170616/fbb1d6ae/attachment.sig>


More information about the OpenStack-dev mailing list