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 :
- 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.
- 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,