Fuel is not just a GUI

Posted Jun 19, 2015 5:07 UTC (Fri) by angdraug (subscriber, #7487)
Parent article: The costs of forks

Thanks for an excellent summary of that thread! I expect great things to come out of this discussion in the medium and long term for both projects. Here's a few knitpicks that I hope clear some confusion about Fuel and why maintaining Puppet modules is very much in its scope. Disclaimer: I'm one of the Fuel developers mentioned in the article.

The Fuel project, which is a graphical user interface (GUI) to help deploy, test, and manage OpenStack installations.

This makes Fuel seem like it's mostly a GUI, and may have contributed to fandingo's initial confusion. If one makes that mistake it becomes really hard to understand how that's related to Puppet and OpenStack (or even to Puppet OpenStack, once you've figured out that that is thing of it's own).

Fuel is much more than a GUI. Here's CLOC breakdown by language.

133k lines of Python + 31k YAML + 12k JSON + 20k XML, most in management backend, orchestration, integration tests, as well as configuration for many data-driven components.
42k lines of Puppet + 113k Ruby, most of it in Puppet manifests, resource providers, and their unit tests.
23k lines of JavaScript + 10k HTML + 1k CSS, that's pretty much it for the GUI, all the logic is in the backend and is also exposed via REST API and CLI.
17k lines of shell scripts all over the place, including deployment scriptlets, HA glue, management utilities, and whatnot.

Counting the commits in the upcoming 6.1 release of Fuel, the breakdown between management layer, Puppet, and GUI looks like this:

Management: 593
Puppet: 656
GUI: 249

So while I like to think that Fuel's got an awesome GUI, it remains only the tip of the iceberg, while Puppet code remains the busiest part of Fuel codebase.

It is sometimes easy for development projects to get so wrapped up in solving their own problems that they forget to occasionally look up and evaluate their relationship with the rest of the ecosystem. That appears to be what happened here at some level. The problem has been known and discussed at various summits over the years, but little has changed.

I'm inclined to think that Emilien's email has reinvigorated Fuel's efforts to move towards upstream that me and Andrew have helped start in March 2014 (and which bore first fruit in October 2014), rather than started something that wasn't already happening. In that light, I feel that it's too harsh to say that it has all remained just talk until now.

Pushing the open source agenda with OpenStack vendors remains an uphill battle that is far from won, and not only because we're too busy to look up. As fandingo has noted, OpenStack community is viciously competitive and dominated by contributors with strong commercial interests, some with big egos, some with very superficial understanding of how free software communities work (and don't work). Downplaying even feeble attempts at coopetition isn't helping with any of these challenges.