<p dir="ltr">Fuel Librarians</p>
<p dir="ltr">I would like to nominate myself as a Candidate for Fuel Library Component Lead position</p>
<p dir="ltr">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.</p>
<p dir="ltr">* General Standards of Decision Making</p>
<p dir="ltr">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.</p>
<p dir="ltr">* HA Polishing</p>
<p dir="ltr">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:</p>
<p dir="ltr">1) Fencing and power management facilities<br>
2) Node health monitoring<br>
3) RabbitMQ clusterer plugin</p>
<p dir="ltr">* Reference Architecture Changes</p>
<p dir="ltr">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.<br>
This makes us support lots of stuff instead of concentrating on a 'golden' set of tools and utilities and making them work perfectly.<br>
I want to spend significant time on figuring out possible solutions for redefining of our architecture based on aforementioned principles.</p>
<p dir="ltr">* Quality and Deployment Velocity</p>
<p dir="ltr">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.<br>
These are:</p>
<p dir="ltr">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<br>
2) significantly increase test coverage: e.g. cover each deployment task with noop test, increase unit test coverage for all the Fuel-only modules<br>
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<br>
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</p>
<p dir="ltr">* Flexibility and Scalability</p>
<p dir="ltr">We have a lot of work to do on orchestration and capabilities of our deployment engine. </p>
<p dir="ltr">We need to introduce hierarchy for deployment attributes like for the whole cluster, for racks, for nodes and tasks themselves.<br></p>
<p dir="ltr">We also need to work on our provisioning scalability parts such as moving towards iPXE + peer2peer base image distribution.</p>
<p dir="ltr">* Documentation</p>
<p dir="ltr">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. </p>
<p dir="ltr">* Community</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.<br><br></p>
<p dir="ltr">Thank you all for your time and consideration!<br></p>
<p dir="ltr">-- <br>
Yours Faithfully,<br>
Vladimir Kuklin,<br>
Fuel Library Tech Lead,<br>
Mirantis, Inc.<br>
+7 (495) 640-49-04<br>
+7 (926) 702-39-68<br>
Skype kuklinvv<br>
35bk3, Vorontsovskaya Str.<br>
Moscow, Russia,<br>
<a href="http://www.mirantis.ru/">www.mirantis.com</a><br>
<a href="http://www.mirantis.ru/">www.mirantis.ru</a><br>
<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a></p>