[openstack-dev] [fuel] Plan to implement the OpenStack Testing Interface for Fuel
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.
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
> Interface . In response to the Fuel application , the Technical
> has clarified that this includes running gate jobs on the OpenStack
> Infrastructure .
>  https://review.openstack.org/199232
>  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
> 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
> components of Fuel.
> As I mentioned in my previous email , we're days away from Feature
> for Fuel 7.0, so we need to plan a gradual transition instead of making the
> testing interface a hard requirement for all repositories.
> I propose the following stages for transition of Fuel CI to OpenStack
> 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
> be done immediately. Boris Pavlovic has kindly agreed to be our code fairy
> magicked together a request that enables such jobs for nailgun in fuel-web
>  https://review.openstack.org/202892
> As it turns out, OpenStack CI imposes strict limits on a project's
> 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
> tests pass would involve a major restructuring of fuel-web repository,
> once again is for now blocked by the 7.0 FF. We have a blueprint to split
> fuel-web , but so far we've only managed to extract fuel-agent, the rest
> will probably have to wait until 8.0.
>  https://blueprints.launchpad.net/fuel/+spec/split-fuel-web-repo
> Because of that, I think fuel-agent is a better candidate for the first
> component to get CI jobs on OpenStack Infrastructure.
> Stage 2: Get the non-voting jobs on the first component to pass, and make
> 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
> be able to complete this stage before 7.0 soft code freeze on August 13
>  https://wiki.openstack.org/wiki/Fuel/7.0_Release_Schedule
> Stage 3: Enable non-voting jobs for all other Python components of Fuel
> 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
> 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.
> 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
> 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
> 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
> Dmitry Borodaenko
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev