<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, May 13, 2018 at 11:30 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-05-13 20:44:25 -0600 (-0600), Wesley Hayutin wrote:<br>
[...]<br>
> I do think it would be helpful to say have a one week change<br>
> window where folks are given the opportunity to preflight check a<br>
> new image and the potential impact on the job workflow the updated<br>
> image may have. If I could update or create a non-voting job w/<br>
> the new image that would provide two things.<br>
> <br>
> 1. The first is the head's up, this new minor version of centos is<br>
> coming into the system and you have $x days to deal with it.<br>
> <br>
> 2. The ability to build a few non-voting jobs w/ the new image to<br>
> see what kind of impact it has on the workflow and deployments.<br>
[...]<br>
<br>
While I can see where you're coming from, right now even the Infra<br>
team doesn't know immediately when a new CentOS minor release starts<br>
to be used. The packages show up in the mirrors automatically and<br>
images begin to be built with them right away. There isn't a<br>
conscious "switch" which is thrown by anyone. This is essentially<br>
the same way we treat Ubuntu LTS point releases as well. If this is<br>
_not_ the way RHEL/CentOS are intended to be consumed (i.e. just<br>
upgrade to and run the latest packages available for a given major<br>
release series) then we should perhaps take a step back and<br>
reevaluate this model. </blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>I think you may be conflating the notion that ubuntu or rhel/cent can be updated w/o any issues to applications that run atop of the distributions with what it means to introduce a minor update into the upstream openstack ci workflow.</div><div><br></div><div>If jobs could execute w/o a timeout the tripleo jobs would have not gone red.  Since we do have constraints in the upstream like a timeouts and others we have to prepare containers, images etc to work efficiently in the upstream.  For example, if our jobs had the time to yum update the roughly 120 containers in play in each job the tripleo jobs would have just worked.  I am not advocating for not having timeouts or constraints on jobs, however I am saying this is an infra issue, not a distribution or distribution support issue.</div><div><br></div><div>I think this is an important point to consider and I view it as mostly unrelated to the support claims by the distribution.  Does that make sense?</div><div>Thanks</div><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For now we have some fairly deep-driven<br>
assumptions in that regard which are reflected in the Linux<br>
distributions support policy of our project testing interface as<br>
documented in OpenStack governance.<br>
-- <br>
Jeremy Stanley<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></div></div>