Open Stack

Fuelers

I am glad that Fuel is becoming more open as a project and is heading
towards Openstack BigTent which should allow our project to scale and
become one of the default OpenStack installers not only for a fraction of
end users but for a significant amount of OpenStack developers also.
Although Fuel is a fairly good toolchain, that allows you to set up a
cluster in a production-ready way, there is still a room for improvement as
we need to work on many things to scale to thousand of deployed nodes,
allow plugin developers to alter deployment workflow and input data in the
way the want and improve many other things which are still not the best in
the industry.

And as a someone who has been working on this project since its very
beginning, leading (which was very tiny several first months) so-called
Fuel Library team and working on all the deployment components I am very
familiar with all the existing issues we need to address in the first
place.

And so far I want to nominate myself for PTL position of Fuel project to be
able to lead the project towards its perfection.

I would like to outline the major points I am going to work on during this
half-year cadence

* General Standards of Decision Making (Meritocracy and Cold Numbers)

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 (Finish It!)

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) Event-based cluster management and disaster handling
3) Node health monitoring
4) Many-many others

* Reference Architecture Changes (Simplicity and Focus on What Matters The
Most)

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 (CI and QA improvements)

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) 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 (Plugin Development and User Experience)

We have a lot of work to do on orchestration and capabilities of our
deployment engine. We still need to think of how to apply fixes easily onto
already deployed environments, how to parallelize deployment on different
nodes as it takes more and more time when we have more roles in the cluster.

We need to think how to make regular cluster operations less invasive.

We need to work on ability to document and standardize all the interactions
between various components of Fuel, such as Nailgun and Fuel-Library. There
are many roadblocks in Nailgun which we need to get rid of and make all as
data-driven as possible allowing plugin developers an regular users to
alter deployment in the way the want by introducing.

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

* Documentation (Make It Clear)

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.

* Community (Unleash The Monster of Synergy)

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.

* Conclusion

I am sure that going this way will make our project better and ramp up our
project quality and growth significantly, allow us to finally join Big Tent
and become the default most effective and easy-to-use installer and manager
of OpenStack clouds.

I will be happy to lead Fuel project during this cadence with this pretty
consistent and wide platform. It seems a little bit ambitious and not so
simple to implement it - but I expect help from Component Leads for
Fuel-Library and Fuel-Python as well as yours.

Remember, as Red Queen said: "you must run at least twice as fast as that!"

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/20150928/540d92a5/attachment.html>