[openstack-dev] [fuel] Add Fuel to OpenStack projects: status update
Andrew Woodward
awoodward at mirantis.com
Wed Nov 11 10:29:05 UTC 2015
I didn't read Jim's note as fuel integration tests need to run on OpenStack
infra as reason. To me, it comes across as that we need have a long and
complete conversation with infra about what we are doing in fuel
integration. The deliverables would be: what can be done now in infra, what
does infra want road mapped, built and transitioned to infra at a later
date, and what does infra not want at this time or the near future. As a
follow-up to this meeting I'd guess that some early draft specs and
proposed time lines are in order. In general it seems he wants alignment
and approval from infra on this.
It seems fair ask at this time, AFAICT fuel has the most comprehensive
multinode and HA testing patterns that I'm aware of, leaving this all in
the fuel-ci system seems anti big tent. Not to mention doing so will reduce
our burden to maintain it ourselves.
On Wed, Nov 11, 2015, 12:21 PM Davanum Srinivas <davanum at gmail.com> wrote:
> Dima,
>
> +1 to "additional scrutiny is there because they want to get this
> right. Lets prove that their trust in us is not misplaced."
>
> Thanks,
> Dims
>
> On Tue, Nov 10, 2015 at 10:10 PM, Dmitry Borodaenko
> <dborodaenko at mirantis.com> wrote:
> > 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
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151111/83cffecd/attachment-0001.html>
More information about the OpenStack-dev
mailing list