openstack/election
Code Issues Proposed changes

adding Andrew Woodward candidacy for Fuel

Browse Source 
Change-Id: Ie243e18efe7b883792b890d48d46ab692e427008
This commit is contained in:
Andrew Woodward 2016-03-14 16:25:31 -07:00
parent c0f7aade5a
commit 225514cc11
1 changed files with 73 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
candidates/newton/Fuel/Andrew_Woodward.txt Normal file
View File

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