Removing unmaintained projects from image-builder
jsturtevant opened this issue · 11 comments
Is your feature request related to a problem? Please describe.
I would like to propose removing the currently unmaintained projects and simplify this repository. The readme states there are three projects in this repository but this also a command line tool. There has been little to no activity on the projects beyond the Cluster API image builder:
- Image builder for Cluster API
- actively maintained
- kube-deploy/imagebuilder
- not actively maintained since 2021: https://github.com/kubernetes-sigs/image-builder/commits/master/images/kube-deploy
- only owners are kops?
- konfigadm
- no commits since initial project structure: https://github.com/kubernetes-sigs/image-builder/commits/master/images/konfigadm
- cli tool
- no major commits in over a year (and no feature development past initial commit: https://github.com/kubernetes-sigs/image-builder/commits/master/v1)
- We provide a docker image and guidance on how to use that to do deploys. This seems to be working for the majority of users
There has been feedback that the project is difficult to approach as folks are not sure where to begin. Part of this is due to three projects being in the repository and it is difficult to figure out what changes are needed.
Another part of this is that the current maintainers of the project have no experience with the tools outside image-builder folder or have a clear vision for where those projects should go.
Describe the solution you'd like
Remove the code from this project and maybe move the CAPI folder up in the code tree structure (this might be breaking change or difficult so lower prior than remove code).
Describe alternatives you've considered
We could continue to leave them with no commits
- doesn't address the issue of making it hard to know where and how to begin.
- creates confusion
We could move them to new github repositories.
- there are not clear maintainers for the projects so this doesn't achieve much
- If in the future someone wants to the code could still be moved
Additional context
Please comment and let us know if there are any reservations or concerns. I propose we have a lazy consensus period (maybe a month?) and pin this issue to the repository for enough visibility to get any feedback/concerns.
/kind cleanup
I'm generally in favor of removing these unmaintained folders to lower the cognitive overhead of just visiting the project. It doesn't seem worth it to hollow them out or move them to new repos; if there is interest in keeping or improving any of it, community members should speak up and I think that's all it would take for them to stick around.
Having said that, I don't think we're in a hurry and we wouldn't want anyone who cares to be surprised by this. I think lazy consensus of a month or longer is reasonable.
I agree in terms of removing old code that is no longer maintained. As someone who started working with the project back in September, it was a bit confusing at first to see all these extra directories only to discover they're not actually required for CAPI.
If it's no longer being maintained, it seems like extra effort to move it elsewhere for it to potentially go stale "over there".
As for the V1 section, I'm a fan over the CLI approach over the Docker method personally - I have no reasoning for this other than "that's what I do now" 😆.
However, looking at the binary that was being developed in V1, it looks like it was created to replace the process that is managed by packer/ansible etc which seems like a long (and possibly doomed to fail) task due to the complexity already built into the project. Not impossible, just hard and time consuming. So I would also be in favour of removing that too.
FWIW, the one I mentioned during office hours that I'd been working on was to make use of the existing codebase in the images/capi directory not to replace it. Maybe as it matures I can share it with the community and see if that can become the CLI approach we take for the project for those that want/need it.
For now though I feel that all we need in this project is the CAPI work but as @mboersma said there is no rush here. We can take the time to have this decision made on how to move forward with this.
Kops no longer uses kube-deploy/imagebuilder and we can almost certainly remove it from master. We can wait on confirmation from the others for final approval.
Kops uses official OS images these days, so anything kube-deploy/imagebuilder can be removed from our point of view.
I agree with the sentiment here - removing unmaintained code and simplifying the code structure will be good for the overall project health.
Sounds good to me.
Assuming we go ahead and all non-CAPI tools will be removed, I wonder if the repository should be renamed eventually to something like "cluster-api-image-builder". This would clearly signal the association with the Cluster API project going forward.
SGTM
Also, we have some providers likes digital ocean which have not been touched in a couple of years. ibmcloud just has support for centos-7 and inactive for a yr etc etc.
Any thoughts on those?
Also, we have some providers likes digital ocean which have not been touched in a couple of years. ibmcloud just has support for centos-7 and inactive for a yr etc etc.
Any thoughts on those?
I think those should be addressed separately. One thing I would like to see in the future is more consistency and shared code across the different providers. Right now we don't really have any insight on which of these providers are being used by people and which aren't.
/assign
I think those should be addressed separately.
+1