<div dir="ltr">Aleksandra,<div>you've got us exactly right. Fuel CI for OSTF can wait a bit longer, but "<span style="font-family:arial,sans-serif;font-size:12.8000001907349px">4 fuel-library tests" should happen right after we create stable/5.1. Also, for Fuel CI for OSTF - I don't think it's actually necessary to support <5.0 envs.</span></div><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">Your questions:</span></div><div><ol><li><font face="arial, sans-serif">Create jobs for both Icehouse and Juno, but it doesn't make sense to do staging for Juno till it starts to pass deployment in HA mode. Once it passes deployment in HA, staging should be enabled. Then, once it passes OSTF - we extend criteria, and pass only those mirrors which also pass OSTF phase</font></li><li><font face="arial, sans-serif">Once Juno starts to pass BVT with OSTF check enabled, I think we can disable Icehouse checks. Not sure about fuel-library tests on Fuel CI with Icehouse - we might want to continue using them. </font></li></ol><div><font face="arial, sans-serif">Thanks,</font></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 12:22 AM, Aleksandra Fedorova <span dir="ltr"><<a href="mailto:afedorova@mirantis.com" target="_blank">afedorova@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><span class=""><div><div></div>> <span style="font-family:arial,sans-serif;font-size:12.8px">Our Fuel CI can do 4 builds against puppet modules: 2 voting, with Icehouse packages; 2 non-voting, with Juno packages.</span><div></div><div>> Then,
 I'd suggest to create ISO with 2 releases (Icehouse, Juno) actually 
