[magnum] Propose deprecation of Docker Swarm, CoreOS, fedora-ironic
Hi, Due to limited resources, Magnum team has decided to put most effort into supporting the most popular use case - Kubernetes on Fedora CoreOS. In light of that, we are seeking maintainers for the less well maintained drivers / COE - Docker Swarm, CoreOS and fedora-ironic drivers. The reasons are as follows: - Docker Swarm - It uses Fedora Atomic which has been EOL [1] - CoreOS - It is EOL [2] - fedora-ironic - Not tested, unsure if it is still working If anyone wants to take up maintenance of any of the above, we will be glad. Please let us know either through the ML or at the Magnum meetings. If there are no suitable maintainers, we will start the deprecation of these before end of Antelope. Regards, Jake [1]: https://projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/ [2]: https://www.redhat.com/en/technologies/cloud-computing/openshift/what-was-co... -- Jake Yip Magnum Team
On 2023-02-22 21:41:59 +1100 (+1100), Jake Yip wrote:
Due to limited resources, Magnum team has decided to put most effort into supporting the most popular use case - Kubernetes on Fedora CoreOS. [...]
I couldn't easily find information on the support lifetime of Fedora CoreOS, but one of the challenges I've heard Magnum users report is that it's hard to use a "supported" stable branch since the bundled operating systems aren't supported by the maintainers of those distros for as long as we claim to support our own projects. When OpenStack 2023.1 is still under normal maintenance almost 2 years from now, will the corresponding version of Magnum work with a Fedora CoreOS that's still getting security vulnerabilities patched? And if not, are there alternatives that are maintained for longer (LTS)? -- Jeremy Stanley
Hi Jeremy, nice to hear from you. On 23/2/2023 9:46 am, Jeremy Stanley wrote:
I couldn't easily find information on the support lifetime of Fedora CoreOS, but one of the challenges I've heard Magnum users report is that it's hard to use a "supported" stable branch since the bundled operating systems aren't supported by the maintainers of those distros for as long as we claim to support our own projects.
To me, this is one of the fundamental issues that Magnum faces - upstream EOL faster than OpenStack. For example, Kubernetes v1.23 was released 2021-12-16, entered EM 2022-12-28 and will be EOL 2023-02-28 [1]. The operating systems also had a huge amount of churn - CoreOS to Fedora Atomic to Fedora CoreOS. (hence this mail to remove dead code). Backports are also an issue. We can (try to) support the latest in master now, but should we backport the support patches and how far back? We have been discussing the 'backport to fix bugs only' practice - is supporting the latest OS in a supported stable branch a 'feature' or a 'bug'? If we choose to backport, we have to test if e.g. code for Fedora CoreOS 37 does not break Fedora CoreOS 35.
When OpenStack 2023.1 is still under normal maintenance almost 2 years from now, will the corresponding version of Magnum work with a Fedora CoreOS that's still getting security vulnerabilities patched? And if not, are there alternatives that are maintained for longer (LTS)?
Magnum Team hopes to solve this problem with ClusterAPI [2]. By turning Magnum into a shim between OpenStack API and ClusterAPI, we hope that this will allow us to leverage upstream effort in supporting the latest Kubernetes / operating systems. Regards, Jake [1] https://kubernetes.io/releases/patch-releases/#1-23 [2] https://cluster-api.sigs.k8s.io/
On 22/2/2023 9:41 pm, Jake Yip wrote:
Hi,
Due to limited resources, Magnum team has decided to put most effort into supporting the most popular use case - Kubernetes on Fedora CoreOS.
In light of that, we are seeking maintainers for the less well maintained drivers / COE - Docker Swarm, CoreOS and fedora-ironic drivers. The reasons are as follows:
Hi all, We have not received any volunteers for these drivers. This is a final attempt on the list; if there is no response in a week, we will continue with our deprecation and subsequent removal of these drivers. Regards, Jake
participants (2)
-
Jake Yip
-
Jeremy Stanley