CentOS 6 deprecation

[bastelfreak]

This issue is a result of #228

CentOS 6 main support is end of life. In the past we removed operating systems when their main support cycle is reached. We never cared about LTS/extended support (like Debian does for oldoldstable or RedHat offers for money). I want to continue this for CentOS 6 and remove it from metadata.json. This will automatically disable unit/acceptance tests for those versions as well. Such a PR should be marked backwards-incompatible. This ensures a major release happens.

[bastelfreak]

@voxpupuli/collaborators please provide feedback :)

[ekohl]

👍 since not a lot of modules still support it. While doing the last modulesync we also saw that a few that did claim support were actually broken.

IMHO we should also drop any compatibility code. Typically this is sysvinit support for the Red Hat OS family since EL7 moved to systemd but there may be more.

[crazymind1337]

Sounds good for me. 👍

[ekohl]

FYI: with VP msync 4.0.0 we automatically enable acceptance tests if they're there for all supported operating systems. In doing so I found a few broken EL6 versions so some modules have dropped it already. To me this is just more proof that with 4.0.0 we're making a big step forward in maintainability of modules.

[b4ldr]

no issue from me dropping EOL OS's

[jhoblitt]

👍 "He's dead, Jim"

[ekohl]

They also removed the vagrant image and dropped it from the mirror networks. That means we can't test it anymore. I've submitted more PRs to drop it.

[bastelfreak]

I'm also +1 for dropping it. In many modules it was already broken, we just didn't test it. All others are now untestable. I don't see us investing a huge amount of time to reimplement acceptance tests + fix existing issues for CentOS 6. Normally I would say a week is enough for such an issue, but given the holidays in the US we might want to keep it open a few more days.

[seanmil]

While CentOS 6 may be EOL, RHEL 6 has years left (in extended support). While much of my codebase is internal I do use a number of Voxpupuli modules as I can and when looking at overhauling modules I do try to look at the community for replacements. Not having support for supported OSes my customers use, even if they are at normal EOL, is a deal-breaker. I'd love to be running only the latest and greatest, but not everyone can dictate the platforms they have to support.

Might I suggest disabling CentOS 6 support for those modules known to be broken, but for those with working tests and capability leave it enabled and continue supporting it until RHEL 6 EOL?

I don't, however, have a great suggestion on what to do given the removal of the vagrant image.

My 2 cents worth. Thanks!

[ekohl]

Without the ability to test it, it's really hard. Remember that we can't use RHEL in our CI. CentOS mirrors are offline for EL6. Quoting https://lists.centos.org/pipermail/centos-devel/2020-December/056208.html:

Just to let you all know that starting from today, mirrorlist.centos.org nodes answer "Invalid release/repo/arch combination" and also that content was removed from mirrors. Johnny pushed the last updates yesterday, that went out to external mirrors .

Today most modules are struggling even to get by. Maintainers like myself don't even know the projects and have to rely on tests, preferably acceptance tests.

I'd love to hear a better solution.

I have been thinking about how to better deal with that. I often get back to the concept of maintainers for sets of modules. Let's say I depend on extlib, nginx and unattended_upgrades. It should be possibly for me to be recognized there. This means some modules can have a bit different policy (support EL6 for longer or similarly, Puppet 5) but those maintainers would be responsible for it. To me that's open source: you need it, you make sure it happens. If you don't, there's no guarantee.

If you're formally recognized (for example, via CODEOWNERS), then it also comes with some responsibility. For example, if a modulesync fails or a build breaks, you should be ready to help fix it.

[attachmentgenie]

i believe with the upstream infrastructure being removed the discussion is now moot. We pride ourselves in being a test driven organisation. So not being able to test is a road block we wont be able to overcome easily. Bar for some sponsor stepping up and keeping extensive mirror infrastructure in place for this to work. RHEL support IMHO has always only been by proxy due it being compatible with centos.

[btravouillon]

The upstream repos are still available at https://vault.centos.org/centos/6/.

[roidelapluie]

I 👍 the removal too

[seanmil]

i believe with the upstream infrastructure being removed the discussion is now moot. We pride ourselves in being a test driven organisation. So not being able to test is a road block we wont be able to overcome easily. Bar for some sponsor stepping up and keeping extensive mirror infrastructure in place for this to work. RHEL support IMHO has always only been by proxy due it being compatible with centos.

How extensive of a mirror system are you looking for? Would two Internet accessible hosts in different datacenters with a mirror of the CentOS 6 vault be sufficient? No promises, but I could look into providing them.