Dmitry,
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 < [email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
