1

Is it ok for a v1 CRD to have data structure dependency to a struct defined in v1beta1 package?

v1 looks like this:

    type MyCRDSpec struct {
        Field1  *v1beta1.MyCustomStruct1   `json:"field1,omitempty" validate:"dive"` //dependency to v1beta1 package
        Field2  []*v1beta1.MyCustomStruct2 `json:"field2,omitempty" validate:"dive"`
    }

The point is that I want every change made in v1beta1 propagate to v1 and viseversa, so it makes sense for both of them to use same data structures to avoid duplication in code.
On the other hand I don't know this direction of dependency makes sense or not.
Finally, my question is that should I keep v1 CRDs dependencies to v1beta1 or they must be complitly decoupled?

mammad
  • 175
  • 8

2 Answers2

0

It's best to keep your v1 CRDs completely decoupled from the v1beta1 package, and define your data structures in the v1 package instead.

V1beta1 is considered an unstable API version, and changes in this package are expected to be made frequently during the beta phase. If you rely on the v1beta1 package in your v1 CRD, any changes made to the v1beta1 package could potentially break your v1 CRD.

One recommended solution is to define your data structures in the v1 package and have the v1beta1 package use these data structures. In this way, any changes made to the data structures in the v1 package will propagate to the v1beta1 package automatically, without the need for any additional work.

Jishan Shaikh
  • 1,572
  • 2
  • 13
  • 31
0

Since you use MyCustomStruct1 and MyCustomStruct2 from module v1beta1 and it's versioned in your go.mod, I would suggest using the external module directly without any code duplication. Your code will break only if the maintainers of v1beta1 violates semantic versioning and update & re-tag the same version.

If you decide to upgrade the version of the external package later, you can do it by updating it's version from your go.mod.

tuna
  • 136
  • 7