[Ci-users] upcoming CentOS Linux 7 release

Tue Nov 24 08:17:40 UTC 2015
Karanbir Singh <mail-lists at karan.org>

On 24/11/15 06:37, Fabian Arrotin wrote:
> 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.

I dont think we should put any unsigned code in here, if its not good
enough to be signed, its not good enough to test stacks on, either
upstream or downstream.

> 
> 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)

but... surely the point of CI is also to test the platform side for the
code running on it, so these failures would be welcome ?

> 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)

When testing things, I like to know that I'm testing content the way the
user is going to see it, so I know I'm testing my code, and not the
mirror infra or testing specific tweaks that are irrelevant to the user
side : so having mirror inside the ci infra look like a released mirror
is the way to go ( imho ), otherwise people are testing exceptions.

>> 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

opt-in yes, but its only an opt-in if there is an opt-out, in this case
there isnt one - we're just getting them the content a week or so ahead
of the rest of the world, so ci-users can make sure ( or atleast know!
of any major issue coming up ). eg. if a major app stops working, we
should make sure its not a break at our end, and if not-possible to fix,
we should put that info in the release notes atleast.

regards,

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc