-
Task
-
Resolution: Unresolved
-
Major
-
None
-
None
-
False
-
None
-
False
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
-
-
RHOAM Sprint 67
Issue description:
Currently, applicaitonAuth can be used to create a new user_key in 3scale application that was created via CR.
The applicationAuth contains references to secret which has the user key and application key.
When created, operator calls 3scale on behalf of applicationAuth CR and updates the user_key with the one specified in the secret.
Issue 1:
This is a one time operator only and operator does not ever re-reconcile the correctness of the values in 3scale (sync).
We should consider making the secret watched by 3scale operator and react to changes updating the 3scale user_key.
If this is meant to be 1 time only operation, we should provide a "DeleteNow" functionality to the CR like in proxyPromote CRs.
In my opinion, the CR should not be a one time only and should allow customers to edit the user_key in the secret which then, should be updated in 3scale. Additionally, the CR and secret should be reconciled as part of normal reconciliation loop, like in terms of tenant, product, backend etc.
Issue 2:
Since this applicationAuth points to a specific application CR, it makes sense for the applciation CR to be the parent of this CR, meaning that if applicaiton CR is deleted, the applicationAuth should also be deleted
Issue 3:
During reconciliation of applicationAuth, when the initial reconciliatino is done and value of user_key has been updated, if applicationAuth CR is removed and re-created with just a new user_key value, the operator updates the user_key but fails on subsequent call.
This causes operator to keep reconiciling applicaitonAuth indefinitely and pushes the token on every reconcile, which means that even if user decided to update the token via ui/api, the token would get reverted. This is a problem because the functionality is entirely different when there is no error in reconciler vs when there is an error.
We should find a common ground on how we handle error/successful reconciliation and stick to it.