Add document explaining v1beta1 changes #2902
Conversation
|
|
||
| ### Structured Configuration | ||
|
|
||
| The `Config` field containing the Collector configuration is a string in `v1alpha1`. This has some downsides: |
There was a problem hiding this comment.
I would call out the limitation with kustomize and other tools
There was a problem hiding this comment.
I called it out below, would you prefer it closer to the start of the section?
| ``` | ||
|
|
||
| > [!NOTE] | ||
| > Empty maps, like `debug:` in the above configuration, should have an explicit value of `{}`. |
swiatekm
force-pushed
the
docs/v1beta1-release
branch
from
75d5731 to
528e30e
Compare
docs/crd-changelog.md
Outdated
|
|
||
| There is no need for any immediate user action. The operator will automatically convert existing `v1alpha1` resources to `v1beta1`. | ||
|
|
||
| However, the conversion procedure will leave your resources stored as both versions. Support for `v1alpha1` will be removed in the future. |
There was a problem hiding this comment.
This is not accurate, but rather misleading.
the conversion procedure will leave your resources stored as both versions.
The custom resources stored as v1alpha1 are not automatically updated to v1beta1. The updated or newly written cutom resources will be stored as v1beta1 because it is the new storage version.
I would also link https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#upgrade-existing-objects-to-a-new-stored-version
There was a problem hiding this comment.
Ok, how about:
There is no need for any immediate user action. The operator will continue to support existing `v1alpha1` resources.
In addition, any newly applied `v1alpha1` resource will be converted to `v1beta1` and stored as both versions. The plan is to remove support for `v1alpha1` in a future version, so users should migrate promptly.
(detailed migration guide here)
There was a problem hiding this comment.
I put the link at the end of the guide, as I don't want to immediately force users to digest the rather extensive and technical K8s documentation for this process.
There was a problem hiding this comment.
and stored in the new API version.
docs/crd-changelog.md
Outdated
|
|
||
| ### Migration | ||
|
|
||
| There is no need for any immediate user action. The operator will automatically convert existing `v1alpha1` resources to `v1beta1`. |
There was a problem hiding this comment.
The operator will automatically convert existing
v1alpha1resources tov1beta1.
I would rephrase this. Yes there is conversion webhook but for migration from v1alpha1 to v1beta1 an update on the CR must happen
swiatekm
force-pushed
the
docs/v1beta1-release
branch
from
528e30e to
7082b59
Compare
* Add document explaining v1beta1 changes * Document the CRD stored version migration
* Add document explaining v1beta1 changes * Document the CRD stored version migration
* Add document explaining v1beta1 changes * Document the CRD stored version migration
I ended up adding a more general "CRD changelog" document, with the first entry explaining the v1alpha1 -> v1beta1 transition. We can put other, similar sections in here in the future, for example introducing new CRDs.