On 2018-05-13 08:25:25 -0600 (-0600), Wesley Hayutin wrote: [...] > 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. [...]
It looks like adjustments would be needed to DIB's centos-minimal element if we want to be able to pin it to specific minor releases. However, having to rotate out images in the fashion described would be a fair amount of manual effort and seems like it would violate our support expectations in governance if we end up pinning to older minor versions (for major LTS versions on the other hand, we expect to undergo this level of coordination but they come at a much slower pace with a lot more advance warning). If we need to add controlled roll-out of CentOS minor version updates, this is really no better than Fedora from the Infra team's perspective and we've already said we can't make stable branch testing guarantees for Fedora due to the complexity involved in using different releases for each branch and the need to support our stable branches longer than the distros are supporting the releases on which we're testing. For example, how long would the distro maintainers have committed to supporting RHEL 7.4 after 7.5 was released? Longer than we're committing to extended maintenance on our stable/queens branches? Or would you expect projects to still continue to backport support for these minor platform bumps to all their stable branches too? And what sort of grace period should we give them before we take away the old versions? Also, how many minor versions of CentOS should we expect to end up maintaining in parallel? (Remember, every additional image means that much extra time to build and upload to all our providers, as well as that much more storage on our builders and in our Glance quotas.) -- Jeremy Stanley
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev