[openstack-dev] [fuel] Add Fuel to OpenStack projects: status update
Dmitry Borodaenko
dborodaenko at mirantis.com
Wed Nov 11 03:10:30 UTC 2015
As you may have guessed, many Fuel developers were holding their breath
for the Technical Committee meeting today, where the decision on whether
to accept Fuel into Big Tent as an OpenStack project [0] was on the
agenda [1].
[0] https://review.openstack.org/199232
[1] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-11-10-20.02.log.html#l-115
Unfortunately, we'll have to hold breath for another week: our proposal
was not approved today, and the vote was postponed again. The good news
is, most of the TC members present were in favor and have acknowledged
that Fuel team has made significant progress in the right direction.
The remaining objections are not new and not insurmountable: Jim Blair
has pointed out that it's not enough to have _most_ of Fuel repositories
covered by PTI compliant gate jobs, it has to be _all_ of them, and that
we still have a few gaps. Thierry was willing to let us get away with a
commitment that we complete this work by the end of the year, or be
removed from the projects if we fail. However, Jim's concerns were
seconded by Russel Bryant and Mark McClain who explicitly abstained
until, in Russel's words, "the Infra team is happy". Without their votes
and with 4 more TC members absent from the meeting, our proposal did not
get enough votes to pass.
I have documented the specific gaps in the gate jobs in my comment to
the governance review linked above. To sum up, what's left to bring Fuel
into full compliance with PTI is:
1) Enable the currently non-voting gate jobs for the new repositories
extracted from fuel-web last week: fuel-menu, network-checker, shotgun.
2) Fix and enable the failing docs jobs in fuel-astute and fuel-docs.
3) Finish the unit test job for fuel-ostf.
4) Set up Ruby unit tests and syntax checks for fuel-astute and
fuel-nailgun-agent.
While figuring out some of the job failures here is tricky, I believe we
should focus on remaining gaps and close all of them soon. It would be a
shame to have come this far and have our proposal rejected because of a
missing syntax check or a failure to compile HTML from RST.
Jim's request to start work on running the more complex tests
(specifically, multi-node deployment tests from fuel-qa) turned out to
be more controversial, both because it is a new requirement that was
explicitly excluded during the previous round of discussions in July,
and because it's hard to objectively assess how much work, short of
complete implementation and full conversion, would be enough to prove
that there is a sufficient collaboration between Fuel and Infrastructure
teams.
We had a good opening discussion on #openstack-dev about this after the
TC meeting [2]. Aleksandra Fedorova has mentioned that she actually
proposed a talk for Tokyo about exactly this topic (which was
unfortunately rejected), and promised to kick off a thread on
openstack-dev ML based on the research she has done so far. It's a
worthwhile long-term goal, I completely understand Infra team's desire
to make sure Fuel project can pull its own weight on OpenStack Infra,
and I will support efforts by Aleksandra and other Fuel Infra engineers
to fully align our CI with OpenStack Infra.
[2] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2015-11-10.log.html#t2015-11-10T21:03:34
Still, I believe that making this a hard requirement for Fuel's
acceptance into Big Tent would be one step too far down a slippery slope
into a whole new vat of worms. Objective inclusion criteria such as
Project Requirements and Project Testing Interface are there to protect
OpenStack contributors from real and perceived favouritism. Declaring,
especially selectively, that meeting these criteria may be insufficient,
takes all the objectivity out of them. Fortunately, Jim did not insist
on making progress with Fuel multi-node tests a hard requirement and
confirmed that he will not block our proposal based on that. He still
wants us to finish setting up gates, though, fair is fair.
Finally, the odd one out was the objection from Dean Troyer: "re Fuel,
I'm just not convinced it fits OpenStack's mission... we generally have
stayed away from being a distro". It was quickly dismissed by other
participants, but Dean still abstained, putting us one more vote short
of approval. I think this serves to illustrate that many prominent
members of OpenStack community still view Fuel as an OpenStack
distribution, even after the two years we've spent establishing Fuel as
a toolset for deployment and operation of OpenStack environments,
decoupled from whatever Linux and OpenStack distributions you choose to
deploy with it. I can only hope that Fuel is accepted into Big Tent and
more distributions are encouraged to use it, so that this particular
confusion is finally laid to rest.
Some of you may be surprised by how much scrutiny Fuel is facing when
compared to smaller and younger projects. In a way, Fuel is a victim of
its own success: we've got so many components and such an extensive and
diverse CI coverage that bringing all that into compliance with The
OpenStack Way is really that much more work than it is for a typical new
project with just one git repo and a handful of unit test jobs. Don't be
discouraged by this additional delay: Fuel is big and has a lot of value
to bring into OpenStack on many levels, Technical Committee is
appreciative of that and supportive of our efforts, additional scrutiny
is there because they want to get this right. Lets prove that their
trust in us is not misplaced.
--
Dmitry Borodaenko
More information about the OpenStack-dev
mailing list