before Juno becomes stable. We will be able to run 2 sets of BVTs 
(against Icehouse and Juno), and it means that we will be able to see 
almost immediately if something in nailgun/astute/puppet integration 
broke. For Juno builds it's going to be all red initially.</div><br></div></span><div>Let me rephrase:<br><br></div><div>We keep one Fuel master branch for two OpenStack releases. And we make sure that Fuel master code is compatible with both of them. And we use current release (Icehouse) as a reference for test results of upcoming release, till we obtain stable enough reference point in Juno itself. Moreover we'd like to have OSTF code running on all previous Fuel releases.<br></div><div><br></div><div>Changes to CI workflow look as follows:<br><br></div><div>Nightly builds:<br></div><div>  1) We build two mirrors: one for Icehouse and one for Juno.<br></div>  2) From each mirror we build Fuel ISO using exactly the same fuel master branch code.<br><div>  3) Then we run BVT tests on both (using the same fuel-main code for system tests).<br></div><div>  4) If Icehouse BVT tests pass, we deploy both ISO images (even with failed Juno tests) onto Fuel CI. <br></div><div><br>On Fuel CI we should run:<br></div><div>  - 4 fuel-library tests (revert master node, inject fuel-library code in master node and run deployment):<br></div><div>            2 (ubuntu and centos) voting Icehouse tests and 2 non-voting Juno tests<br></div><div>  - 5 OSTF tests (revert deployed environment, inject OSTF code into master node, run OSTF):<br></div><div>            voting on 4.1, 5.0, 5.1, master/icehouse and non-voting on master/Juno<br></div><div>  - other tests, which don't use prebuilt environment, work as before<br><br></div><div>The major action point here would be OSTF tests, as we don't have yet working implementation of injecting OSTF code into deployed environment. And we don't run any tests on old environments.<br></div><br><br></div><div>Questions:<br><br></div><div>1) How should we test mirrors?<br><br></div><div>Current master mirrors go through the 4 hours test cycle involving Fuel ISO build:<br></div><div>  1. we build temporary mirror<br></div><div>  2. build custom iso from it <br></div><div>  3. run two custom bvt jobs<br></div><div>  4. if they pass we move mirror to stable and sitch to it for our "primary" fuel_master_iso<br><br></div><div>Should we test only Icehouse mirrors, or both, but ignoring again failed BVT for Juno? Maybe we should enable these tests only later in release cycle, say, after SCF?<br></div><br>2) It is not clear for me when and how we will switch from supporting two releases back to one.<br></div><div>Should we add one more milestone to our release process? The "Switching point", when we disable and remove Icehouse tasks and move to Juno completely? I guess it should happen before next SCF?<br></div></div></div><div><div><div><div><div><div><div><br><br></div></div></div></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 9:52 PM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div>> <span style="font-family:arial,sans-serif;font-size:12.8000001907349px">What we need to achieve that is have 2 build series based on Fuel</span></div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">master: one with Icehouse packages, and one with Juno, and, as Mike</span><br style="font-family:arial,sans-serif;font-size:12.8000001907349px"><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">proposed, keep our manifests backwards compatible with Icehouse.</span></span><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">Exactly. Our Fuel CI can do 4 builds against puppet modules: 2 voting, with Icehouse packages; 2 non-voting, with Juno packages.</span></div><div><br></div><div>Then, I'd suggest to create ISO with 2 releases (Icehouse, Juno) actually before Juno becomes stable. We will be able to run 2 sets of BVTs (against Icehouse and Juno), and it means that we will be able to see almost immediately if something in nailgun/astute/puppet integration broke. For Juno builds it's going to be all red initially.</div><div><br></div><div>Another suggestion would be to lower green switch in BVTs for Juno: first, when it passes deployment; and then, if it finally passes OSTF.</div><div><br></div><div>I'd like to hear QA & DevOps opinion on all the above. Immediately we would need just standard stuff which is in checklists for OSCI & DevOps teams, and ideally soon after that - ability to have Fuel CI running 4 builds, not 2, against our master, as mentioned above.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 9:28 PM, Roman Vyalov <span dir="ltr"><<a href="mailto:rvyalov@mirantis.com" target="_blank">rvyalov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">All OSCI action items for prepare HCF check list  has been done<div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 6:27 PM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br><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"><div dir="ltr">Thanks Alexandra.<div><br></div><div>We land a few patches a day currently, so I think we can open stable branch. If we see no serious objections in next 12 hours, let's do it. We would need to immediately notify everyone in mailing list - that for every patch for 5.1, it should go first to master, and then to stable/5.1.</div><div><br></div><div>Is everything ready from DevOps, OSCI (packaging) side to do this? Fuel CI, OBS, etc.?</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 2:28 PM, Aleksandra Fedorova <span dir="ltr"><<a href="mailto:afedorova@mirantis.com" target="_blank">afedorova@mirantis.com</a>></span> wrote:<br><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"><div dir="ltr"><div><div>As I understand your proposal, we need to split our HCF milestone into two check points: Branching Point and HCF itself.<br><br>Branching point should happen somewhere in between SCF and HCF. And though It may coincide with HCF, it needs its own list of requirements. This will give us the possibility to untie two events and make a separate decision on branching without enforcing all HCF criteria.<br><br></div>From the DevOps point of view it changes almost nothing, it just adds a bit more discussion items on the management side and slight modifications to our checklists.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Sep 9, 2014 at 5:55 AM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br></span><div><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">TL;DR: Yes, our work on 6.0 features is currently blocked and it is<br>
becoming a major problem. No, I don't think we should create<br>
pre-release or feature branches. Instead, we should create stable/5.1<br>
branches and open master for 6.0 work.<br>
<br>
We have reached a point in 5.1 release cycle where the scope of issues<br>
we are willing to address in this release is narrow enough to not<br>
require full attention of the whole team. We have engineers working on<br>
6.0 features, and their work is essentially blocked until they have<br>
somewhere to commit their changes.<br>
<br>
Simply creating new branches is not even close to solving this<br>
problem: we have a whole CI infrastructure around every active release<br>
series (currently 5.1, 5.0, 4.1), including test jobs for gerrit<br>
commits, package repository mirrors updates, ISO image builds, smoke,<br>
build verification, and swarm tests for ISO images, documentation<br>
builds, etc. A branch without all that infrastructure isn't any better<br>
than current status quo: every developer tracking their own 6.0 work<br>
locally.<br>
<br>
Unrelated to all that, we also had a lot of very negative experience<br>
with feature branches in the past [0] [1], which is why we have<br>
decided to follow the OpenStack branching strategy: commit all feature<br>
changes directly to master and track bugfixes for stable releases in<br>
stable/* branches.<br>
<br>
[0] <a href="https://lists.launchpad.net/fuel-dev/msg00127.html" target="_blank">https://lists.launchpad.net/fuel-dev/msg00127.html</a><br>
[1] <a href="https://lists.launchpad.net/fuel-dev/msg00028.html" target="_blank">https://lists.launchpad.net/fuel-dev/msg00028.html</a><br>
<br>
I'm also against declaring a "hard code freeze with exceptions", HCF<br>
should remain tied to our ability to declare a release candidate. If<br>
we can't release with the bugs we already know about, declaring HCF<br>
before fixing these bugs would be an empty gesture.<br>
<br>
Creating stable/5.1 now instead of waiting for hard code freeze for<br>
5.1 will cost us two things:<br>
<br>
1) DevOps team will have to update our CI infrastructure for one more<br>
release series. It's something we have to do for 6.0 sooner or later,<br>
so this may be a disruption, but not an additional effort.<br>
<br>
2) All commits targeted for 5.1 will have to be proposed for two<br>
branches (master and stable/5.1) instead of just one (master). This<br>
will require additional effort, but I think that it is significantly<br>
smaller than the cost of spinning our wheels on 6.0 efforts.<br>
<br>
-DmitryB<br>
<div><div><br>
<br>
On Mon, Sep 8, 2014 at 10:10 AM, Dmitry Mescheryakov<br>
<<a href="mailto:dmescheryakov@mirantis.com" target="_blank">dmescheryakov@mirantis.com</a>> wrote:<br>
> Hello Fuelers,<br>
><br>
> Right now we have the following policy in place: the branches for a<br>
> release are opened only after its 'parent' release have reached hard<br>
> code freeze (HCF). Say, 5.1 release is parent releases for 5.1.1 and<br>
> 6.0.<br>
><br>
> And that is the problem: if parent release is delayed, we can't<br>
> properly start development of a child release because we don't have<br>
> branches to commit. That is current issue with 6.0: we already started<br>
> to work on pushing Juno in to 6.0, but if we are to make changes to<br>
> our deployment code we have nowhere to store them.<br>
><br>
> IMHO the issue could easily be resolved by creation of pre-release<br>
> branches, which are merged together with parent branches once the<br>
> parent reaches HCF. Say, we use branch 'pre-6.0' for initial<br>
> development of 6.0. Once 5.1 reaches HCF, we merge pre-6.0 into master<br>
> and continue development here. After that pre-6.0 is abandoned.<br>
><br>
> What do you think?<br>
><br>
> Thanks,<br>
><br>
> Dmitry<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
Dmitry Borodaenko<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><br>-- <br><div dir="ltr"><div><div></div>Aleksandra Fedorova<br></div>bookwar<br></div>
</font></span></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><span><font color="#888888"><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div><div></div>Aleksandra Fedorova<br></div>bookwar<br></div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div>