You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Charms that were rewritten from podspec to sidecar pattern do not require kubeflow-roles-operator to create their aggregation clusterRoles because they are now capable of doing that for themselves using lightkube. In that case, the kubeflow-roles-operator must ensure that on upgrade event, it is removing the aggregation clusterRoles that will be duplicated.
Rationale
Two charms will attempt to create, apply, or patch the same resource, which can cause conflicts.
The text was updated successfully, but these errors were encountered:
hi @DnPlas
In our upgrade guides we are instructing to remove and re-deploy kubeflow-roles charm for this reason you mentioned.
check it out here and here.
We can definitely improve our upgrade story in the future by handling this in the charm with an upgrade event handler. I'll mark this issue as an enhancement and we can pick it up in Kubeflow 1.9.
Charms that were rewritten from podspec to sidecar pattern do not require
kubeflow-roles-operator
to create their aggregation clusterRoles because they are now capable of doing that for themselves using lightkube. In that case, thekubeflow-roles-operator
must ensure that onupgrade
event, it is removing the aggregation clusterRoles that will be duplicated.Rationale
Two charms will attempt to create, apply, or patch the same resource, which can cause conflicts.
The text was updated successfully, but these errors were encountered: