search

stackhpc / magnum-capi-helm

Magnum driver using capi-helm-charts
Apache License 2.0
2 stars 4 forks source link

Flexbility of apiversion in Custom Resources #25

Open dalees opened 1 year ago

dalees commented 1 year ago

When CAPI or CAPO providers release new versions, we'll want to use a newer apiversion for Custom Resources.

The current Magnum driver implements K8s API client with Classes that have a fixed value for api_version. This makes it easy to request directly into the K8s API for named values that match these objects.

However, when upgrading CAPI/CAPO we'll have some resources in the CAPI management cluster with the older apiversion (eg. cluster.x-k8s.io/v1beta1) and we'll update Helm charts to start creating new apiversion objects (eg. cluster.x-k8s.io/v1beta2).

Magnum will be regularly fetching these resources by apiversion and name. This will either fail to fetch the new ones (with an old Magnum deployment), or fail to fetch the old ones. A re-creation and cutover event must take place to be able to use the new cluster.x-k8s.io/v1beta2 apiversion (which will need to happen on CAPI management Resources, Magnum codebase and Helm charts simultaneously).

The solution to this may be to use K8s API discovery, so we end up fetching our example Cluster resources by name. Libraries such as https://github.com/kubernetes-client support this discovery.

dalees commented 1 year ago

@mkjpryor I suspect you'll have some helpful background on why kubernetes.py is as it is, and hopefully some ideas on alternative libraries or upgrade strategies.

mkjpryor commented 11 months ago

We should discover the current preferred version from the Kubernetes API - this is actually quite easy. For example, this is how it is done in the asyncio client that we use in all the Azimuth components:

https://github.com/stackhpc/easykube/blob/main/easykube/kubernetes/client/client.py#L55