<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, May 13, 2018 at 11:25 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">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 08:25:25 -0600 (-0600), Wesley Hayutin wrote:<br>
[...]<br>
> We need to in coordination with the infra team be able to pin / lock<br>
> content for production check and gate jobs while also have the ability to<br>
> stage new content e.g. centos 7.5 with experimental or periodic jobs.<br>
[...]<br>
<br>
It looks like adjustments would be needed to DIB's centos-minimal<br>
element if we want to be able to pin it to specific minor releases.<br>
However, having to rotate out images in the fashion described would<br>
be a fair amount of manual effort and seems like it would violate<br>
our support expectations in governance if we end up pinning to older<br>
minor versions (for major LTS versions on the other hand, we expect<br>
to undergo this level of coordination but they come at a much slower<br>
pace with a lot more advance warning). If we need to add controlled<br>
roll-out of CentOS minor version updates, this is really no better<br>
than Fedora from the Infra team's perspective and we've already said<br>
we can't make stable branch testing guarantees for Fedora due to the<br>
complexity involved in using different releases for each branch and<br>
the need to support our stable branches longer than the distros are<br>
supporting the releases on which we're testing.<br></blockquote><div><br></div><div>This is good insight Jeremy, thanks for replying.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For example, how long would the distro maintainers have committed to<br>
supporting RHEL 7.4 after 7.5 was released? Longer than we're<br>
committing to extended maintenance on our stable/queens branches? Or<br>
would you expect projects to still continue to backport support for<br>
these minor platform bumps to all their stable branches too? And<br>
what sort of grace period should we give them before we take away<br>
the old versions? Also, how many minor versions of CentOS should we<br>
expect to end up maintaining in parallel? (Remember, every<br>
additional image means that much extra time to build and upload to<br>
all our providers, as well as that much more storage on our builders<br>
and in our Glance quotas.)<br>
-- <br>
Jeremy Stanley<br></blockquote><div><br></div><div>I think you may be describing a level of support that is far greater than what I was thinking. I also don't want to tax the infra team w/ n+ versions of the baseos to support.  </div><div>I do think it would be helpful to say have a one week change window where folks are given the opportunity to preflight check a new image and the potential impact on the job workflow the updated image may have.  If I could update or create a non-voting job w/ the new image that would provide two things.</div><div><br></div><div>1. The first is the head's up, this new minor version of centos is coming into the system and you have $x days to deal with it.</div><div>2. The ability to build a few non-voting jobs w/ the new image to see what kind of impact it has on the workflow and deployments.</div><div><br></div><div>In this case the updated 7.5 CentOS image worked fine w/ TripleO, however it did cause our gates to go red because..</div><div>a. when we update containers w/ zuul dependendencies all the base-os updates were pulled in and jobs timed out.</div><div>b. a kernel bug workaround with virt-customize failed to work due the kernel packages changed ( 3rd party job )</div><div>c. the containers we use were not yet at CentOS 7.5 but the bm image was causing issues w/ pacemaker.</div><div>d. there may be a few more that I am forgetting, but hopefully the point is made.</div><div><br></div><div>We can fix a lot of the issues and I'm not blaming anyone because if we  (tripleo ) thought of all the corner cases with our workflow we would have been able to avoid some of these issues.  However it does seem like we get hit by $something every time we update a minor version of the baseos.  My preference would be to have a heads up and work through the issues than to go immediately red and unable to merge patches.  I don't know if other teams get impacted in similiar ways, and I understand this is a big ship and updating CentOS may work just fine for everyone else.</div><div><br></div><div>Thanks all for your time and effort!</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
__________________________________________________________________________<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>