[openstack-dev] [fuel] Plan to implement the OpenStack Testing Interface for Fuel

Boris Pavlovic boris at pavlovic.me
Sat Jul 18 20:48:29 UTC 2015


Am I missing any major risks or additional requirements here?

Syncing requirements with global openstack requirements can produce issues,
that requires changes in code.

I would strongly recommend to sync requirements by hand and test
everything before starting splitting repos and adding openstack-ci jobs.

-1 risk.

Best regards,
Boris Pavlovic

On Sat, Jul 18, 2015 at 12:16 AM, Dmitry Borodaenko <
dborodaenko at mirantis.com> wrote:

> One of the requirements for all OpenStack projects is to use the same
> Testing
> Interface [0]. In response to the Fuel application [1], the Technical
> Committee
> has clarified that this includes running gate jobs on the OpenStack
> Infrastructure [2][3].
> [0]
> http://governance.openstack.org/reference/project-testing-interface.html
> [1] https://review.openstack.org/199232
> [2]
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-07-14-20.02.log.html#l-150
> [3] https://review.openstack.org/201766
> Although the proposed formal requirement could use some clarification,
> according to the meeting log linked above, TC has acknowledged that
> OpenStack
> Infrastructure can't currently host deployment tests for projects like
> Fuel and
> TripleO. This narrows the requirement down to codestyle checks, unit tests,
> coverage report, source tarball generation, and docs generation for all
> Python
> components of Fuel.
> As I mentioned in my previous email [4], we're days away from Feature
> Freeze
> for Fuel 7.0, so we need to plan a gradual transition instead of making the
> testing interface a hard requirement for all repositories.
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069906.html
> I propose the following stages for transition of Fuel CI to OpenStack
> Infrastructure:
> Stage 1: Enable non-voting jobs compliant with the testing interface for a
> single Python component of Fuel. This has no impact on Fuel schedule and
> should
> be done immediately. Boris Pavlovic has kindly agreed to be our code fairy
> and
> magicked together a request that enables such jobs for nailgun in fuel-web
> [5].
> [5] https://review.openstack.org/202892
> As it turns out, OpenStack CI imposes strict limits on a project's
> directory
> structure, and fuel-web doesn't fit those since it contains a long list of
> components besides nailgun, some of them not even in Python. Making the
> above
> tests pass would involve a major restructuring of fuel-web repository,
> which
> once again is for now blocked by the 7.0 FF. We have a blueprint to split
> fuel-web [6], but so far we've only managed to extract fuel-agent, the rest
> will probably have to wait until 8.0.
> [6] https://blueprints.launchpad.net/fuel/+spec/split-fuel-web-repo
> Because of that, I think fuel-agent is a better candidate for the first
> Fuel
> component to get CI jobs on OpenStack Infrastructure.
> Stage 2: Get the non-voting jobs on the first component to pass, and make
> them
> voting and gating the commits to that component. Assuming that we pick a
> component that doesn't need major restructuring to pass OpenStack CI, we
> should
> be able to complete this stage before 7.0 soft code freeze on August 13
> [7].
> [7] https://wiki.openstack.org/wiki/Fuel/7.0_Release_Schedule
> Stage 3: Enable non-voting jobs for all other Python components of Fuel
> outside
> of fuel-web. We will have until 7.0 GA release on September 24, and we
> won't be
> able to proceed to following stages until 7.0 is released.
> Stage 4: Everything else that is too disruptive for 7.0 but doesn't require
> changes on the side of OpenStack Infrastructure can all start in parallel
> after
> Fuel 7.0 is released:
> a) Finish splitting fuel-web.
> b) Get all Python components of Fuel to pass OpenStack CI.
> c) Set up unit test gates for non-Python components of Fuel (e.g.
> fuel-astute).
> d) Finish the transition of upstream modules in fuel-library to librarian.
> e) Set up rspec based gates for non-upstream modules in fuel-library.
> I think completing all these can be done by 8.0 SCF in December, and if
> not,
> must become a blocker requirement for 9.0 (Q3 2016).
> Stage 5: Bonus objectives that are not required to meet TC requirements for
> joining OpenStack, but still achievable based on current state of OpenStack
> Infrastructure:
> a) functional tests for Fuel UI
> b) beaker tests for non-upstream parts of fuel-library
> Stage 6: Stretch goal for the distant future is to actually make it
> possible to
> run multi-node deploy tests on OpenStack Infrastructure. I guess we can at
> least start that discussion in Tokyo...
> Am I missing any major risks or additional requirements here? Do the dates
> make
> sense?
> Thanks,
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150718/8d7ff716/attachment.html>

More information about the OpenStack-dev mailing list