[Ci-users] upcoming CentOS Linux 7 release

Tue Nov 24 06:37:14 UTC 2015
Fabian Arrotin <arrfab at centos.org>

Hash: SHA1

On 24/11/15 00:30, Karanbir Singh wrote:
> hi guys,
> RHEL 7.2 was released a few days back and we've been busy sorting 
> through the code and working on the downstream CentOS Linux release
> ( its going to likely be released in November and will be called
> 7.1511 ).
> I'd like to make that content available on ci.centos.org ahead of
> public release. And there are a couple of ways to do this :
> 1) either we update the provisioning service, so all requests for
> a centos linux 7 machine will give you a 7.1511 build ( its 7.1503
> at the moment ), with all the updates etc posted in sync that way.
> This also means that mirror.centos.org inside the ci infra will
> look DIFFERENT from mirror.centos.org the real users see, since it
> will be setup to look like the next release.

Not the solution I was thinking of, as that would imply we'll have an
installable tree with 7.1511 content, and that's not the case. So my
idea was more something like :
- - provision using the http://mirror.centos.org/centos/7/ url
- - add the 7.1511 pre-released and unsigned/untested content as another
repo in the kickstart.

That means that new nodes provisioned with 7 will have directly newer
packages installed. and we also need to enforce that repo to be
available for the CI tests (kickstart can drop an additional .repo
pointing to that internal temporary repo)

The issue is that because it's untested, the provisioning itself can
fail (due to conflicting packages, or other issues), leading to CI
tests not being able to be launched (in worst case)

I'd also like to keep the internal mirror.centos.org exactly the same
as what is released and available publicly, and keep the
untested/unsigned packages in another repository, so that it would be
clear to see the root cause if there is a packaging issue, etc (like
gluster packages - part of - available now in the 7.1511 repo)

> 2) we make the content available in a new set of repos, called 
> CentOS.next or something; and the ci users are able to optionally
> tweak their build scripts etc to include or not include these new
> changes.

Yes, at least $projects actually using the CI env would be able to opt-in

> 3) we dont make this content available before its publicly
> released.
> of all those bits, I like (1) best; (2) only delays the content
> from hitting the ci infra by a week or 10 days. We dont usually
> take longer than that from when the builds are done to when the
> distro update is released. (3) just means that if there are
> changes, failures or breakages in the ci tested code, we only find
> out at the same time as the users - which isnt nice.
> thoughts ?

- -- 
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab
Version: GnuPG v2.0.22 (GNU/Linux)