Open Stack

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