<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi,</div><div class="gmail_default" style="font-family:verdana,sans-serif">Could you please point out some of the glance functional tests which are failing and causing this resets?</div><div class="gmail_default" style="font-family:verdana,sans-serif">I will like to put some efforts towards fixing those.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks & Best Regards,<br><br></div>Abhishek Kekane<br></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 3, 2018 at 10:14 PM Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>> writes:<br>
<br>
[snip]<br>
<br>
> The TripleO project has created a single node container based composable<br>
> OpenStack deployment [2]. It is the projects intention to replace most of<br>
> the TripleO upstream jobs with the Standalone deployment.  We would like to<br>
> reduce our multi-node usage to a total of two or three multinode jobs to<br>
> handle a basic overcloud deployment, updates and upgrades[a]. Currently in<br>
> master we are relying on multiple multi-node scenario jobs to test many of<br>
> the OpenStack services in a single job. Our intention is to move these<br>
> multinode scenario jobs to single node job(s) that tests a smaller subset<br>
> of services. The goal of this would be target the specific areas of the<br>
> TripleO code base that affect these services and only run those there. This<br>
> would replace the existing 2-3 hour two node job(s) with single node job(s)<br>
> for specific services that completes in about half the time.  This<br>
> unfortunately will reduce the overall coverage upstream but still allows us<br>
> a basic smoke test of the supported OpenStack services and their deployment<br>
> upstream.<br>
><br>
> Ideally projects other than TripleO would make use of the Standalone<br>
> deployment to test their particular service with containers, upgrades or<br>
> for various other reasons.  Additional projects using this deployment would<br>
> help ensure bugs are found quickly and resolved providing additional<br>
> resilience to the upstream gate jobs. The TripleO team will begin review to<br>
> scope out and create estimates for the above work starting on October 18<br>
> 2018.  One should expect to see updates on our progress posted to the<br>
> list.  Below are some details on the proposed changes.<br>
<br>
[snip]<br>
<br>
Thanks for all of the details, Wes. I know the current situation has<br>
been hurting the TripleO team as well, so I'm glad to see a good plan in<br>
place to address it. I look forward to seeing updates about the<br>
progress.<br>
<br>
Doug<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>
</blockquote></div>