<div dir="ltr"><div class="gmail_default" style=""><div class="gmail_default">Hi all,</div><div class="gmail_default"><br></div><div class="gmail_default">I'd like to announce my candidacy to be Fuel PTL for the Newton cycle.</div><div class="gmail_default">I've been a member of Fuel team since the very beginning of the project.</div><div class="gmail_default">Fuel started as a proprietary deployment tool for OpenStack, but since</div><div class="gmail_default">that we have been smothly moving towards being more and more open and</div><div class="gmail_default">more and more community oriented. In the beginning of Mitaka cycle Fuel</div><div class="gmail_default">was approved to become an official OpenStack project under Big Tent.</div><div class="gmail_default">But being an offcial project is not enough. 95% of Fuel contributions</div><div class="gmail_default">during Mitaka are from Mirantis [1].</div><div class="gmail_default"><br></div><div class="gmail_default">Fuel is huge and it is hard for companies and individuals to catch</div><div class="gmail_default">tendencies in Fuel project and thus it is hard for them to decide how,</div><div class="gmail_default">what and why they could contribute. One of the biggest problems I see is</div><div class="gmail_default">Fuel is not modular enough.</div><div class="gmail_default"><br></div><div class="gmail_default">Some Fuel components have already been brought out of Fuel and now they</div><div class="gmail_default">are fully independent. These are Bareon and Packetary. Bareon is a fork of</div><div class="gmail_default">Fuel-agent and is to become a generic OS provisioning tool. It already has</div><div class="gmail_default">third party contributions. Fuel is to switch to Bareon in Newton cycle.</div><div class="gmail_default">Packetary is a former part of Fuel-mirror. It is to become a generic tool</div><div class="gmail_default">to deal with DEB and RPM repositories and packages, so its use case</div><div class="gmail_default">is much broader than Fuel.</div><div class="gmail_default"><br></div><div class="gmail_default">Some current Fuel components are quite generic and thus they could</div><div class="gmail_default">be brought out of Fuel project. For example, Shotgun is a tool for</div><div class="gmail_default">collecting log files and commands output from an environment, but this</div><div class="gmail_default">functionality could potentially be useful for other projects.</div><div class="gmail_default">The same is about Network-checker.</div><div class="gmail_default"><br></div><div class="gmail_default">Some Fuel components strictly depend on Fuel but their purpose is generic.</div><div class="gmail_default">We could put some efforts to make these components fully data driven and</div><div class="gmail_default">thus expand their use case. For example, Fuel-menu is a tool that provides</div><div class="gmail_default">user configuration dialog. Why should it be Fuel specific? Could we make it</div><div class="gmail_default">data driven and expand its use case? The same is about Fuel-virtualbox, which</div><div class="gmail_default">is just a set of configurable shell scripts that could be used for non-Fuel</div><div class="gmail_default">virtualbox environments. Fuel-ostf also could be potentially used out of Fuel.</div><div class="gmail_default"><br></div><div class="gmail_default">Some Fuel components could potentially be substituted with generic community</div><div class="gmail_default">tools. For example, Fuel-nailgun-agent is a discovery/inventory tool.</div><div class="gmail_default">Ironic-inspector does the same. Ironic itself could be used as a power</div><div class="gmail_default">management tool. Perhaps Neutron could be used for network allocation and</div><div class="gmail_default">configuration. Anyway, we should put more efforts in integrating with</div><div class="gmail_default">other OpenStack projects (i.e. avoid duplicating code as well as functionality). </div><div class="gmail_default"><br></div><div class="gmail_default">Besides, Fuel development process is feature driven. Contributors are</div><div class="gmail_default">encouraged to merge changes that implement a feature but they are not</div><div class="gmail_default">encouraged to think of how maintainable that change is and how it is</div><div class="gmail_default">related to the component architecture. Last couple cycles we suffered a lot</div><div class="gmail_default">when many features were to be merged by feature freeze. There were many feature</div><div class="gmail_default">freeze exceptions, we merged features that had not been tested well.</div><div class="gmail_default"><br></div><div class="gmail_default">My suggestion for Newton cycle is to switch from feature driven approach</div><div class="gmail_default">to component driven. All components should have dedicated teams that should plan</div><div class="gmail_default">components road map taking into account not only feature requests but also tech</div><div class="gmail_default">debt and components architecture. It is better when people are focused on their</div><div class="gmail_default">particular field like REST API, network configuration, OS provisioning, etc.</div><div class="gmail_default">That is going to make feature planning more predictable, help to avoid feature</div><div class="gmail_default">freeze rush and increase the quality of code. Component teams </div><div class="gmail_default">should also be responsible for thorough test coverage </div><div class="gmail_default">(including functional and system/integration tests) and for </div><div class="gmail_default">promotion of their components.</div><div class="gmail_default"><br></div><div class="gmail_default">If we make Fuel components as much independent and generic as</div><div class="gmail_default">possible, that will help us to expand component use cases and thus</div><div class="gmail_default">to to attract third party contributors.</div><div class="gmail_default"><br></div><div class="gmail_default">My primary goals for Newton cycle are:</div><div class="gmail_default">1) Switch to component driven development approach</div><div class="gmail_default">   (i.e. by-component teams, by-component releases)</div><div class="gmail_default">2) Introduce by-component and cross-component functional testing</div><div class="gmail_default">3) Attract third party contributors, so they contribute at least 10%</div><div class="gmail_default"><br></div><div class="gmail_default">There are lots of things that I'd like to be implemented (integrating with</div><div class="gmail_default">OpenStack packaging, UEFI support, torrent based OS provisioning,</div><div class="gmail_default">OpenStack deployment from source code, power management, LCM, etc.)</div><div class="gmail_default">but I'm going to rely on component teams opinions in such particular fields.</div><div class="gmail_default"><br></div><div class="gmail_default">Thanks for reading. If you like the plan, please vote.</div><div class="gmail_default"><br></div><div class="gmail_default">[1] <a href="http://stackalytics.com/?module=fuel-group&metric=commits">http://stackalytics.com/?module=fuel-group&metric=commits</a></div></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
</div>