<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 6, 2017 at 7:35 AM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobreli@redhat.com" target="_blank">bdobreli@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 11/6/17 1:01 AM, Emilien Macchi wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>> wrote:<br>
[...]<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  -CI resources: better use of CI resources. At the PTG we received<br>
feedback from the OpenStack infrastructure team that our upstream CI<br>
resource usage is quite high at times (even as high as 50% of the<br>
total). Because of the shared framework and single node capabilities we<br>
can re-architecture much of our upstream CI matrix around single node.<br>
We no longer require multinode jobs to be able to test many of the<br>
services in tripleo-heat-templates... we can just use a single cloud VM<br>
instead. We'll still want multinode undercloud -> overcloud jobs for<br>
testing things like HA and baremetal provisioning. But we can cover a<br>
large set of the services (in particular many of the new scenario jobs<br>
we added in Pike) with single node CI test runs in much less time.<br>
</blockquote>
<br>
After the last (terrible) weeks in CI, it's pretty clear we need to<br>
find a solution to reduce and optimize our testing.<br>
I'm now really convinced by switching our current scenarios jobs to<br>
NOT deploy the overcloud, and just an undercloud with composable<br>
services & run tempest.<br>
</blockquote>
<br></span>
+1<br>
And we should start using the quickstart-extras undercloud-reploy role for that.<span class="gmail-im gmail-HOEnZb"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Benefits:<br>
- deploy 1 node instead of 2 nodes, so we save nodepool resources<br>
- faster (no overcloud)<br>
- reduce gate queue time, faster development process, faster CI<br>
<br>
Challenges:<br>
- keep overcloud testing, with OVB<br>
- reduce OVB to strict minimum: Ironic, Nova, Mistral and basic<br>
containerized services on overcloud.<br>
<br>
I really want to get consensus on these points, please raise your<br>
voice now before we engage some work on that front.<br>
<br>
[...]<br>
<br>
</blockquote>
<br>
<br>
-- <br></span><span class="gmail-im gmail-HOEnZb">
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br></span><div class="gmail-HOEnZb"><div class="gmail-h5">
______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">OK, </div><div class="gmail_extra">Just got off the containers call.  We discussed the CI requirements for the containerized undercloud.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the upstream, launched via quickstart not tripleo.sh we want to see</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) undercloud-containers - a containerized install, should be voting by m1</div><div class="gmail_extra">2) undercloud-containers-update - minor updates run on containerized</div><div class="gmail_extra">underclouds, should be voting by m2</div><div class="gmail_extra">3) undercloud-containers-upgrade - major upgrade from</div><div class="gmail_extra">non-containerized to containerized undercloud, should be voting by m2.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The above three items will enable us to test the quality of just the undercloud install.</div><div class="gmail_extra"><br></div>Ian and I are also working together on testing full deployments with the containerized<div class="gmail_extra"> undercloud to test how stable full runs are generally.  This will </div><div class="gmail_extra">help us assess the readiness of switching over in full in queens.  </div><div class="gmail_extra"><br></div><div class="gmail_extra">This will also then lead into discussions and planning around where we can remove</div><div class="gmail_extra">multinode testing in upstream and start to fully utilize the benefits of the containerized undercloud. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Please contact myself or Sagi regarding changes in the CI for the undercloud.</div><div class="gmail_extra">Thanks</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>