Resource Versioning

[lobkovilya]

Context

Today Kuma resources don’t have versions. Even though on Kubernetes Kuma resources are presented as CRDs with GroupVersionKind, it’s not reflected in the internal Kuma model and that’s why it’s not propagated to Universal. Since we’re about to make some breaking changes related to policy matching, resource versioning is important to have backward compatibility support.

Implementation

Resource versioning could be added by introducing a new field to the Kuma core model. Today it consists of Mesh, Name, and Type. So on Universal when a user creates resource these fields have to be specified:

type: FaultInjection
mesh: default
name: fi1

A new field could be called apiVersion or something else but probably not just a version since it could be treated as object version, not API or type version.

On Kubernetes, the version will be converted to GroupVersionKind, so a new set of CRDs has to be created for every new version.

If a user didn’t specify the apiVersion, an old version called v1alpha1 will be used.

[austince]

Not sure if you already have implementation plans, but I recently used the k8s.io/apimachinery lib's Scheme directly for this with a lot of success, though required some specific code generation that might not be compatible with the current protobuf-first approach. Are you planning on adding the apiVersion to the HTTP paths as well in this?

[lobkovilya]

There are no concrete implementation plans so far :) cool, I'll take a look into k8s.io/apimachinery, do you know if it won't be a problem with Universal?

Are you planning on adding the apiVersion to the HTTP paths as well in this?

yeah, that's a good point, we definitely have to add /v1 prefix for our API

[austince]

k8s.io/apimachinery, do you know if it won't be a problem with Universal?

It should be fine, doesn't use k8s cluster things, just defines ways to map between API versions of a given kind. But does involve a good bit of overhead.

[jpeach]

Since we’re about to make some breaking changes related to policy matching, resource versioning is important to have backward compatibility support.

Do you have an idea about how resource versioning helps the transition to the new policy matching world?

[github-actions]

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.

[github-actions]

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.