Details
-
Type:
RFC
-
Status: Withdrawn
-
Resolution: Done
-
Component/s: LSST
-
Labels:None
Description
The current required distribution and version for all Linux computers working on the project is CentOS 7. This will EOL via RedHat on June 30, 2024. While this seems to be plenty of time, commissioning will start in earnest on the second half of 2021 and first light is planned for May 2023. We would like to try to avoid upgrading during commissioning and also avoid having a short one-year upgrade time span during the first year of operations. So a "good" upgrade window is now.
That being said, we are attempting a project consensus for two items:
- The upgrade path from CentOS 7 is CentOS 8
- Now is the time to begin the upgrade process (the actual length of the timeline, should also be discussed, but may differ between subsystems. It is probably preferred to end the upgrade by June of 2021).
Attempt at consensus was held during the Commissioning Activities Planning (CAP) meeting on Dec 15, 2020 It was agreed upon during this meeting, that an RFC issue would be generated to begin this discussion.
There are some concerns for the upgrade path. Mainly that CentOS is now following RedHat's lead into the stream version of the distribution. The stream version is part of CentOS's upgrade path, taking over after CentOS 8. However, the EOL for CentOS 8 is May 31, 2029 - which should leave plenty of room, after a few years of operations to either continue onto stream or move onto another distribution (such as Rocky Linux or Ubuntu) depending on what the project wants to do at that point. It has been discussed that the project should wait a few years to see how the stream version is used in the Linux community before moving forward on a decision to switch distributions. EDIT: Please see John Maloney [X] comment below.
Initial discussions in the CAP meeting seemed to determine that upgrading now, was possible for all the subsystems of the project. I would like to confirm the viability of this option for all subsystems. So key personnel of the various subsystems may chased down to confirm this in the comments.
That being said, I may have missed adding key personnel in the watchers list - if you see that someone is missing, please add them. Thanks.
Attachments
Issue Links
Activity
Thanks Joshua Hoblitt - you missed the CAP meeting - but a decision was made there to hold off on updating and continue to use CentOS 7 till operations. This is because CentOS 8 will EOL at the end of this year, so it is really not worthwhile going there. CentOS 7 does have some breathing room and hopefully we can make the decision as to what OS we want to move to during that time. There seems to be a little hiccup with the RPi as Iain Goodenow hasn't found a CentOS 7 for ARM - but maybe he can comment further here.
Anyway, the CAP meeting wanted to put the above decision here for discussion. So if anyone has a dissenting opinion on the matter - please let us know. Otherwise, we will carry on with the plan above.
Also, Thanks for all who commented - we appreciate your input the process. 
Wouter already has a CentOS 7 (aarm64) image for RPI (4), and also a container.
Dave Mills
added a comment - Wouter already has a CentOS 7 (aarm64) image for RPI (4), and also a container. For clarification, Iain can't find an AWS CentOS 7 arm 64 image... which would be for our Jenkins build. Sorry for the confusion.
As I have not seen any more comments on this RFC, I am formally withdrawing it. Thanks all for your input.
I think we need to have some in the trenches experience with centos stream before making a decision. My expectation is that centos 8 stream will be virtually indistinguishable from centos 8/rhel8 in an operational context for physical summit/base hardware as with any of the above will will have to maintain our own mirror snapshots in order to have reproducible installs. I suspect the 2 year support cycle of fedora would probably be fine for things like k8s hosts. I will note that, in the distant past, I have had several bad experiences with ubuntu self destructing upon trivial updates... debian testing may be preferable over ubuntu LTS. I am also not enthusiastic about having to deal with rhel license management but there is at least now a rhel8 docker base image which is redistributable, which makes the containerized situation less miserable.
The reality is that for physical hosts we will almost certainly end up with a heterogeneous mix of centos 7 + <something else(s)>. Which provides a lot of motivation for the <else(s)> it be in the redhat family. For container images, which don't need to worry about in place package updates, networking configuration, etc. and are not attached a configuration management system, the choice – and the cost of change – is vastly less significant.
I am informally hoping to work on getting centos 8 [stream] working with the summit/base puppet tree early in the CY to see how it goes.