Adding Alexey Shtokolov candidacy for Fuel
Change-Id: I9a3cdae9a15e5cbb25d88f2c8a7777a5591ec7ad
This commit is contained in:
Alexey Shtokolov
parent
d2da6b3721
commit
9f22934827
118
candidates/ocata/Fuel/ashtokolov.txt
Normal file
118
candidates/ocata/Fuel/ashtokolov.txt
Normal file
@ -0,0 +1,118 @@
|
|||||||
|
I would like to announce my candidacy for Fuel PTL in the Ocata cycle.
|
||||||
|
|
||||||
|
|
||||||
|
** Introduction **
|
||||||
|
|
||||||
|
First of all, allow me to introduce myself. I joined the OpenStack Community
|
||||||
|
during the Juno release cycle. I started on a "consumer" side - as a Head of
|
||||||
|
IT at a media holding I was consuming and bringing Open Source technologies
|
||||||
|
to an "Enterprise world" as much as it was possible and OpenStack was there
|
||||||
|
as well. I had been investigating OpenStack and finally deployed my first
|
||||||
|
private cloud manually. It was Juno 2014.2 and it was a very-very long trip.
|
||||||
|
Half a year later I found out that Fuel could do it much more faster! I liked
|
||||||
|
Fuel mission, both stated and delivered - make OpenStack installation process
|
||||||
|
easier and more streamlined. OpenStack was in a serious need of such a tool,
|
||||||
|
as one of prerequisites for lowering adoption barriers.
|
||||||
|
|
||||||
|
Finally, I joined Fuel Community as a deployment engineer. Since 2015 I've
|
||||||
|
been an active contributor in the very core features of Fuel and have been
|
||||||
|
leading a Fuel development team [0] at Mirantis. If you're using or developing
|
||||||
|
Fuel - you’ve probably heard of some of the features that we designed and
|
||||||
|
implemented:
|
||||||
|
Task-based deployment engine [1], Post-deployment plugins installation,
|
||||||
|
Deployment History [2][3], Data-driven orchestration [4] with Unlocked
|
||||||
|
Settings and Network tabs [5] (aka Fuel LCM), Custom graphs execution [6],
|
||||||
|
Release-as-a-Plugin [7] and Everything-as-a-Graph [8].
|
||||||
|
|
||||||
|
As you can see, the main goal of this work was to make Fuel more flexible and
|
||||||
|
friendly for deployment engineers, based on my and my colleagues’ experience
|
||||||
|
from real OpenStack deployments. And I would like to keep doing it
|
||||||
|
as a Fuel PTL.
|
||||||
|
|
||||||
|
|
||||||
|
** Community **
|
||||||
|
|
||||||
|
Fuel, as a part of OpenStack BigTent since November 17 2015, had the first
|
||||||
|
design summit at Austin. Vladimir Kozhukalov did a great job organizing it.
|
||||||
|
This summit allowed Fuel community to solicit a feedback, to align our goals
|
||||||
|
with OpenStack community and, the most important, to start having an open
|
||||||
|
design. Open Design was the last of four Opens [9] to be achieved by Fuel
|
||||||
|
Community. Unfortunately during the Newton release cycle not all discussions
|
||||||
|
and decisions were open and public enough. We need to avoid such behaviour
|
||||||
|
in future. Fuel Community will have a very modest representation during
|
||||||
|
upcoming Fuel Ocata Design summit at Barcelona and the first Project Teams
|
||||||
|
Gathering [10] And that’s the reason to make our goal #1: the expansion of
|
||||||
|
the OpenStack Community involvement into Fuel design during the whole release
|
||||||
|
cycle. And as a result encourage new contributors, build a healthy community
|
||||||
|
around Fuel and achieve the contribution diversity.
|
||||||
|
|
||||||
|
|
||||||
|
** Technical challenges **
|
||||||
|
|
||||||
|
October 2015 Fuel was the 5th deployment tool for OpenStack with 12% [11]
|
||||||
|
but April 2016 Fuel got the 3rd place with 19% [12] right after Puppet and
|
||||||
|
Ansible. While SaltStack, Chef and Puppet are visibly going down Fuel is
|
||||||
|
taking over the OpenStack deployment world. But we still have a set of
|
||||||
|
technical challenges and we must focus on:
|
||||||
|
|
||||||
|
* Infrastructure-as-Code (IaC) allows us to provide convenient and familiar UX
|
||||||
|
for those user who have experience with dynamic infrastructure in Public
|
||||||
|
clouds - it's now easy to control OpenStack configuration and versioning via
|
||||||
|
git. Since nailgun extension for IaC [13] became a part of Fuel project [14]
|
||||||
|
we should actively support and develop it.
|
||||||
|
|
||||||
|
* Lifecycle management. Making changes on already installed clouds is still
|
||||||
|
complicated. We’ve done a lot of work in this direction, but we are still not
|
||||||
|
there.
|
||||||
|
|
||||||
|
* The Upgrades of Fuel itself and OpenStack clusters managed by Fuel still
|
||||||
|
need more flexibility and much better UX. We can fix it using the custom
|
||||||
|
graphs concept [8].
|
||||||
|
|
||||||
|
* Fuel extensions and plugins framework should be polished and provide itself
|
||||||
|
with stable API. Moreover extensions and plugins SDK should become
|
||||||
|
developer-friendly and support all new features like release-as-a-plugin [7].
|
||||||
|
|
||||||
|
* Single Fuel Master node should support multiple different OpenStack releases.
|
||||||
|
First step [7] was done. Let’s keep moving.
|
||||||
|
|
||||||
|
* Audit, troubleshooting and debugging became easier with Deployment History
|
||||||
|
features and dry-run/noop deployments but we are still facing with the
|
||||||
|
inconsistent error reporting and diagnostic snapshots. We can improve it using
|
||||||
|
graphs.
|
||||||
|
|
||||||
|
* Documentation team has done a great job of restructuring Fuel documentation
|
||||||
|
and moving it under OpenStack Doc space. However, as subject matter experts,
|
||||||
|
we need to proactively review and help the doc team with updates and new
|
||||||
|
features documentation [15]
|
||||||
|
|
||||||
|
|
||||||
|
** Afterword **
|
||||||
|
|
||||||
|
As an epilogue I would like to say: Working closely with OpenStack Community
|
||||||
|
I see that PTL is more about how to help people come together and achieve
|
||||||
|
goals, how to built horizontal communications between project teams and how
|
||||||
|
to keep developers in their zone of maximum performance.
|
||||||
|
|
||||||
|
Fuel is a mature project with existing strong development team. And we should
|
||||||
|
keep these things in place.
|
||||||
|
|
||||||
|
WBR, Alexey Shtokolov
|
||||||
|
irc: ashtokolov
|
||||||
|
|
||||||
|
[0] https://launchpad.net/~fuel-toolbox/+members
|
||||||
|
[1] https://specs.openstack.org/openstack/fuel-specs/specs/8.0/task-based-deployment-mvp.html
|
||||||
|
[2] https://specs.openstack.org/openstack/fuel-specs/specs/9.0/store-deployment-tasks-history.html
|
||||||
|
[3] https://specs.openstack.org/openstack/fuel-specs/specs/9.0/save-deployment-info-in-database.html
|
||||||
|
[4] https://specs.openstack.org/openstack/fuel-specs/specs/9.0/tasks-computable-fields-with-yaql.html
|
||||||
|
[5] https://specs.openstack.org/openstack/fuel-specs/specs/9.0/unlock-settings-tab.html
|
||||||
|
[6] https://specs.openstack.org/openstack/fuel-specs/specs/9.0/execute-custom-graph.html
|
||||||
|
[7] https://specs.openstack.org/openstack/fuel-specs/specs/10.0/release-as-a-plugin.html
|
||||||
|
[8] https://specs.openstack.org/openstack/fuel-specs/specs/10.0/graph-concept-extension.html
|
||||||
|
[9] https://governance.openstack.org/reference/opens.html
|
||||||
|
[10] http://www.openstack.org/ptg
|
||||||
|
[11] http://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf Page 26
|
||||||
|
[12] https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf Page 37
|
||||||
|
[13] https://github.com/openstack/fuel-nailgun-extension-iac
|
||||||
|
[14] https://review.openstack.org/#/c/366779/ https://review.openstack.org/#/c/366780/
|
||||||
|
[15] http://stackalytics.com/report/contribution/fuel-docs/180
|
||||||
Loading…
x
Reference in New Issue
Block a user