[CentOS-devel] Rolling Monthly snapshots

[Karanbir Singh]

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