<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, May 12, 2018 at 11:45 PM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 12, 2018 at 9:10 AM, Wesley Hayutin <span dir="ltr"><<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>2. Shortly after #1 was resolved CentOS released 7.5 which comes directly into the upstream repos untested and ungated.  Additionally the associated qcow2 image and container-base images were not updated at the same time as the yum repos.  <a href="https://bugs.launchpad.net/tripleo/+bug/1770355" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1770355</a></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Why do we have this situation everytime the OS is upgraded to a major version? Can't we test the image before actually using it? We could have experimental jobs testing latest image and pin gate images to a specific one?</div><div>Like we could configure infra to deploy centos 7.4 in our gate and 7.5 in experimental, so we can take our time to fix eventual problems and make the switch when we're ready, instead of dealing with fires (that usually come all together).</div><div><br></div><div>It would be great to make a retrospective on this thing between tripleo ci & infra folks, and see how we can improve things.</div></div></div></div></blockquote><div><br></div><div>I agree,</div><div>We need to in coordination with the infra team be able to pin / lock content for production check and gate jobs while also have the ability to stage new content e.g. centos 7.5 with experimental or periodic jobs.</div><div>In this particular case the ci team did check the tripleo deployment w/ centos 7.5 updates, however we did not stage or test what impact the centos minor update would have on the upstream job workflow.</div><div>The key issue is that the base centos image used upstream can not be pinned by the ci team, if say we could pin that image the ci team could pin the centos repos used in ci and run staging jobs on the latest centos content.</div><div><br></div><div>I'm glad that you also see the need for some amount of coordination here, I've been in contact with a few folks to initiate the conversation.</div><div><br></div><div>In an unrelated note, Sagi and I just fixed the network latency issue on our promotion server, it was related to DNS.  Automatic promotions should be back online.</div><div>Thanks all.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">-- <br><div class="m_-3178477008414559797gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>
</div></div>
__________________________________________________________________________<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></div>