Allow a tenant and/or service to be marked as "Managed by Operator"

Operator is a normal API user. Any other tool can be used to manage 3scale objects via API. Our authentication is based on user access token, not on a particular resource. So restricting other API access to the object is outside the scope of this issue and would involve 3scale authentication to change completely so that would be a separate discussion.

The implementation we agreed upon as the first step was:

• when creating and updating objects (we start with a few more prominent ones, probably Account, Backend, and Service), add ability to annotate as managed by "..." which might be operator or another tool
• UI will highlight objects managed by "..." and possibly require confirmation for update operations
• because operator presently does not manage every object under account/product/whatever, we will annotate individual objects but not hierarchy
• next step is for system to implement the API capability, and then operator will use that in case it is suitable for the purpose

Also:

• The operator needs to reconcile that new attribute of the 3scale object.
• The operator team needs to decide if that new attribute will always be added or depends on something else. Maybe they want to enable only when some new annotation in the CR is there, or new field in the spec of the CR.
• In any case, upon upgrade, the operator will reconcile all the existing CR's and for those where the new attribute has been enabled, the operator will update the objects in 3scale to enable the UI warning

================== ORIGINAL DESCRIPTION ==================

By being able to mark a resource as "managed by an operator" we will be able to restrict changes to some of those resources either by the UI or external API clients and simplify the reconciliation loop of the Operator.

This improvement can be provided as an optional parameter on tenant/service creation via API.

By doing that, we would be able to create a ReadOnly UI for resources managed by the operator, improve the UX, so the User can understand why changes are not being applied or overwritten, etc.

–

Update: This is one of the proposed solutions to the CR being the source of truth and letting users make changes in the UI, which will be overridden by the operator with what's in the CR.

This problem has been highlighted in slide 42 here https://docs.google.com/presentation/d/1sVUBeQvP0--u1WUF6A97GYiEGEDERUSJ6qn3eiyD6KE/edit#slide=id.g50db5a137a_0_159
and it should be discussed for consistency across products.

In 3scale we've discussed this and below is a summary of our current thinking (4/26):

• Ideal solution would be that the source of truth are the CRs and both the operator and the UI are based on what's defined there.
• Another good solution would be to manage this with proper RBAC so users of an instance operated by the operator only get read access.
• Short term, none of these seem feasible from a technical point of view.
• 3 way merge doesn't seem a good fit, it defeats the purpose of having operators.
• The short term solution proposed is what's reflected in the title of this issue ' Allow tenant and/or service to be marked as Managed by Operator' so when that happens and a user attempts to edit the UI, they'll see a warning that they shouldn't make changes in the UI because the operator will override with whatever is defined in the CR.

Dev note

Add a new endpoint. First implementation can be be simply adding a flag to the Account, Backend, and Service data models. As a first iteration that flag would be only informative, meaning it would NOT make the objects read-only in the System UI although they would be visibly flagged.
This tagging can also include metadata inserted by the operator, for example, data about the operator in question (which could also be included in the UI).
The user could still go through the UI or API to modify the objects but changes could get lost...

Making the objects actually read-only based on that flag would be much more complicated and not recommended for the first implementation. 2-way synchronization is even more complicated than that and also not recommended for the first implementation.

models: https://github.com/3scale/3scale-operator/blob/master/doc/api-crd-reference.md

See also https://issues.redhat.com/browse/THREESCALE-8297

See also https://docs.google.com/document/d/1ZMZxp7J0-1tL-m0UthexVxq___Wu6ZRsHZSXSUDvdiE/