<div dir="ltr"><div>I would like to announce my candidacy to run as PTL for the Fuel project</div><div>during the Newton cycle. Over the Mitaka cycle the Fuel project has</div><div>accomplished a lot ranging from joining Big-tent, to reducing code</div><div>duplication in puppet-openstack to increased collaboration with other</div><div>projects.</div><div><br></div><div>Going forward, I'd like to help drive Fuel to continue to be a community</div><div>focused OpenStack installer. To further this I want to focus the project on:</div><div><br></div><div>* Plugins as first class citizen. Fuel plugins have been a success by many</div><div>measures [0], but there are still many things that can only be done in Fuel's</div><div>core. To help remove these barriers, I would continue to push for more</div><div>interfaces to be in the scope of plugins (releases, and serializers, network</div><div>scheme) and at the same time move the core implementations to plugins. This</div><div>will put plugin interfaces into the primary concern for implementation and</div><div>prevent it from being an after thought. The result will greatly increase the</div><div>flexibility of the plugins interfaces as well as ensure heaver testing. In</div><div>the end, there should be no difference in functionality for a plugin</div><div>developed as part of the core product or by others.</div><div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html">http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html</a></div><div><br></div><div>* Community collaboration. We've really stepped up here already. We've moved</div><div>from being effectively duplicate, hard-fork of the puppet-openstack project</div><div>to removal of code duplication, to heavy participation. Going forward, we</div><div>need to continue towards tight-integration in puppet-openstack and increase</div><div>participation with other projects, such as openstack-resource-agents, infra,</div><div>and others.</div><div><br></div><div>* Fuel community. We have an open community, and even downstreams, such as</div><div>OPNFV[1]. While we have lots of documentation and awesome operations guides,</div><div>we still have development areas that comprise of tribal knowledge. We have areas such as documenting API changes from version to version (Nailgun and</div><div>Plugin APIs) where we completely fall down on. We need to work to clarify</div><div>and document these areas with a special focus to on-boarding new developers.</div><div>At the same time we need to also improve processes that we have already</div><div>defined, such as design and spec approval so that we can both enhance</div><div>on-boarding and minimize release risks such as FFE.</div><div><br></div><div>[1]<a href="https://wiki.opnfv.org/fuel_opnfv">https://wiki.opnfv.org/fuel_opnfv</a></div><div><br></div><div>* Day 2 support: Life cycle management. In the Newton cycle we will need to</div><div>focus heavily on operations besides initial deployment, these so called</div><div>"day 2 operations" or "life cycle management". This focus on managing</div><div>deployed OpenStack clusters will greatly enhance the usefulness of fuel as</div><div>well as better take advantage of the underlying systems to manage a deployed</div><div>environment.</div><div><br></div><div>* Unlocking Fuel for downstream and customization. Over the course of the</div><div>development of Fuel, we have tended to limit certain actions because we don't</div><div>want to address either the complication tied to this, or don't have the</div><div>resources to test it enough to be confident with afore mentioned</div><div>complications. However when this happens, we tend to limit this in a</div><div>hard-coded capacity. This in turn creates restrictions that limit users and</div><div>downstreams alike that are willing, or capable of addressing (or accepting)</div><div>these implications. To this end I want to drive preventing the creation of</div><div>new hard-restrictions, and the driving design that allows for these to be</div><div>customized when desired.</div><div><br></div><div>* CI performance and reliability. While we have a complex and thorough CI</div><div>system for testing Fuel, we still have gaps, mostly due to execution timing,</div><div>and less often, due to reliability. I'd like to see increased focus on</div><div>granular execution of tests and the reuse of already tested artifacts. This</div><div>should help with performance as it would reduce the test set to the minimal</div><div>necessary to cover the change. For example we can drop a number of the python</div><div>fuel projects (fuel-web) from running full deployment tests (2.5-3 hrs), if</div><div>instead we properly validated the data in something like Noop which currently</div><div>takes less than half the time to run (1.2 hours). At the same time a more</div><div>granular scope of testing will lead to increased precision of floating</div><div>failures. I would still drive more focus on isolating and resolving a number</div><div>of floating issues like those that plague fuel-web so that we can increase</div><div>developer velocity.</div><div><br></div><div>Thanks for your consideration, and I look forward to being your PTL in Newton.</div><div><br></div><div><a href="https://review.openstack.org/292642">https://review.openstack.org/292642</a><br></div><div><br></div><div><br></div></div><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">--</p><p dir="ltr"><span style="font-size:13.1999998092651px">Andrew Woodward</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Mirantis</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Fuel Community Ambassador</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Ceph Community</span></p>
</div>