<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 8, 2017 at 5:00 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Nov 7, 2017 at 2:59 PM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>
> On Wed, Nov 8, 2017 at 3:30 AM, James Slagle <<a href="mailto:james.slagle@gmail.com">james.slagle@gmail.com</a>> wrote:<br>
>> On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>
>>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br>
>>> [...]<br>
>>><br>
>>>>  -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>
>>><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>
>><br>
>> +1 if you mean just the scenarios.<br>
><br>
> Yes, just scenarios.<br>
><br>
>> I think we need to keep at least 1 multinode job voting that deploys<br>
>> the overcloud, probably containers-multinode.<br>
><br>
> Yes, exactly, and also work on optimizing OVB jobs (maybe just keep<br>
> one or 2 jobs, instead 3).<br>
><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>
>><br>
>> This is why I'm not sure what you're proposing. Do you mean switch all<br>
>> multinode jobs to be just an undercloud, or just the scenarios?<br>
><br>
> Keep 1 or 2 OVB jobs, to test ironic + mistral + HA (HA could be<br>
> tested with multinode though but well).<br>
><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>
>> I'm fine to optimize the scenarios to be undercloud driven, but feel<br>
>> we still need a multinode job that deploys the overcloud in the gate.<br>
>> Otherwise, we'll have nothing that deploys an overcloud in the gate,<br>
>> which is a step in the wrong direction imo. Primarily, b/c of the loss<br>
>> of coverage around mistral and all of our workflows. Perhaps down the<br>
>> road we could find ways to optimize that by using an ephemeral Mistral<br>
>> (similar to the ephemeral Heat container), and then use a single node,<br>
>> but we're not there yet.<br>
>><br>
>> On the other hand, if the goal is just to test less upstream so that<br>
>> we can more quickly merge code, then *not* deploying an overcloud in<br>
>> the gate at all seems to fit that goal. Is that what you're after?<br>
><br>
> Yes. Thanks for reformulate with better words.<br>
> Just to be clear, I want to transform the scenarios into single-node<br>
> jobs that deploy the SAME services (using composable services) from<br>
> the undercloud, using the new ansible installer. I also want to keep<br>
> running Tempest.<br>
> And of course, like we said, keep one multinode job to test overcloud<br>
> workflow, and OVB with some adjustments.<br>
><br>
<br>
</div></div>So I'm ok with switching to use the containerized undercloud deploy to<br>
smoke test functionality of more complex openstack service<br>
deployments. What I would like to see prior to investing in this is<br>
that the plain containerized undercloud deploy job reliability is on<br>
par with the existing undercloud install.  We had to switch the<br>
undercloud-containers back to non-voting due to higher failure rates<br>
and it is still not voting.  </blockquote><div><br></div><div>Agree, once we have a little success I'll update featureset027 ( the undercloud-containers )</div><div>which is still non-voting to use this updated containerized deployment.  Then we'll compare</div><div>the undercloud-oooq to undercloud-containers (fs027) After a few weeks of running.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With the current state of CI being<br>
questionable due to random failures which are not fully have resolved,<br>
I would prefer that we ensure existing CI is stable and that what we<br>
plan to move is as stable.<br></blockquote><div><br></div><div>Agreed,</div><div>There are times IMHO when one must strike when the iron is hot on certain</div><div>parts of the work here.  I felt compelled to help bootstrap Ian with the </div><div>containerized undercloud work or see old habits remain and have things</div><div>running in tripleo.sh or other shell scripts.</div><div><br></div><div>The priority is to help stablize the upstream CI for sure!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additionally I think we need to ensure that the ovb jobs that still do<br>
full deployment process become voting by switching to 3rd party CI.<br></blockquote><div><br></div><div>Yes, agreed.  I'll reach out to the rdo sf admins and see if we get it voting -2.</div><div>That is what we discussed at summit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
-Alex<br>
<div class="HOEnZb"><div class="h5"><br>
> Is it good?<br>
><br>
> Thanks,<br>
> --<br>
> Emilien Macchi<br>
><br>
> ______________________________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>