[openstack-dev] [fuel] Fuel is now an OpenStack project: what's next?
Dmitry Borodaenko
dborodaenko at mirantis.com
Thu Nov 19 08:04:04 UTC 2015
Fuel team,
You've heard the good news. After 4 months of hard work on expanding our
collaboration with other OpenStack projects and aligning our development
and governance processes with the OpenStack project requirements, our
proposal to add Fuel to OpenStack projects [0] was approved by the
Technical Committee.
[0] https://review.openstack.org/199232
This is a huge achievement for Fuel, there's no doubt about that. I'd
like to thank everyone who made this possible. Everyone who runs
technical discussions on openstack-dev, helps our users and contributors
on IRC, represents Fuel in community meetings, meetups, and summits,
removes code duplication between fuel-library and puppet-openstack,
modularizes Fuel components for better reuse outside Fuel, makes Fuel
more distro-independent, those who covered all Fuel repositories with
voting gate jobs -- you all know who you are. You're awesome, you made
it happen, thank you!
This is also a beginning of a much greater journey. We have convinced
the Technical Committee that we are willing and able to operate as an
OpenStack project. Now we get to the hard part: convince the rest of the
community that Fuel is worth contributing to, that we can and we will
support new contributors, that we will remain true to the OpenStack's "4
opens": Open Source, Open Community, Open Development, Open Design.
With all the technical challenges that we need to resolve, the biggest
challenge for Fuel right now remains a social one: we need more people
from different backgrounds, with different needs and different opinions,
to become active participants and eventually core reviewers in Fuel
components.
How do we know when we've fixed the diversity problem? Simple: TC has
defined a diverse-affiliation tag [1] specifically to address this. All
we need is to make it our top priority to invite, encourage, coach, and
promote new contributors until we satisfy this tag's requirements.
[1] http://governance.openstack.org/reference/tags/team_diverse-affiliation.html
I believe this will be an effort well spent. An hour spent coaching a
new contributor who will then contribute many hours worth of effort into
making Fuel better, more flexible and reliable, is more than worth it.
The next big challenge is as much social as it is a technical one. There
are many projects in OpenStack that can benefit greatly from
collaboration with Fuel, and, as our experience collaborating with
Puppet OpenStack project shows, Fuel can benefit just as much from
collaborating with them.
First of all, Infrastructure needs our help. We've just dumped a massive
project in their lap (over 400K lines of code in more than 20 git
repositories), we owe it to them to pull our own weight and help them
deal with increased load of the new gate jobs we've just set up. I've
appointed Aleksandra Fedorova and Igor Belikov as our liaisons to the
Infrastructure team -- not just to look after our own gates, but to
actively look for new ways to improve and integrate.
The investigation of how to run Fuel's deployment tests on nodepool [2]
must continue, and I call other Fuel developers, especially from the QA
team, to join and start making some progress with design and
implementation.
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-November/079284.html
This is not just about making more Fuel compliant with OpenStack
policies, and not just about reducing the diversity of technologies that
Infrastructure project has to deal with. It's about enabling
Infrastructure to support a greater range of multi-node tests across all
OpenStack projects, and building a CI/CD based OpenStack development
workflow around Fuel.
There's more synergy opportunities all over the place. The one we've
known about for a while and should revisit again is expanding Ironic's
flexibility with the image based provisioning capacities of the
fuel-agent. As we look into deploying containerized OpenStack services,
we must work closely with the Kolla project. Making Fuel fully
distro-independent is not going to be possible without help from the RPM
and DEB packaging projects. I'm open for more suggestions, but I think
the above makes a good initial list of collaboration priorities.
Last but not the least, it's time to get back to the plan for aligning
Fuel release schedule with that of OpenStack. We're still in line with
my proposal from August [3], I think we should stick to that and work
closely with Packaging and Puppet projects to make sure we can release
Mitaka based Fuel 9.0 weeks (rather than months) after Mitaka itself is
released. For the n/10.0 release, we should start thinking about
switching completely to the OpenStack release schedule.
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073110.html
I know all this is a tall order, and between it all we still have to
release Liberty based Fuel 8.0 on time, and keep our quality going up,
and keep new features flowing in. I wouldn't ask you this if I didn't
think you could do it. When I look back and consider how far Fuel has
come since it was first released in March 2013, how much it evolved in
terms of architecture flexibility and engineering process maturity, all
I can think of is: we can do anything!
--
Dmitry Borodaenko
More information about the OpenStack-dev
mailing list