Closed kaczyns closed 4 years ago
I just want to point out, that the CLI service is not currently broken - the Kabanero operator continues to support the old way of setting a single version of a collection. However our intention is to deprecate the v1alpha1 API in favor of a v1alpha2 API which only supports the multiple version syntax. The v1alpha2 API will be available soon, but the v1alpha1 API will not be removed for several releases. The CLI service should be converted as soon as is feasible.
Just to be clear - for Kabanero 0.6.0 the Collection
CR instance is no longer supported, so some of what I said earlier about being backwards compatible is no longer true. 0.6.0 uses the Stack
CR which only supports the versions
array.
Should we close this issue as "won't do" for the v1alpha1 and open new issue for similar implemenation for stacks in v1alpha2? If we don't close it, the examples should be updated to be stacks
completed
The Collection CRD v1alpha1 has recently been extended to support a versions array in the spec section. See: https://github.com/kabanero-io/kabanero-operator/blob/88d5ac9139f9fcec09762c46ad6bb8d9a47b1d29/deploy/crds/kabanero_v1alpha1_collection_crd.yaml
Here is a sample usage:
The CLI service needs to be able to parse this information and return multiple versions of the collection back to the CLI on a
list
command. On adeactivate
, a good place to start is probably deactivating all versions of the collection, but ideally the CLI would let the user specify which version, and the CLI service would just deactivate the specific version of the collection that the user asked for.On a
sync
command, it may be necessary to parse multiple repositories. TheKabanero
CRD already supports multiple repositories, but the CLI currently only uses the first one that it finds. The only way currently that there can be multiple versions of the same collection, is to have multiple repositories. For example:Note the second repository, which is pointing to and older version of the collections.