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