What is Happening
Red Hat announced changes to CentOS Linux release structure last week, and I like everyone else around is working through what that means. I have worked with and on CentOS since 2005, and saw a lot of my work in EPEL as helping people in that community able to get things done. This has been a real kick to the guts for a lot of people, and I do not have the words to express myself on this. That said, as a System Administrator, you have to take the Tango Charlie Foxtrot's as they are handed to you, plan what to do next, and execute as efficiently as possible.
Current End of Life Dates for CentOS Releases
The following seem to be the current dates to plan against:
| CentOS Linux Release | Current End of Life |
|---|---|
| CentOS 6 | 2020-11-30 |
| CentOS 7 | 2024-06-30 |
| CentOS 8 | 2021-12-31 |
| CentOS Stream Release | Current End of Life |
| CentOS Stream 8 | 2024-06-?? |
What Do I Need to do Next
Deal with the Grief
At this point, System Administrators need to start making a lot of assessments of what they are using CentOS for, why they are using it, and what are the alternatives to move to. This is hard to do when you are angry, pissed, depressed, betrayed, enraged, apoplectic, or the other dozen emotions that have been going through my head lately. So the first thing one has to do is try to work on those emotions as best you can. Talk them out with someone who can take one more rant from you, write them in a blog you never publish, and go for long walks away from computers for several hours. [There are a lot of other methods too and each person has their own way to deal with this.. but the point is that until you get the emotions out, you can not operate.]
Do an analytical assessment of why you are currently using CentOS Linux
There are a plethora of reasons why people use CentOS in their environments.. and those need to be examined to figure out what you need to do next. Sadly like most environments, I think most System Administrators rarely have time to document these and so when having to redeploy you end up with what seems like an impossible project. Like all Charlie Tango Foxtrot situations, one needs to eat the elephant one bite at a time. I find that the following can help make this easier. For each set of servers/services you answer:
- Who are the consumers of this service or server?
- What do they need from their services?
- What is the amount of change that they can deal with on this service?
- How many systems do I have in this service? How can I break them into smaller chunks?
- Where are my systems? [How are
- What automation can I use to roll out these changes?
- When are upcoming deadlines that my consumers need to deal with
- When are upcoming deadlines I have to deal with?
- What are my alternatives? (This is a larger question needing a breakout sheet of why this alternative, how close is it to meeting my needs, what are the costs involved, when can I switch to it, where can i run it, what do I need to change from what I do now?, etc)
- How long would it take to work these alternatives?
If you have hundreds of servers, then this still looks like a giant load of dung to crawl through. I start with my central Infrastructure server and work my way out.
- Who are the consumers? [I am as use this server to run config scripts to outlying systems.]
- What do they need from their services? [Good uptime and stability so that when an outage happens elsewhere I have a good homebase to work from.]
- What is the amount of change they can deal with on this service? [If I use this as a learning experience, a lot. If I do not have time to learn.. then not a lot.]
- How many systems do I have in this service? 1
- Where are my systems? [Home base is under my desk in my office.]
- What automaton can I use to roll out these changes? Ansible looks like a good choice
- When are upcoming deadlines that my consumers need to deal with? [check with home calendar and mark off dates when I can actually futz with this.]
- When are upcoming deadlines that I have to deal with? 2020-12-31
- What are my alternatives? [Only listing some alternatives.. rationale needs to be filled out]
- CentOS Stream
- Red Hat Enterprise Linux
- Oracle Enterprise Linux
- Springdale Linux
- Rocky Linux (maybe 2020-1Q?)
- Lenix (maybe 2020-1Q?)
- Completely different Linux distribution
- How long would it take to work these alternatives? ... unknown at this time.
This list is a starting point for getting the conversation going with some questions not needed and others needing to be added. Once you have worked out the questions then it is time to work out with each of the stakeholders of your services to answer the questions for themselves and then come to a conclusion. For deadlines to work this out, I would use the rule of thumb I found when dealing with change over of Fedora services with several hundred systems and also previous Tango Foxtrot Charlie changes:
| Step | Soft Deadline | Hard deadline |
|---|---|---|
| Inventory current systems | 2021-01-31 | 2021-02-15 |
| Evaluate alternatives | 2021-02-28 | 2021-03-15 |
| Write automation rules for minimal services | 2021-03-31 | 2021-04-15 |
| Roll out staged minimal new infra using different choices if possible | 2021-04-30 | 2021-05-15 |
| Evaluate rollout and go with best choice | 2021-05-15 | 2020-05-31 |
| Determine convergence planning for additional services | 2021-05-15 | 2020-05-31 |
| Begin Rollout of New Infra | 2021-06-30 | 2021-07-15 |
| Last systems are moved over. | 2021-12-31 | 2020-12-31 |
| Last updates for CentOS-8 | 2020-12-31 | 2020-12-31 |
Note: None of the above is to say 'golly gee, its no problem, you just need to throw away all your other work plans for 2021.' or any similar flipant response. It is only meant as a possible way to deal with this in a sane way. Some ways of converting/change are easier than others, but they all require some work and knowing what the tradeoffs are for each one.
No comments:
Post a Comment