<div dir="ltr">Dmitry, <div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Am I missing any major risks or additional requirements here? </span></blockquote><div> </div><div>Syncing requirements with global openstack requirements can produce issues, <br></div><div>that requires changes in code. </div><div><br></div><div>I would strongly recommend to sync requirements by hand and test</div><div>everything before starting splitting repos and adding openstack-ci jobs.</div><div><br></div><div>-1 risk.</div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 18, 2015 at 12:16 AM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One of the requirements for all OpenStack projects is to use the same Testing<br>
Interface [0]. In response to the Fuel application [1], the Technical Committee<br>
has clarified that this includes running gate jobs on the OpenStack<br>
Infrastructure [2][3].<br>
<br>
[0] <a href="http://governance.openstack.org/reference/project-testing-interface.html" rel="noreferrer" target="_blank">http://governance.openstack.org/reference/project-testing-interface.html</a><br>
[1] <a href="https://review.openstack.org/199232" rel="noreferrer" target="_blank">https://review.openstack.org/199232</a><br>
[2] <a href="http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-07-14-20.02.log.html#l-150" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-07-14-20.02.log.html#l-150</a><br>
[3] <a href="https://review.openstack.org/201766" rel="noreferrer" target="_blank">https://review.openstack.org/201766</a><br>
<br>
Although the proposed formal requirement could use some clarification,<br>
according to the meeting log linked above, TC has acknowledged that OpenStack<br>
Infrastructure can't currently host deployment tests for projects like Fuel and<br>
TripleO. This narrows the requirement down to codestyle checks, unit tests,<br>
coverage report, source tarball generation, and docs generation for all Python<br>
components of Fuel.<br>
<br>
As I mentioned in my previous email [4], we're days away from Feature Freeze<br>
for Fuel 7.0, so we need to plan a gradual transition instead of making the<br>
testing interface a hard requirement for all repositories.<br>
<br>
[4] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-July/069906.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-July/069906.html</a><br>
<br>
I propose the following stages for transition of Fuel CI to OpenStack<br>
Infrastructure:<br>
<br>
Stage 1: Enable non-voting jobs compliant with the testing interface for a<br>
single Python component of Fuel. This has no impact on Fuel schedule and should<br>
be done immediately. Boris Pavlovic has kindly agreed to be our code fairy and<br>
magicked together a request that enables such jobs for nailgun in fuel-web [5].<br>
<br>
[5] <a href="https://review.openstack.org/202892" rel="noreferrer" target="_blank">https://review.openstack.org/202892</a><br>
<br>
As it turns out, OpenStack CI imposes strict limits on a project's directory<br>
structure, and fuel-web doesn't fit those since it contains a long list of<br>
components besides nailgun, some of them not even in Python. Making the above<br>
tests pass would involve a major restructuring of fuel-web repository, which<br>
once again is for now blocked by the 7.0 FF. We have a blueprint to split<br>
fuel-web [6], but so far we've only managed to extract fuel-agent, the rest<br>
will probably have to wait until 8.0.<br>
<br>
[6] <a href="https://blueprints.launchpad.net/fuel/+spec/split-fuel-web-repo" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/split-fuel-web-repo</a><br>
<br>
Because of that, I think fuel-agent is a better candidate for the first Fuel<br>
component to get CI jobs on OpenStack Infrastructure.<br>
<br>
Stage 2: Get the non-voting jobs on the first component to pass, and make them<br>
voting and gating the commits to that component. Assuming that we pick a<br>
component that doesn't need major restructuring to pass OpenStack CI, we should<br>
be able to complete this stage before 7.0 soft code freeze on August 13 [7].<br>
<br>
[7] <a href="https://wiki.openstack.org/wiki/Fuel/7.0_Release_Schedule" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Fuel/7.0_Release_Schedule</a><br>
<br>
Stage 3: Enable non-voting jobs for all other Python components of Fuel outside<br>
of fuel-web. We will have until 7.0 GA release on September 24, and we won't be<br>
able to proceed to following stages until 7.0 is released.<br>
<br>
Stage 4: Everything else that is too disruptive for 7.0 but doesn't require<br>
changes on the side of OpenStack Infrastructure can all start in parallel after<br>
Fuel 7.0 is released:<br>
<br>
a) Finish splitting fuel-web.<br>
b) Get all Python components of Fuel to pass OpenStack CI.<br>
c) Set up unit test gates for non-Python components of Fuel (e.g. fuel-astute).<br>
d) Finish the transition of upstream modules in fuel-library to librarian.<br>
e) Set up rspec based gates for non-upstream modules in fuel-library.<br>
<br>
I think completing all these can be done by 8.0 SCF in December, and if not,<br>
must become a blocker requirement for 9.0 (Q3 2016).<br>
<br>
Stage 5: Bonus objectives that are not required to meet TC requirements for<br>
joining OpenStack, but still achievable based on current state of OpenStack<br>
Infrastructure:<br>
<br>
a) functional tests for Fuel UI<br>
b) beaker tests for non-upstream parts of fuel-library<br>
<br>
Stage 6: Stretch goal for the distant future is to actually make it possible to<br>
run multi-node deploy tests on OpenStack Infrastructure. I guess we can at<br>
least start that discussion in Tokyo...<br>
<br>
Am I missing any major risks or additional requirements here? Do the dates make<br>
sense?<br>
<br>
Thanks,<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Dmitry Borodaenko<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>