hi guys
What I would really like is to have the CentOS Linux 7.1611 ( based on RHEL 7.3 sources ) be available and deployed on the CI nodes ahead of when we GA - so that SIGs and other people who are invested with us, have a chance to validate their content and also prep anything that might be needed ahead of GA for 7.1611
Towards that goal - there are 2 stages we can do this in.
1) When CR/ repo content is ready, we enable that content directly in the CI nodes. The CR repo represents the next-release content, but shipped as a repo in the existing release tree. This allows folks to 'yum update' and get the content ahead of GA. In our case, on the CI nodes, we would run the yum upgrade as a part of the install process, so while the deployment would have been with the previous installer, the booted machine would be running the new kernel + new packages. And any yum operation from here on, would include the newer content.
2) this stage would come a few days down the road, when we have the installer in place and the new CI deployments are then run with the new installer
Since the installer is typically the last thing that we build, stage2 might be a few more days out, but we should be able to start seeding up stage1 above, in the next day or two. I will announce it here once this content is in place.
What is important is that when things break with the new code, please let us know - this list is fine, we will track here, but also the centos-devel list is a good place to talk about it. For real time chat, #centos-devel on irc.freenode.net
Does anyone have thoughts around this ?
On 17/11/16 13:56, Karanbir Singh wrote:
hi guys
What I would really like is to have the CentOS Linux 7.1611 ( based on RHEL 7.3 sources ) be available and deployed on the CI nodes ahead of when we GA - so that SIGs and other people who are invested with us, have a chance to validate their content and also prep anything that might be needed ahead of GA for 7.1611
Towards that goal - there are 2 stages we can do this in.
- When CR/ repo content is ready, we enable that content directly in
the CI nodes. The CR repo represents the next-release content, but shipped as a repo in the existing release tree. This allows folks to 'yum update' and get the content ahead of GA. In our case, on the CI nodes, we would run the yum upgrade as a part of the install process, so while the deployment would have been with the previous installer, the booted machine would be running the new kernel + new packages. And any yum operation from here on, would include the newer content.
- this stage would come a few days down the road, when we have the
installer in place and the new CI deployments are then run with the new installer
Since the installer is typically the last thing that we build, stage2 might be a few more days out, but we should be able to start seeding up stage1 above, in the next day or two. I will announce it here once this content is in place.
What is important is that when things break with the new code, please let us know - this list is fine, we will track here, but also the centos-devel list is a good place to talk about it. For real time chat, #centos-devel on irc.freenode.net
Does anyone have thoughts around this ?
That sounds like a good idea, and probably already in place for CentOS 7 : machines are provisioned with CR content by default : <ks content> repo --name="cr" --baseurl=http://mirror.centos.org/centos/7/cr/x86_64/ --cost=100 .... %post yum-config-manager --enable cr </ks content>
So that means that it should be there already, and so as soon as content will be pushed to CR, it will be available to CI projects.
The other question (and so question for centos-devel) is about reflecting that into CBS too so that people seeing issues in their CI tests against 7.1511+updates+CR will have a chance to build in cbs against the same repositories ..
-
Fabian Arrotin -
Karanbir Singh