search

kube-object-storage / lib-bucket-provisioner

Library for the dynamic provisioning of object store buckets to be used by object store providers.
Apache License 2.0
21 stars 22 forks source link

Discuss library versioning #132

Open jeffvance opened 5 years ago

jeffvance commented 5 years ago

CRDs support multiple versions, though today the lib only defines v1aplha1. Later, we might add v1apha2, v1beta1, and v1. If each of these versions at one time had the storage property set to true then etcd has stored this version and remembers this fact (in the status.storedVersions field).

There are suggested steps to follow when deprecating a CRD version. But we can also use a conversion webhook.

Example:

  1. start out with v1apha1 for the lib and OBC
  2. add version v1alpha2 to the CRD because a new OBC field has been added
  3. but the provisioner still imports v1alpha1 lib
  4. create v1alpha2 OBC

Should the provisioner importing the v1alpha1 version of the lib see the v1alpha2 OBC?. If yes then there are potential compatibility issues. If no then the lib can fail the provisioner's call to NewProvisioner or can ignore this OBC (which will likely remain unowned).

Similarly, the provisioner could be at v1alpha2 of the lib and a v1alpha1 OBC is created. Should this scenario also fail the provisioner?

If version mismatches always fail the provisioner (at least for now) then I see no reason to support multiple versions of the CRDs.

guymguym commented 5 years ago

@jeffvance How can the library provide a webhook when multiple providers are embedding the library in a cluster?

jeffvance commented 5 years ago

@guymguym Good point. I don't think it can. I've updated the original description.

jeffvance commented 5 years ago

cc @screeley44, @copejon, @travisn, @dannyzaken @nimrod-becker

copejon commented 5 years ago

Per Aug 8th meeting - a check on the cluster's CRD version, and failing if unsupported, is a good first step towards figuring out how we're going to handle different provisioners' dependencies on different versions of the API.

The question of who gets to decide the verion(s) of the crd supported within the cluster is not fully resolved. One solution is to create an OLM package and hand the decision to the cluster administrator.

guymguym commented 5 years ago

I think OLM can help here a bit - it has the notion of "owned" vs "required" CRD's for every operator. If you "require" a CRD the OLM will pull it, and its operator, and deploy. So we can create a CSV from the library repo and submit to operatorshub without running an actual operator, only to install the CRD's. Then the CSVs of NooBaa and Ceph and other providers will just "require" that "api-only-operator".

guymguym commented 5 years ago

See OLM docs for owned-crds vs required-crds

travisn commented 5 years ago

The best versioning story IMO to avoid the challenges with CRD versioning is the following:

If this is done, there isn't a need to change the CRD version every time a property changes. By taking this approach, the only reason Rook has changed CRDs versions was to declare stability by moving from alpha to beta to v1.

Since the library is compiled into the operator, the main question in my mind is if two operators are using two different versions of the object bucket CRD. Until we have a stable version, the admin will need to ensure he is only configuring operators that use the same version of the object bucket CRD, right?