Skip to content
Snippets Groups Projects
Verified Commit 004d3808 authored by Alex Iribarren's avatar Alex Iribarren
Browse files

Replace C8 page for CS8

parent ddd35f03
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
docs/distributions/c8.md → docs/distributions/cs8.md
+ 104
− 0
View file @ 004d3808
# CentOS 8 # CentOS Stream 8
## Practical info ## Practical info
...@@ -7,11 +7,11 @@ ...@@ -7,11 +7,11 @@
## Upstream updates ## Upstream updates
Upstream updates are handled by a [Nomad job](https://gitlab.cern.ch/linuxsupport/cronjobs/centos8_snapshots/). Upstream updates are handled by a [Nomad job](https://gitlab.cern.ch/linuxsupport/cronjobs/stream8_snapshots/).
The job runs automatically every day at 8am. It creates daily snapshot directories The job runs automatically every day at 8am. It creates daily snapshot directories
in `/mnt/data1/dist/cern/centos/8-snapshots/` and maintains the symlinks from `8`, in `/mnt/data1/dist/cern/centos/s8-snapshots/` and maintains the symlinks from `s8`,
`8-testing`, etc. to the appropriate daily snapshot. The `-testing` symlinks `s8-testing`, etc. to the appropriate daily snapshot. The `-testing` symlinks
point to that day's snapshot (see note), and the production (ie. non -testing) point to that day's snapshot (see note), and the production (ie. non -testing)
ones point to the previous Wednesday's snapshot. Production symlinks are changed on ones point to the previous Wednesday's snapshot. Production symlinks are changed on
Wednesdays and ensure packages spend at least 7 days and at most 13 days in testing. Wednesdays and ensure packages spend at least 7 days and at most 13 days in testing.
...@@ -24,14 +24,14 @@ Wednesdays and ensure packages spend at least 7 days and at most 13 days in test ...@@ -24,14 +24,14 @@ Wednesdays and ensure packages spend at least 7 days and at most 13 days in test
### Stopping modifications to symlinks ### Stopping modifications to symlinks
Changes to symlinks can be manually stopped by creating `.freeze.*` files in Changes to symlinks can be manually stopped by creating `.freeze.*` files in
`/mnt/data1/dist/cern/centos/`. You can create the file `.freeze.8all` to stop `/mnt/data1/dist/cern/centos/`. You can create the file `.freeze.s8all` to stop
updating all symlinks, or create specific ones for each symlink (ie. `.freeze.8`, updating all symlinks, or create specific ones for each symlink (ie. `.freeze.s8`,
`.freeze.8.0.1905-testing`, etc.). `.freeze.s8.0.1905-testing`, etc.).
A `.freeze.8all` may be created automatically in certain conditions, such as a A `.freeze.s8all` may be created automatically in certain conditions, such as a
validation failure, detection of a "dangerous" RPM (see below), etc. When this validation failure, detection of a "dangerous" RPM (see below), etc. When this
happens, an email will be sent to lxsoft-admin explaining the cause. You will happens, an email will be sent to lxsoft-admin explaining the cause. You will
have to take manual action to resolve the situation and remove the `.freeze.8all` have to take manual action to resolve the situation and remove the `.freeze.s8all`
so the process can continue. so the process can continue.
### *-release packages: the "dangerous" RPMs ### *-release packages: the "dangerous" RPMs
...@@ -49,10 +49,10 @@ As a general rule, when creating a new one, you will need to change the repo fil ...@@ -49,10 +49,10 @@ As a general rule, when creating a new one, you will need to change the repo fil
the corresponding URL from CERN and add the GPG keys. You will also need to add a high epoch the corresponding URL from CERN and add the GPG keys. You will also need to add a high epoch
to make sure CERN's RPM has priority. Use `centos-release` as an example. The source code of to make sure CERN's RPM has priority. Use `centos-release` as an example. The source code of
the upstream packages can be found in the [CentOS git repositories](https://git.centos.org/), the upstream packages can be found in the [CentOS git repositories](https://git.centos.org/),
in the `c8` branch. in the `c8s` branch.
Once the new version of a release package is built and tagged as stable, you can Once the new version of a release package is built and tagged as stable, you can
delete the `.freeze.8all` file and rerun the Nomad job. This time, it will find delete the `.freeze.s8all` file and rerun the Nomad job. This time, it will find
your new RPM in the CERN repo and continue the process. your new RPM in the CERN repo and continue the process.
### Seeing differences between snapshots ### Seeing differences between snapshots
...@@ -61,7 +61,7 @@ You can see all the packages that changed between two dates using the `snapshotd ...@@ -61,7 +61,7 @@ You can see all the packages that changed between two dates using the `snapshotd
command, which is provided by [lxdist-build](https://gitlab.cern.ch/linuxsupport/lxdist-build/-/tree/master/bin): command, which is provided by [lxdist-build](https://gitlab.cern.ch/linuxsupport/lxdist-build/-/tree/master/bin):
```bash ```bash
[build@lxsoftadm01] snapshotdiff -d 8 -s 20200701 -e 20200709 [build@lxsoftadm01] snapshotdiff -d s8 -s 20200701 -e 20200709
Calculating diff between 20200701 and 20200709... Calculating diff between 20200701 and 20200709...
apache-sshd 2.5.1-1.el8 apache-sshd 2.5.1-1.el8
...@@ -83,7 +83,7 @@ will not be moved backwards in time, but it will move forward again as necessary ...@@ -83,7 +83,7 @@ will not be moved backwards in time, but it will move forward again as necessary
For instance, on Wednesday the 8th, the production symlinks would point to Wednesday For instance, on Wednesday the 8th, the production symlinks would point to Wednesday
the 1st. On Thursday the 9th an emergency security patch is released and you manually the 1st. On Thursday the 9th an emergency security patch is released and you manually
modify the production symlinks to point to that Thurday's snapshot. The links will modify the production symlinks to point to that Thursday's snapshot. The links will
continue pointing to that day even on Wednesday the 15th, where they should continue pointing to that day even on Wednesday the 15th, where they should
been moved to the 8th but won't be because they're never moved backwards in time. been moved to the 8th but won't be because they're never moved backwards in time.
On Wednesday the 22nd they would be moved to Wednesday the 15th as usual. On Wednesday the 22nd they would be moved to Wednesday the 15th as usual.
...@@ -96,95 +96,9 @@ and run: ...@@ -96,95 +96,9 @@ and run:
```bash ```bash
# cd /mnt/data1/dist/cern/centos # cd /mnt/data1/dist/cern/centos
# echo "20200709" > .forcemove.8 # echo "20200709" > .forcemove.s8
``` ```
Once that file is created, rerun the [snapshotting cron job in Nomad](https://lxsoftadm.cern.ch:4646/ui/jobs/prod_centos8_snapshots). It will see Once that file is created, rerun the [snapshotting cron job in Nomad](https://lxsoftadm.cern.ch:4646/ui/jobs/prod_stream8_snapshots). It will see
this file, set the production symlinks to that date, and then delete the `.forcemove.8` this file, set the production symlinks to that date, and then delete the `.forcemove.s8`
file. The job will also send the usual emails and update the web site. file. The job will also send the usual emails and update the web site.
## 'Minor' (8.x -> 8.x+1) version release process
The daily update process will do most of the work when a new CentOS 8 minor release
is published, but there are still some things that will have to be done by hand.
### On the day the release is published by upstream
By the time CentOS announces the new release, our local mirror will already have all
the new RPMs. We can already prepare things for a smooth rollout the following day:
* Create a new VM with the current CentOS 8 release. We will use it for testing the upgrade.
```bash
[aiadm52] ~ > eval `ai-rc "IT Linux Support"`
OpenStack environment variables set for Project = 'IT Linux Support'
[aiadm52] ~ > openstack image list --property os_distro=C --property os_distro_major=8
+--------------------------------------+--------------------------+--------+
| ID | Name | Status |
+--------------------------------------+--------------------------+--------+
| 708ba85e-dc9b-49c9-ad73-d645aa87dd67 | C8 - x86_64 [2020-06-01] | active |
+--------------------------------------+--------------------------+--------+
$ openstack server create --image "C8 - x86_64 [2020-06-01]" --flavor m2.small --property cern-waitdns=false --key-name my-key test-c83
...
```
* Once that VM is spawned, connect to it, point it to the current testing repos and update it:
```bash
[aiadm52] ~ > ssh root@137.138.54.59
Enter passphrase for key '/afs/cern.ch/user/a/airibarr/.ssh/id_rsa':
X11 forwarding request failed on channel 0
[root@test-c83 ~]# cat /etc/dnf/vars/cernbase
8
[root@test-c83 ~]# echo ".8-testing" > /etc/dnf/vars/cernbase
[root@test-c83 ~]# dnf clean all && dnf distro-sync -y
0 files removed
CentOS-8 - CERN 388 kB/s | 43 kB 00:00
CentOS-8 - AppStream 18 MB/s | 5.8 MB 00:00
CentOS-8 - Base 20 MB/s | 2.2 MB 00:00
...
```
* As part of the new CentOS RPMS, there will be a new `centos-release` which [needs to be rebuilt](#-release-packages-the-dangerous-rpms). There may be other `*-release` RPMs to rebuild as well. When you build the packages through Koji, they will automatically be tagged to `cern8-testing`.
* There will also be a new `kernel`, so a new `kmod-openafs` will need to be built and tagged to `openafs8-testing`.
* Once that is done, you can go back to your VM and test that the upgrade works as expected. For this, we will use the very latest upstream repos:
```bash
[root@test-c83 ~]# echo ".8-upstream" > /etc/dnf/vars/cernbase
[root@test-c83 ~]# dnf clean all && dnf distro-sync -y
CentOS-8 - CERN 135 kB/s | 32 kB 00:00
CentOS-8 - AppStream 13 MB/s | 5.8 MB 00:00
CentOS-8 - Base 6.7 MB/s | 2.2 MB 00:00
...
```
Note that if you're late in doing this and today's snapshot already contains the latest release, you should use `.8-latest` instead of `.8-upstream`.
* New AIMS images need to be published. Grab the images from the new release's
`/BaseOS/x86_64/kickstart/images/pxeboot/` directory.
```bash
$ wget http://linuxsoft.cern.ch/cern/centos/8.4/BaseOS/x86_64/kickstart/images/pxeboot/{vmlinuz,initrd.img}
...
$ aims2 addimg --testserver --name C84_X86_64_TEST --arch x86_64 --vmlinuz vmlinuz --initrd initrd.img --description "CENTOS 8.4 X86_64 TEST" --uefi
$ aims2 addimg --name C84_X86_64_TEST --arch x86_64 --vmlinuz vmlinuz --initrd initrd.img --description "CENTOS 8.4 X86_64 TEST" --uefi
```
* You may want to do the same with aarch64, but you will not be able to test is as of today due to the lack of HW.
* [Test](/aims2/addinganewimage#testing-a-new-image) the new images
### On the following day
If you did all those things yesterday, today you can congratulate yourself and
go home early. There are just a few more things to do:
* Check that nothing stopped the snapshot process, that the website reflects the
[latest updates](https://linux.web.cern.ch/updates/c8/test/latest_updates/) and that the automatic email to `linux-announce-test@cern.ch` was sent. The new release should now be `8-testing`.
* Send an email to `linux-announce@cern.ch` and `linux-announce-test@cern.ch`
announcing the new version and the date that it will become production. Include a link to the release notes.
* Add the email you just sent to the [news section](https://gitlab.cern.ch/linuxsupport/websites/linux.cern.ch/-/blob/master/docs/index.md) of the website.
* Let the Config team know that they need to prepare the provisioning templates and rename the OS in Foreman.
### On the day the new release becomes production
Today the new CentOS release becomes production. Just a few more things to do:
* Reupload the AIMS images, but this time without the TEST suffix.
* Reupload the latest release as the LATEST image.
* Add entries for previous release to [AIMS hostgroup Hiera data](https://gitlab.cern.ch/ai/it-puppet-hostgroup-aims/-/blob/qa/data/hostgroup/aims.yaml).
* Remove the previous TEST images.
mkdocs.yml
+ 1
− 1
View file @ 004d3808
...@@ -24,7 +24,7 @@ nav: ...@@ -24,7 +24,7 @@ nav:
- 'Service Alarms': tasks/alarms.md - 'Service Alarms': tasks/alarms.md
- 'Distributions': - 'Distributions':
- 'CC7': distributions/cc7.md - 'CC7': distributions/cc7.md
- 'C8': distributions/c8.md - 'CS8': distributions/cs8.md
- 'Docker images': distributions/docker.md - 'Docker images': distributions/docker.md
- 'OpenStack': distributions/openstack.md - 'OpenStack': distributions/openstack.md
- 'Architecture': distributions/architecture.md - 'Architecture': distributions/architecture.md
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment