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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
