[openstack-dev] [fuel][ptl] PTL candidacy

Sergii Golovatiuk sgolovatiuk at mirantis.com
Mon Sep 28 21:51:49 UTC 2015


Hi friends,


I’d like to raise my hand to send my candidacy for Fuel PTL position for
next cycle.

Before I go forward with my candidacy, I will remind some facts we’ve been
focuses as a team for last six months:

- Synchronisation with upstream modules. As a result we have a nice
mechanist to synchronise upstream manifests

- Plugin system improvements. We extended our plugin system to allow to
detach components. These changes creates a flexible mechanism for plugin
developers.

- HA Improvements. Fuel team polished OCF scripts. QA engineers automated a
lot of scenarios of our high availability architecture.

- Breaking Fuel to components. fuel-qa, fuel-agent and other components
were moved to own repositories. That increased the velocity of component
development.

- Fuel repositories. Fuel team implemented online repositories for
distribution system it supports. This allowed to speed up the update
delivery.

- Granular deployment. Instead of single ‘puppet apply’ fuel has a lot of
small applies. This step speed up the development process as the developer
doesn’t need to wait for whole deployment. He may apply only ‘required’
task. This flexibility gives a lot of room for plugin developers.


I believe there are some of the most important topics that our team should
focus on:

With my deployer/operator hat on:


- Continue breaking Fuel monolith to components. This will allow to
increase the velocity of product development. A good candidate is fuel-web.
There are some other projects that can be moved to own repositories.

- Switching to fuel2 CLI. We should finally deprecate first version of CLI.
fuel2 which is based on cliff should be a main tool for operator.

- Implement integration testing. Fuel is suffering from lack of integration
testing. This means that state of processes are not ensured after
deployment. Also, I am going to spend time to introduce code coverage
metrics that will be used for analysing if coverage is getting better or
not.

- CI improvements. Fuel is suffering from slow gates. ISO compilation,
master node deployment, openstack deployment require more and more time.
Reducing CI time will speed up the development process. I believe we should
start with metrics so we’ll know how much time is required from code to
deployed openstack. So, we’ll iteratively improve the bottle necks. In the
end, Developer will require less time for CI.

- Improve collaboration with Puppet OpenStack community. This part was
started as simple synchronisation of community manifests. A couple of
cycles we contributed a lot of bug fixes. In the end, Fuel team implemented
a nice mechanism that allows us to consume openstack-puppet modules without
any modifications. However, we are still in process of migration. It should
be done within next 6 months.

- Documentation improvements. I believe that documentation improvement will
allow to minimise the barrier for new contributors. I am going to add more
samples and details to our development documentation. A good sample is
puppetlabs-stdlib [1]

[1] https://github.com/puppetlabs/puppetlabs-stdlib

>From other hand, Fuelers have a lot of knowledge in OpenStack which should
be contributed back to upstream. I believe HA experience should contributed
back to upstream.

- Lifecycle improvements. I am going to make a paradigm shift that Fuel is
not only deployment tool. It’s very useful for lifecycle management.

With my leader hat on:

- Implementing lieutenant based model. Fuel Core developers are overloaded
with reviews. Switching to lieutenant model should free up their time that
can be spent on some R&D. [2]

[2]
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg62229.html

- The last but not least. I’ll do all my the best to get Fuel under Big
Tent.

I have many many things in my backlog. However, I believe the above are the
most important. I believe that resolving these issues will speed up the
velocity of development and make a cultural shift with many external
contributions.

Sincerely yours,

Sergii Golovatiuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150928/8ae3f446/attachment.html>


More information about the OpenStack-dev mailing list