Updated README.md with a section to describe how to update the operator #3
Conversation
Signed-off-by: Jordi Gil <jgil@redhat.com>
|
|
||
|
|
||
| ## Upgrading the operator | ||
| Updating the operator requires a few manual steps due to the need of the operator's RBAC roles to be in sync with the kind of resources in the chart, so that the operator is able to manage them. Unfortunately it is not possible to leverage on the operator-sdk ability to populate the roles based on the resources generated from the chart as the generation fails because the chart contains certain constrains that prevents it from succeeding without running against an live cluster, such as the need to determine the cluster's domain name from the `ingresses.config.openshift.io` object. |
There was a problem hiding this comment.
The Janus-IDP charts expect this to be provided as an argument. We used to do that before and switched to the current method of resolving it ourselves after they incorporated the fix in their chart.
Recently, they've reverted it with the following explanation:
redhat-developer/rhdh-chart#9 (comment)
If this is the only limitation that blocks us, we can evaluate the replacement of it with user's input. In that case, how will that argument be specified? when installed via the operator? As another attribute for the Orchestrator CR?
There was a problem hiding this comment.
It's one of the issues. I agree with their reasoning about access permission to the ingresses.config.openshift.io object. I think we should consider this change by adding a field in the values.yaml and shifting the responsibility to the user to provide the value.
The other issues is that we have conditionals that render objects based on the fields in the values.yaml, most specifically the devmode field.
Barring the cluster.domain issue, there's still the possibility that we could add resources that are only rendered in certain conditions, and the generation of the roles.yaml in the operator-sdk init command won't catch. So for now I don't think we can escape from this particular step.
Also, the verbs generated by helm are too generic (see "*"), which it's not ideal to me. But there's nothing that can be done by helm at this point to identify which verbs are required until the operator is running with a CR instance deployed.
|
Could you add also a section on how to use the operator? can de done in a different PR. |
@masayag PTAL. This new section describes how to update it and push the new controller, bundle and catalog images to the registry. What's missing is how to update the catalog to include the new version once we have it published.