How to factorize code between kops and cluster api?

[remyleone]

/kind feature

1. Describe IN DETAIL the feature/behavior/change you would like to see.

I would like to have documentation about how to have reusable components between kops and cluster api controller. For those both tools there is a lot of overlap in the preparation of a cluster. Is there any documentation/recommendation about how to reuse code between those two projects?

2. Feel free to provide a design supporting your feature request.

I would like to have documentation about the core functions/interfaces that would need to be documented to permit maximum reusability between kops and cluster api.

[hakman]

/assign @justinsb
/kind office-hours

[justinsb]

This is a great question. I don't think we have a "do it this way" answer, but here's my suggestion....

There are broadly two levels in the code; in kOps we have the tasks and the model layer. I think the tasks layer is essentially trying to create a declarative/idempotent abstraction of the cloud provider's RESTful APIs, and the model layer is translating kOps to those tasks.

I think the tasks layer is the best opportunity for reuse. The cloud-provider code would benefit from it, cluster-api would benefit from it, and tasks would also benefit from it. I also work on KCC , which is a set of operators for managing cloud resources on GCP (and AWS has ACK, Azure has ASO), those also map pretty naturally to the tasks layer.

This doesn't necessarily mean reuse of the task layer directly (though it would be an interesting refactor to try once we've done the 1.30 beta and can do big refactors on the main branch). At its most basic it could be copy-and-paste reuse and then we can see whether it is worthwhile doing the bigger refactor.

The idea though is that generally the work to add kOps / cluster-api / cloud-provider support can be split into the work to "translate" those APIs to the cloud-provider APIs, and then the work to drive those cloud-provider APIs in a way compatible with the Kubernetes reconciliation/declarative model. Because the "mapping" involves a different source API, it's always going to be hard to reuse, but the "reconciliation" layer has the same "target" and the same representation (the output of the mapping), so should be much easier to reproduce. My theory is that the reconciliation layer is also more time consuming to implement and generally where there are more bugs, but that is only a hypothesis.

The Kubernetes operator layer is an interesting additional opportunity. I don't know if anyone has tried building cluster-api / cloud-provider support on top of operators; I'm pretty sure nobody has for kOps because it would need some tricks to fake client.Client. But I do think that is possible, so if you wanted to investigate that I'd be very interested in exploring that with you!