Hi,
I'd like to introduce the idea of rolling monthly builds for install media, cloud, instance and container images.
A generally accepted and expected state of cloud and container images is to update the default stock image on a schedule, something we've not been doing in the past and something that lots of people have been asking for.
In order address this, I'd like to introduce everyone to http://buildlogs.centos.org/rolling/
There is no change to mirror.centos.org rpm repo's; those will stay the way they are.
For right now, these are x86_64 only; on c5 / c6 I will work to bringing in the 32bit builds in as well ( in the coming week ).
Important Note: the CentOS-6 cloud images now include cloud-init and expect user login from user 'centos' instead of the old default of 'root'. Please share comments about how this impacts your existing use case ( and I am very willing to go back to using the root user by default since thats what we've had for a long long time on c5/c6 ). CentOS-5 images remain as they were, no cloud-init and default login is via root. The cloud-init files in this CentOS-6 build are not signed, however they will be released into centos-extras/ and signed before we push these images to final release.
This contains right now :
CentOS-7 - CentOS-7-x86_64-AtomicHost-20141029_02.qcow2 - CentOS-7-x86_64-AtomicHost-20141029_02.qcow2.gz - CentOS-7-x86_64-GenericCloud-20141029_01.qcow2 and - CentOS-7-x86_64-DVD-20141029_02.iso - CentOS-7-x86_64-Everything-20141029_03.iso - CentOS-7-x86_64-Minimal-20141029_02.iso
CentOS-6 - CentOS-6-x86_64-GenericCloud-20141029_01.qcow2
In the next few days, I will try and get the entire stock of install media ( ie. livemedia and isos ) for the CentOS-6 tree online as well, and then CentOS-5. The aim is to work through the build process and evolve it through this month, to then hit a regular, predictable delivery plan.
These images are built against the mirror.centos.org state as on and including all updates released to the 29th of October ( so as to be a month from the last images. ), however there is good reason to either make it the 28th of every month ( so we are covered for Feb ) or just use the 1st of the month, every month, to include all updates released upto that day ( but not including the 1st ). This would also make it easier to label the images at just YYMM, and we can drop the day of month reference completely.
Couple of key things to note here : - Whatever date we all decide on, we will use that date in month, to deliver fresh install media every month, which will contain all updates released from the last media set, rolled in. eg. If someone was to install CentOS-7-x86_64-DVD-20141029.iso, the default installed tree would already pre-include all updates released to that date.
- The aim is to pick a snapshot date, and deliver the entire complement of media, i.e if someone was to pick Nov '14 as their install point, they would be able to get docker images, vagrant images, cloud images, live media, iso media all with exact same point-in-time content.
- If we need to hit a higher frequency, eg: the cloud and docker images might need to move to a weekly plan ( there is reasonable expectation in the consumer groups for this content to have weekly images ), then we can do that as an additional buildrun, but I want atleast a monthly run for the entire set.
- Development builds, eg. as we work through cloud-init issues on CentOS-6 will also show up under /rolling/ however, we might want to setup a devel/ subtree, so people only interested in consuming known good, non-devel builds are not overloaded and can ignore those easily.
- In case of big-news-security issues like heartbleed, puddle, shellshock ( and all the ones where naming wasent cool ), we can also do point-in-time builds that help get media out for people looking to consume media known patched for those things.
- I've put in quite a bit of effort to make sure that kernel drivers and installtime configs that work at the closest point release continue to work in these builds as well, but all feedback on that welcome and please test it.
Lets use the next 20 odd days and get this process setup, so we can go into 'production' mode with rolling builds starting end of Nov.
Thanks for the effort, this is great!
I personally have no preference on when the images are built as long as they are refreshed regularly.
Any chance the PXE images can also be updated regularly? It's nice to have more up to date drivers in them.
Lucian
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Karanbir Singh" mail-lists@karan.org To: "The CentOS developers mailing list." centos-devel@centos.org Sent: Friday, 7 November, 2014 11:47:38 Subject: [CentOS-devel] Rolling Monthly snapshots
Hi,
I'd like to introduce the idea of rolling monthly builds for install media, cloud, instance and container images.
A generally accepted and expected state of cloud and container images is to update the default stock image on a schedule, something we've not been doing in the past and something that lots of people have been asking for.
In order address this, I'd like to introduce everyone to http://buildlogs.centos.org/rolling/
There is no change to mirror.centos.org rpm repo's; those will stay the way they are.
For right now, these are x86_64 only; on c5 / c6 I will work to bringing in the 32bit builds in as well ( in the coming week ).
Important Note: the CentOS-6 cloud images now include cloud-init and expect user login from user 'centos' instead of the old default of 'root'. Please share comments about how this impacts your existing use case ( and I am very willing to go back to using the root user by default since thats what we've had for a long long time on c5/c6 ). CentOS-5 images remain as they were, no cloud-init and default login is via root. The cloud-init files in this CentOS-6 build are not signed, however they will be released into centos-extras/ and signed before we push these images to final release.
This contains right now :
CentOS-7
- CentOS-7-x86_64-AtomicHost-20141029_02.qcow2
- CentOS-7-x86_64-AtomicHost-20141029_02.qcow2.gz
- CentOS-7-x86_64-GenericCloud-20141029_01.qcow2
and
- CentOS-7-x86_64-DVD-20141029_02.iso
- CentOS-7-x86_64-Everything-20141029_03.iso
- CentOS-7-x86_64-Minimal-20141029_02.iso
CentOS-6
- CentOS-6-x86_64-GenericCloud-20141029_01.qcow2
In the next few days, I will try and get the entire stock of install media ( ie. livemedia and isos ) for the CentOS-6 tree online as well, and then CentOS-5. The aim is to work through the build process and evolve it through this month, to then hit a regular, predictable delivery plan.
These images are built against the mirror.centos.org state as on and including all updates released to the 29th of October ( so as to be a month from the last images. ), however there is good reason to either make it the 28th of every month ( so we are covered for Feb ) or just use the 1st of the month, every month, to include all updates released upto that day ( but not including the 1st ). This would also make it easier to label the images at just YYMM, and we can drop the day of month reference completely.
Couple of key things to note here :
- Whatever date we all decide on, we will use that date in month, to
deliver fresh install media every month, which will contain all updates released from the last media set, rolled in. eg. If someone was to install CentOS-7-x86_64-DVD-20141029.iso, the default installed tree would already pre-include all updates released to that date.
- The aim is to pick a snapshot date, and deliver the entire complement
of media, i.e if someone was to pick Nov '14 as their install point, they would be able to get docker images, vagrant images, cloud images, live media, iso media all with exact same point-in-time content.
- If we need to hit a higher frequency, eg: the cloud and docker images
might need to move to a weekly plan ( there is reasonable expectation in the consumer groups for this content to have weekly images ), then we can do that as an additional buildrun, but I want atleast a monthly run for the entire set.
- Development builds, eg. as we work through cloud-init issues on
CentOS-6 will also show up under /rolling/ however, we might want to setup a devel/ subtree, so people only interested in consuming known good, non-devel builds are not overloaded and can ignore those easily.
- In case of big-news-security issues like heartbleed, puddle,
shellshock ( and all the ones where naming wasent cool ), we can also do point-in-time builds that help get media out for people looking to consume media known patched for those things.
- I've put in quite a bit of effort to make sure that kernel drivers and
installtime configs that work at the closest point release continue to work in these builds as well, but all feedback on that welcome and please test it.
Lets use the next 20 odd days and get this process setup, so we can go into 'production' mode with rolling builds starting end of Nov.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 11/07/2014 12:18 PM, Nux! wrote:
Thanks for the effort, this is great!
I personally have no preference on when the images are built as long as they are refreshed regularly.
cool,
Any chance the PXE images can also be updated regularly? It's nice to have more up to dat
This is in the pipeline, something i want to address once we have a stable process for 5/6/7 rolled images.
My plan was to initially build an net-install like iso, that gives us the installed+updated tree that can still hit the base-os + update tree as well as pxe images and a rescue environ. However, it becomes important to only use those images against a mirror.c.o tree that is either same date or newer than the build date.
Validating this and testing this is going to be semi complex, but its something worth doing for sure. Lets pick up on this in the week of Nov 18th I think.
-
Karanbir Singh -
Nux!