PROPOSAL: Shifting & Sharpening Focus - Putting MicroOS First
Hi all, I'm coming to you all with two hats on, speaking as both the Kubic/MicroOS Release person and openSUSE's Kubernetes package maintainer. Before I explain what I propose, I'd like to give a little bit of history just so we're all on the same page. First their was Kubic, openSUSE's attempt at making a Kubernetes focused distro, the community companion to SUSE's CaaSP product. As part of that, this little thing called MicroOS, the transactionally updated OS was spawned as a side project from Kubic. This 'side project' has now become the much bigger deal, with far more interest and activity than the Kubic project that gave birth to it, and spawning its own side efforts, like the MicroOS Desktop. And Kubic's commercial companion, CaaSP, has likewise been superseded by Rancher, who meanwhile work hard on making sure their offerings work on SUSE/openSUSE stuff often without needing repackaging for SUSE/openSUSE. But meanwhile, we carry a whole bunch of weird organisational debt. Most of us are here to talk about MicroOS, but this list is named after kubic. Our devel project in OBS is called devel:kubic, not devel:microos. And our github.com/kubic-project organisation holds a ton of stuff that either arguably shouldn't exist, or is better homed in github.com/openSUSE Therefore I'd like to make the following proposals for us to consider. - Tidy up github.com/kubic-project (I've already started moving many things to github.com/openSUSE or archiving the inactive projects) - Making devel:microos and moving everything MicroOS related there - Creating a MicroOS mailinglist Assuming we collectively agree to the above, I'd also like us to consider the following. I do not really want to maintain seperate Kubernetes packages in openSUSE any more. Therefore I'd like to step back from maintaining those packages. But there is more to it than that. I think the Kubic Project has run its course and people are best served using MicroOS with k3s/RKE direct from Rancher. Personally, I think the best way forward would be to remove the openSUSE Kubernetes packages and wind down the Kubic Project. But, of course, I'm open to the possibility of people disagreeing and wanting to take up that work. Please reach out to me either directly or discuss on this list if you're interested in stepping up. It's quite a bit of work and while I'm not sure it's worth it, I promise to help any motivated folk who disagree with me :) Look forward to hearing what you all think, Richard
------- Original Message ------- On Tuesday, May 3rd, 2022 at 11:03 PM, Richard Brown <rbrown@suse.de> wrote:
Hi all,
I'm coming to you all with two hats on, speaking as both the Kubic/MicroOS Release person and openSUSE's Kubernetes package maintainer.
Before I explain what I propose, I'd like to give a little bit of history just so we're all on the same page.
First their was Kubic, openSUSE's attempt at making a Kubernetes focused distro, the community companion to SUSE's CaaSP product.
As part of that, this little thing called MicroOS, the transactionally updated OS was spawned as a side project from Kubic.
This 'side project' has now become the much bigger deal, with far more interest and activity than the Kubic project that gave birth to it, and spawning its own side efforts, like the MicroOS Desktop.
And Kubic's commercial companion, CaaSP, has likewise been superseded by Rancher, who meanwhile work hard on making sure their offerings work on SUSE/openSUSE stuff often without needing repackaging for SUSE/openSUSE.
But meanwhile, we carry a whole bunch of weird organisational debt.
Most of us are here to talk about MicroOS, but this list is named after kubic.
Our devel project in OBS is called devel:kubic, not devel:microos.
And our github.com/kubic-project organisation holds a ton of stuff that either arguably shouldn't exist, or is better homed in github.com/openSUSE
Therefore I'd like to make the following proposals for us to consider.
- Tidy up github.com/kubic-project (I've already started moving many things to github.com/openSUSE or archiving the inactive projects)
- Making devel:microos and moving everything MicroOS related there
- Creating a MicroOS mailinglist
Assuming we collectively agree to the above, I'd also like us to consider the following.
I do not really want to maintain seperate Kubernetes packages in openSUSE any more.
Therefore I'd like to step back from maintaining those packages. But there is more to it than that.
I think the Kubic Project has run its course and people are best served using MicroOS with k3s/RKE direct from Rancher.
Personally, I think the best way forward would be to remove the openSUSE Kubernetes packages and wind down the Kubic Project.
But, of course, I'm open to the possibility of people disagreeing and wanting to take up that work.
Please reach out to me either directly or discuss on this list if you're interested in stepping up.
It's quite a bit of work and while I'm not sure it's worth it, I promise to help any motivated folk who disagree with me :)
Look forward to hearing what you all think,
Richard
Hi Richard, After a quick chat yesterday I do see your point (https://t.me/openSUSE_MicroOS_Desktop/14845). The only thing I would miss from a k3s-MicroOS system is kubicctl which IMO really gives the edge over other k8s distributions. If the project does reach EOL I would be quite happy to work on a similar solution for MicroOS and k3s. If, however, the contributors of the project decide to keep it alive, and maintain it I would be also happy to help. Although I have very little experience with openSUSE tools (which is shameful at this point really) I'm happy to learn. Either way I respect your decision, and gladly help out wherever I can. Br, A.
Hi Richard, Richard Brown <rbrown@suse.de> writes:
Hi all,
I'm coming to you all with two hats on, speaking as both the Kubic/MicroOS Release person and openSUSE's Kubernetes package maintainer.
Before I explain what I propose, I'd like to give a little bit of history just so we're all on the same page.
First their was Kubic, openSUSE's attempt at making a Kubernetes focused distro, the community companion to SUSE's CaaSP product.
As part of that, this little thing called MicroOS, the transactionally updated OS was spawned as a side project from Kubic.
This 'side project' has now become the much bigger deal, with far more interest and activity than the Kubic project that gave birth to it, and spawning its own side efforts, like the MicroOS Desktop.
And Kubic's commercial companion, CaaSP, has likewise been superseded by Rancher, who meanwhile work hard on making sure their offerings work on SUSE/openSUSE stuff often without needing repackaging for SUSE/openSUSE.
But meanwhile, we carry a whole bunch of weird organisational debt.
Most of us are here to talk about MicroOS, but this list is named after kubic.
Our devel project in OBS is called devel:kubic, not devel:microos.
And our github.com/kubic-project organisation holds a ton of stuff that either arguably shouldn't exist, or is better homed in github.com/openSUSE
Therefore I'd like to make the following proposals for us to consider.
- Tidy up github.com/kubic-project (I've already started moving many things to github.com/openSUSE or archiving the inactive projects)
- Making devel:microos and moving everything MicroOS related there
- Creating a MicroOS mailinglist
Assuming we collectively agree to the above, I'd also like us to consider the following.
I do not really want to maintain seperate Kubernetes packages in openSUSE any more.
Therefore I'd like to step back from maintaining those packages. But there is more to it than that.
I think the Kubic Project has run its course and people are best served using MicroOS with k3s/RKE direct from Rancher.
Personally, I think the best way forward would be to remove the openSUSE Kubernetes packages and wind down the Kubic Project.
I personally don't have any stakes in the kubernetes packages, but I do care about the whole podman+buildah, docker+containerd and potentially nerdctl stack. What about those? Do you plan to remove those as well from devel:kubic? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
Hi Dan, On 06.05.22 at 08:44 Dan Čermák wrote:
Personally, I think the best way forward would be to remove the openSUSE Kubernetes packages and wind down the Kubic Project.
I personally don't have any stakes in the kubernetes packages, but I do care about the whole podman+buildah, docker+containerd and potentially nerdctl stack.
What about those? Do you plan to remove those as well from devel:kubic?
I just asked a similar question in my reply, as things like helm and kubie and other kubernetes-related packages do not fit into devel:microos IMHO. Putting everything into Virtualization:containers might be messy, maybe something like Kubernetes_Tools might be a good idea? But keeping devel:kubic just for such packages if the project is torn down seems wrong. Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Richard, On Tue, 2022-05-03 at 18:03 +0200, Richard Brown wrote:
I think the Kubic Project has run its course and people are best served using MicroOS with k3s/RKE direct from Rancher.
I am a happy user of Kubic and sad to see this change of direction. But, as they say, s/problem/opportunity/g . When you say 'k3s(/RKE) direct from Rancher', does that imply that there are going to be no k3s binary packages in MicroOS? I would obviously strongly prefer having an RPM package compared to downloading binaries or piping URLs through curl. Thanks, Robert
Hi Robert, On 06.05.22 at 13:15 Robert Munteanu wrote:
When you say 'k3s(/RKE) direct from Rancher', does that imply that there are going to be no k3s binary packages in MicroOS? I would obviously strongly prefer having an RPM package compared to downloading binaries or piping URLs through curl.
I think what Richard means is that there is no need to maintain yet another kubernetes distribution with packages for three minor versions at the same time. There are packages for k3s, rke, rke2 in Tumbleweed/MicroOS. I am maintainer of the latter two, although I do not use them as regularly as I would like to. I personally install k3s or rke2 via ansible, but that is just personal preference. (I built some roles myself as I needed them for some demo setups. For this purpose they worked, and I used them to setup my kubernetes clusters at home on openSUSE MicroOS) Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Johannes, On Fri, 2022-05-06 at 14:18 +0200, Johannes Kastl wrote:
Hi Robert,
On 06.05.22 at 13:15 Robert Munteanu wrote:
When you say 'k3s(/RKE) direct from Rancher', does that imply that there are going to be no k3s binary packages in MicroOS? I would obviously strongly prefer having an RPM package compared to downloading binaries or piping URLs through curl.
I think what Richard means is that there is no need to maintain yet another kubernetes distribution with packages for three minor versions at the same time.
There are packages for k3s, rke, rke2 in Tumbleweed/MicroOS. I am maintainer of the latter two, although I do not use them as regularly as I would like to.
That more or less answers my question, thank you. If the RPMs for k3s will still be available for MicroOS, then I can structure my installation flow around them. Thanks, Robert
Hi Richard, On 03.05.22 at 18:03 Richard Brown wrote: [too much to quote without leaving out some aspect...]
Look forward to hearing what you all think,
I personally switched from kubic to running k3s on MicroOS last year, as my "special setup" was not reflected by kubicctl (three node cluster with only control plane, no separate workers). Salt threw errors when I had to replace one node and I did not have enough time to fix it. As I wanted to try out k3s anyway I switched. I find kubic/kubicctl a fascinating piece of technology, but I think it is lacking the user base to get as much support as needed. (But maybe the userbase will shout at me and will prove me wrong... :-) ) Keeping up with Kubernetes development and allowing to finetune the many settings is a hard task and might not be feasible. So, I think it is a reasonable approach to focus on MicroOS and rather test that k3s/rke/rke2 are fully working on it, including selinux and other funny things. One thing that we should consider is where to put the many many kubernetes-related packages that are currently residing in devel:kubic. Those will not fit into devel:microos, I guess. Things like helm, k3s, rke, rke2, kubie, cilium-cli, cmctl and a whole heap of others. Have a nice weekend, everyone! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (5)
-
Attila Pinter -
Dan Čermák -
Johannes Kastl -
Richard Brown -
Robert Munteanu