<div dir="ltr"><div>Fuelers, </div><div><br></div><div>I would like to announce my candidacy for Fuel PTL in the Ocata cycle.</div><div><br></div><div><br></div><div>** Introduction **</div><div><br></div><div>First of all, allow me to introduce myself. I joined the OpenStack Community</div><div>during the Juno release cycle. I started on a "consumer" side - as a Head of</div><div>IT at a media holding I was consuming and bringing Open Source technologies</div><div>to an "Enterprise world" as much as it was possible and OpenStack was there</div><div>as well. I had been investigating OpenStack and finally deployed my first</div><div>private cloud manually. It was Juno 2014.2 and it was a very-very long trip.</div><div>Half a year later I found out that Fuel could do it much more faster! I liked</div><div>Fuel mission, both stated and delivered - make OpenStack installation process</div><div>easier and more streamlined. OpenStack was in a serious need of such a tool,</div><div>as one of prerequisites for lowering adoption barriers.</div><div><br></div><div>Finally, I joined Fuel Community as a deployment engineer. Since 2015 I've</div><div>been an active contributor in the very core features of Fuel and have been</div><div>leading a Fuel development team [0] at Mirantis. If you're using or developing</div><div>Fuel - you’ve probably heard of some of the features that we designed and</div><div>implemented:</div><div>Task-based deployment engine [1], Post-deployment plugins installation,</div><div>Deployment History [2][3], Data-driven orchestration [4] with Unlocked</div><div>Settings and Network tabs [5] (aka Fuel LCM), Custom graphs execution [6],</div><div>Release-as-a-Plugin [7] and Everything-as-a-Graph [8].</div><div><br></div><div>As you can see, the main goal of this work was to make Fuel more flexible and</div><div>friendly for deployment engineers, based on my and my colleagues’ experience</div><div>from real OpenStack deployments. And I would like to keep doing it</div><div>as a Fuel PTL.</div><div><br></div><div><br></div><div>** Community **</div><div><br></div><div>Fuel, as a part of OpenStack BigTent since November 17 2015, had the first</div><div>design summit at Austin. Vladimir Kozhukalov did a great job organizing it.</div><div>This summit allowed Fuel community to solicit a feedback, to align our goals</div><div>with OpenStack community and, the most important, to start having an open</div><div>design. Open Design was the last of four Opens [9] to be achieved by Fuel</div><div>Community. Unfortunately during the Newton release cycle not all discussions</div><div>and decisions were open and public enough. We need to avoid such behaviour</div><div>in future. Fuel Community will have a very modest representation during</div><div>upcoming Fuel Ocata Design summit at Barcelona and the first Project Teams</div><div>Gathering [10] And that’s the reason to make our goal #1: the expansion of</div><div>the OpenStack Community involvement into Fuel design during the whole release</div><div>cycle. And as a result encourage new contributors, build a healthy community</div><div>around Fuel and achieve the contribution diversity.</div><div><br></div><div><br></div><div>** Technical challenges **</div><div><br></div><div>October 2015 Fuel was the 5th deployment tool for OpenStack with 12% [11]</div><div>but April 2016 Fuel got the 3rd place with 19% [12] right after Puppet and</div><div>Ansible. While SaltStack, Chef and Puppet are visibly going down Fuel is</div><div>taking over the OpenStack deployment world. But we still have a set of</div><div>technical challenges and we must focus on:</div><div><br></div><div>* Infrastructure-as-Code (IaC) allows us to provide convenient and familiar UX</div><div>for those user who have experience with dynamic infrastructure in Public</div><div>clouds - it's now easy to control OpenStack configuration and versioning via</div><div>git. Since nailgun extension for IaC [13] became a part of Fuel project [14]</div><div>we should actively support and develop it.</div><div><br></div><div>* Lifecycle management. Making changes on already installed clouds is still</div><div>complicated. We’ve done a lot of work in this direction, but we are still not</div><div>there.</div><div><br></div><div>* The Upgrades of Fuel itself and OpenStack clusters managed by Fuel still</div><div>need more flexibility and much better UX. We can fix it using the custom</div><div>graphs concept [8].</div><div><br></div><div>* Fuel extensions and plugins framework should be polished and provide itself</div><div>with stable API. Moreover extensions and plugins SDK should become</div><div>developer-friendly and support all new features like release-as-a-plugin [7].</div><div><br></div><div>* Single Fuel Master node should support multiple different OpenStack releases.</div><div>First step [7] was done. Let’s keep moving.</div><div><br></div><div>* Audit, troubleshooting and debugging became easier with Deployment History</div><div>features and dry-run/noop deployments but we are still facing with the</div><div>inconsistent error reporting and diagnostic snapshots. We can improve it using</div><div>graphs.</div><div><br></div><div>* Documentation team has done a great job of restructuring Fuel documentation</div><div>and moving it under OpenStack Doc space. However, as subject matter experts,</div><div>we need to proactively review and help the doc team with updates and new</div><div>features documentation [15]</div><div><br></div><div><br></div><div>** Afterword **</div><div><br></div><div>As an epilogue I would like to say: Working closely with OpenStack Community</div><div>I see that PTL is more about how to help people come together and achieve</div><div>goals, how to built horizontal communications between project teams and how</div><div>to keep developers in their zone of maximum performance.</div><div><br></div><div>Fuel is a mature project with existing strong development team. And we should</div><div>keep these things in place.</div><div><br></div><div>WBR, Alexey Shtokolov</div><div>irc: ashtokolov</div><div><br></div><div>[0] <a href="https://launchpad.net/~fuel-toolbox/+members">https://launchpad.net/~fuel-toolbox/+members</a></div><div>[1] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/8.0/task-based-deployment-mvp.html">https://specs.openstack.org/openstack/fuel-specs/specs/8.0/task-based-deployment-mvp.html</a></div><div>[2] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/9.0/store-deployment-tasks-history.html">https://specs.openstack.org/openstack/fuel-specs/specs/9.0/store-deployment-tasks-history.html</a></div><div>[3] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/9.0/save-deployment-info-in-database.html">https://specs.openstack.org/openstack/fuel-specs/specs/9.0/save-deployment-info-in-database.html</a></div><div>[4] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/9.0/tasks-computable-fields-with-yaql.html">https://specs.openstack.org/openstack/fuel-specs/specs/9.0/tasks-computable-fields-with-yaql.html</a></div><div>[5] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/9.0/unlock-settings-tab.html">https://specs.openstack.org/openstack/fuel-specs/specs/9.0/unlock-settings-tab.html</a></div><div>[6] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/9.0/execute-custom-graph.html">https://specs.openstack.org/openstack/fuel-specs/specs/9.0/execute-custom-graph.html</a></div><div>[7] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/10.0/release-as-a-plugin.html">https://specs.openstack.org/openstack/fuel-specs/specs/10.0/release-as-a-plugin.html</a></div><div>[8] <a href="https://specs.openstack.org/openstack/fuel-specs/specs/10.0/graph-concept-extension.html">https://specs.openstack.org/openstack/fuel-specs/specs/10.0/graph-concept-extension.html</a></div><div>[9] <a href="https://governance.openstack.org/reference/opens.html">https://governance.openstack.org/reference/opens.html</a></div><div>[10] <a href="http://www.openstack.org/ptg">http://www.openstack.org/ptg</a></div><div>[11] <a href="http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf">http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf</a> Page 26</div><div>[12] <a href="https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf">https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf</a> Page 37</div><div>[13] <a href="https://github.com/openstack/fuel-nailgun-extension-iac">https://github.com/openstack/fuel-nailgun-extension-iac</a></div><div>[14] <a href="https://review.openstack.org/#/c/366779/">https://review.openstack.org/#/c/366779/</a> <a href="https://review.openstack.org/#/c/366780/">https://review.openstack.org/#/c/366780/</a></div><div>[15] <a href="http://stackalytics.com/report/contribution/fuel-docs/180">http://stackalytics.com/report/contribution/fuel-docs/180</a></div>
</div>