<div dir="ltr">Fuelers<div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>And so far I want to nominate myself for PTL position of Fuel project to be able to lead the project towards its perfection. <br></div><div><br></div><div>I would like to outline the major points I am going to work on during this half-year cadence</div><div><br></div><div>* General Standards of Decision Making (Meritocracy and Cold Numbers)</div><div><br></div><div>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.</div><div><br></div><div><div>* HA Polishing (Finish It!)</div></div><div><br></div><div>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:</div><div><br></div><div>1) Fencing and power management facilities</div><div>2) Event-based cluster management and disaster handling</div><div>3) Node health monitoring</div><div>4) Many-many others</div><div><br></div><div>* Reference Architecture Changes (Simplicity and Focus on What Matters The Most)</div><div><br></div><div>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.</div><div>This makes us support lots of stuff instead of concentrating on a 'golden' set of tools and utilities and making them work perfectly.</div><div>I want to spend significant time on figuring out possible solutions for redefining of our architecture based on aforementioned principles.</div><div><br></div><div>* Quality and Deployment Velocity (CI and QA improvements)<br></div><div><br></div><div>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.</div><div>These are:</div><div><br></div><div>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</div><div>2) significantly increase test coverage: e.g. cover each deployment task with noop test, increase unit test coverage for all the Fuel-only modules</div><div>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></div><div>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</div><div><br></div><div>* Flexibility and Scalability (Plugin Development and User Experience)</div><div><br></div><div>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.</div><div><br></div><div>We need to think how to make regular cluster operations less invasive.</div><div><br></div><div>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.</div><div><br></div><div>We also need to work on our provisioning scalability parts such as moving towards iPXE + peer2peer base image distribution.</div><div><br></div><div>* Documentation (Make It Clear)<br></div><div><br></div><div>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. </div><div><br></div><div>* Community (Unleash The Monster of Synergy)<br></div><div><br></div><div>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.</div><div><br></div><div>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></div><div><br></div><div>* Conclusion</div><div><br></div><div><div>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.<br></div><div><br></div><div>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. </div><div><br></div><div>Remember, as Red Queen said: "<span style="color:rgb(37,37,37);font-family:sans-serif;font-size:14px;line-height:22.3999996185303px">you must run at least twice as fast as that!</span>"</div><div><br></div><div>Thank you all for your time and consideration!</div><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr">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/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div></div>