Open Stack

Fuel Librarians

I would like to nominate myself as a Candidate for Fuel Library Component
Lead position

Let me mention the list of main points I would like to work on. This list
is going to essentially resemble my PTL candidacy item list but it will
also differ from it significantly.

* General Standards of Decision Making

This assumes that each design decision on architecture must be applied
according to the sufficient data and expert analysis performed by subject
matter experts and cold and heartless machines that should run tests and
collect metrics of existing and proposed solutions to figure out the best
solution. Each decision on the new library or tool to choose must be
accompanied by clear report showing that this change actually makes
difference. I will start working on the unified toolchain and methodology
on how to make decisions immediately.

* HA Polishing

This one has always been one of the strongest parts of Fuel and we are
using our own unique and innovative ways of deploying HA architecture.
Nevertheless, we still have many things to work on to make it perfect:

1) Fencing and power management facilities
2) Node health monitoring
3) RabbitMQ clusterer plugin

* Reference Architecture Changes

It seems pretty obvious that our reference architecture requires some
simplification and polishing. We have several key-value storages, we are
using several HTTP servers/proxies and so on.
This makes us support lots of stuff instead of concentrating on a 'golden'
set of tools and utilities and making them work perfectly.
I want to spend significant time on figuring out possible solutions for
redefining of our architecture based on aforementioned principles.

* Quality and Deployment Velocity

Although we are among the only projects who run very extensive set of tests
including for each commit into Fuel Library - we can still work on many
things for perfect QA and CI.
These are:

1) deployment integration tests for all the components, e.g. run deployment
for each deployment-related component like nailgun, nailgun-agent,
fuel-agent, fuel-astute and others
2) significantly increase test coverage: e.g. cover each deployment task
with noop test, increase unit test coverage for all the Fuel-only modules
3) work on the ways of automated generation of test plans for each
particular feature and bugfix including regression, functional, scale,
stress and other types of tests
4) work on the way of introducing more granular tests for fuel deployment
components - we have an awesome framework to get faster feedback, written
by fuel QA team, but we have not yet integrated it into our CI

* Flexibility and Scalability

We have a lot of work to do on orchestration and capabilities of our
deployment engine.

We need to introduce hierarchy for deployment attributes like for the whole
cluster, for racks, for nodes and tasks themselves.

We also need to work on our provisioning scalability parts such as moving
towards iPXE + peer2peer base image distribution.

* Documentation

It seems we have lots of good tools like our devops toolkit, noop tests and
other things. But this info is not available to external contributors and
plugin developers. Even Fuel engineers do not know everything about how
these tools work.  I am going to setup several webinars and write a dozen
of articles on how to develop and test Fuel Library.

* Community

And the last but not least - community collaboration. We are doing great
job while gluing existing deployment libraries and testing their
integration. Community folks like puppet-openstack are also doing great
job. And, instead of duplicating it, I would like to merge with upstream
code as much as possible thus freeing our resources onto the things we do
the best along with sharing the stuff we do the best with community by
testing results of their work against our reference architecture and
installations.

Additionally, it is worth to mention that I envision significant value in
making Fuel able to install current OpenStack trunk code thus allowing us
to set up Fuel CI for each piece of OpenStack and allowing OpenStack
developers to test their code against multi-host HA-enabled reference
architecture in an easy and automated way.

Thank you all for your time and consideration!

-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151014/2df807bb/attachment.html>