<div dir="auto">We're currently running with a max-servers of 80 for the TripleO tenant. This number doesn't include OVB nodes.<div dir="auto"><br></div><div dir="auto">When taking into account OVB nodes, we are already nearing vCPU capacity and could consider raising the overcommit ratio from 2.0 to 4.0 to make use of the available RAM.</div><div dir="auto"><br></div><div dir="auto">See the rough maths in my comment here [1].</div><div dir="auto"><br></div><div dir="auto">[1]: <a href="https://review.rdoproject.org/r/#/c/10249/1/nodepool/nodepool.yaml@133">https://review.rdoproject.org/r/#/c/10249/1/nodepool/nodepool.yaml@133</a></div><div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">David Moreau Simard<br>Senior Software Engineer | Openstack RDO<br><br>dmsimard = [irc, github, twitter]</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 25, 2017 1:39 PM, "Ben Nemec" <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Overall sounds good.  A couple of comments inline.<br>
<br>
On 10/23/2017 05:46 AM, Sagi Shnaidman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
as you know we prepare transition of all OVB jobs from RH1 cloud to RDO cloud, also a few long multinode upgrades jobs as well. We prepared a workflow of transition below, please feel free to comment.<br>
<br>
<br>
1) We run one job (ovb-ha-oooq) on every patch in following repos: oooq, oooq-extras, tripleo-ci. We run rest of ovb jobs (containers and fs024) as experimental in rdo cloud for following repos: oooq, oooq-extras, tripleo-ci, tht, tripleo-common. It should cover most of our testing. This step is completed.<br>
<br>
Currently it's blocked by newton bug in RDO cloud: <a href="https://bugs.launchpad.net/heat/+bug/1626256" rel="noreferrer" target="_blank">https://bugs.launchpad.net/hea<wbr>t/+bug/1626256</a> , where cloud release doesn't contain its fix: <a href="https://review.openstack.org/#/c/501592/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/501592/</a> . From other side, the upgrade to Ocata release (which would solve this issue too) is blocked by bug: <a href="https://bugs.launchpad.net/tripleo/+bug/1724328" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tri<wbr>pleo/+bug/1724328</a><br>
So we are in blocked state right now with moving.<br>
<br>
Next steps:<br>
<br>
2) We solve all issues with running on every patch job (ovb-ha-oooq) so that it's passing (or failing exactly for same results as on rh1) for a 2 regular working days. (not weekend).<br>
3) We should trigger experimental jobs in this time on various patches in tht and tripleo-common and solve all issues for experimental jobs so all ovb jobs pass.<br>
4) We need to monitor all this time resources in openstack-nodepool tenant (with help of rhops maybe) and be sure that it has the capacity to run configured jobs.<br>
</blockquote>
<br>
I assume we will have a max jobs limit in nodepool (or whatever we're using for that purpose) that will ensure we stay within capacity regardless of what jobs are configured.  We probably want to keep that limit low initially so we don't have to worry about throwing a huge number of jobs at the cloud accidentally (say someone submits a large patch series that triggers our subset of jobs).<br>
<br>
Obviously as we add jobs we'll need to bump the concurrent jobs limit, but I think that should be the primary variable we change and that we add more jobs as necessary to fill the configured limit.  Also, rather than set a time period of two days or whatever, ensure we run at the configured limit for some period of time before increasing it.  There are slow days in ci where we might not get much useful information so we need to make sure we don't get a false positive result from a step just because of the quirks of ci load.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5) We set ovb-ha-oooq job as running for every patch in all places where it's running in rh1 (in parallel with existing rh1 job). We monitor RDO cloud that it doesn't fail and still have resources - 1.5 working days<br>
6) We add featureset024 ovb job to run in every patch where it runs in rh1. We continue to monitor RDO cloud - 1.5 working days<br>
7) We add last containers ovb job to all patches where it runs on rh1. We continue monitor RDO cloud - 2 days.<br>
8) In case if everything is OK in all previous points and RDO cloud still performs well, we remove ovb jobs from rh1 configuration and make them as experimental.<br>
9) During next few days we monitor ovb jobs and run rh1 ovb jobs as experimental to check if we have the same results (or better :) )<br>
10) OVB jobs on rh1 cloud stay in experimental pipeline in tripleo for a next month or two.<br>
<br>
-- <br>
Best regards<br>
Sagi Shnaidman<br>
<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.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>
<br>
</blockquote>
<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.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>
</blockquote></div></div>