Recently I talked to @ananace and @magnus about OS supported ending. Then I remember that my Fedora 40 machine started to yell at me it was unsupported. That was actually a very nice. It turns out this is supported in /etc/os-release starting systemd v252 via SUPPORT_END. Now I’m thinking about how we would integrate this into Foreman. This is not a concrete RFC but really one where I’m looking for ideas.
My first idea is that you can upload facts from the host. We already create the OS that way. For that, I opened a PR:
If this is added, we can enhance Foreman’s fact parser to store this data for every host. While for now not many operating systems provide this info today, it could be great in the future. Then you can create reports of operating systems going out of support in the next 3 months, 6 months or year. That can be good for capacity planning because large migrations take time.
It also feels natural to store this information on the Foreman operating system itself, but it may also be tricky because you have standard support vs extended support. You may not want to pay for extended support for all your servers, but do pay for some.
I haven’t operated a production Foreman in quite some time so I need feedback from people closer to the field. I’d love to hear your thoughts.
Hooking it through the incoming fact parser definitely looks like a sane way of doing it.
For OSes that don’t have the data available as on-machine facts - e.g. Windows - it could be injected from a plugin as part of the parsing.
I would like it if whatever implementation is done supports tracking more than just End-of-Life, since it can be equally important to be able to document when an OS goes “Security updates only” - as well as when a potential “Extended Support” ends.
I don’t see automatically populating that data as a necessity, but having a way to at least specify dates like those manually or through a plugin would be great.
(Could also be done with an OS facet )
Another option with the facts would be to drop an external fact on a system which does not provide the information, which would be a very simple way to add this information or if I remember correct even to override it if required.
I would also introduce a new state for it (or does adding it to the calculation of an existing one make sense?), so it affects the global status, just because people react on red!
Yes, living in code of the project itself is likely not the best way. Seeing all the old, hopefully not used anymore distributions, but not EL10 should be prove enough.
I think getting a bit more solid information and being able to be consistent in that information that’s already there would be a good start, eg: currently the foreman global hosts screen is not able to detect OS version and platform consistently
shows 24.04.1 - when as you can see it’s actually 24.04.2
these things matter as we saw with 22.04 where there difference between .[1,2] and .3 where significant.
if you look at these test shots you can see one device shows up a system product, and the others show up as PI4B 8GB, I have to put these in manually so I could identify the different platforms as they where undetected using both ubuntu and debian.
I love the idea in this thread and to see it move to a real RFC and implementation, but I believe getting the basics consistent and stable
you can see this is also a recent question / issue faced by an ansible fact user rather than puppet
I love the idea and think it would add real value from both awareness but also important functions like auditing where you could see at a glance your estate, which ones are coming close to EOL and when.
but I’d also support a tidy-up / solidification of current reporting to be stable and constant or at worst solid documentation for what users must do (custom fact, concat to facts etc) to be able to make this consistent and dependable
sorry - I didn’t mean they where part of this, it was more I think your suggestion is a good idea, but before adding more functionality/extra scope, it would be nice to solidify the existing functionality.
)
