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
Currently RFC006 is only partially implemented and there has being number of issues/side affects raised by the current implementation. I still think there is a good reason for implementing RFC006 but the how should be changed. This question is being raised from the introduction of the draft RFC "RFC: Observability API".
The initial drive for RFC006 came from MGC wanting to configure limitadors Redis when applying the kuadrant CR to a cluster, related issue Kuadrant/kuadrant-operator#163. This now not a use case that we need to support.
With the current approach it is the components that is targeted for configuration in the kuadrant CR and not the use case, ie: you define the logging configuration for the limitador instance and not the for kuadrant installation as a whole. This approach gives an issue with ownership and the source of truth.
The current approach allows the user to define only the fields they care about in the kuadrant CR for limitador. For instances if the user configures Redis in the kuadrant CR, they will not be able to change that value in the limitador CR, it will be reconcile by the kuadrant operator. However, if the user could configures the log level within the limitador CR and even tho this can be configured at the kuadrant level, kuadrant will not reconcile the values back if it is not defined in the kuadrant CR. This gives great flexibility but comes at a cost.
As the kuadrant controller has no reference to the previous state of the kuadrant CR, if the use removes the Redis configuration from the kuadrant CR those changes are not reconciled into the limitador as it is unknown what has changed. This can lead to a misunderstanding of what is configured.
As we are trying to release a stable API for GA I think it would be best to remove the current implementation, breaking backwards compatibility, now and try to refine the approach based on the current understanding and the work that will come from the "RFC: Observability API"
If the changes are not reverted there still will need to be changes made to support "RFC: Observability API", so in any case the API will need to change.
There is an open PR, Kuadrant/kuadrant-operator#393, for doing this work with Authorino but as I had being out sick the wind has fallen out of the movement, with summit and now GA targets being focused on. This work while not merged would also need changing to suit the "RFC: Observability API".
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently RFC006 is only partially implemented and there has being number of issues/side affects raised by the current implementation. I still think there is a good reason for implementing RFC006 but the how should be changed. This question is being raised from the introduction of the draft RFC "RFC: Observability API".
The initial drive for RFC006 came from MGC wanting to configure limitadors Redis when applying the kuadrant CR to a cluster, related issue Kuadrant/kuadrant-operator#163. This now not a use case that we need to support.
With the current approach it is the components that is targeted for configuration in the kuadrant CR and not the use case, ie: you define the logging configuration for the limitador instance and not the for kuadrant installation as a whole. This approach gives an issue with ownership and the source of truth.
The current approach allows the user to define only the fields they care about in the kuadrant CR for limitador. For instances if the user configures Redis in the kuadrant CR, they will not be able to change that value in the limitador CR, it will be reconcile by the kuadrant operator. However, if the user could configures the log level within the limitador CR and even tho this can be configured at the kuadrant level, kuadrant will not reconcile the values back if it is not defined in the kuadrant CR. This gives great flexibility but comes at a cost.
As the kuadrant controller has no reference to the previous state of the kuadrant CR, if the use removes the Redis configuration from the kuadrant CR those changes are not reconciled into the limitador as it is unknown what has changed. This can lead to a misunderstanding of what is configured.
As we are trying to release a stable API for GA I think it would be best to remove the current implementation, breaking backwards compatibility, now and try to refine the approach based on the current understanding and the work that will come from the "RFC: Observability API"
If the changes are not reverted there still will need to be changes made to support "RFC: Observability API", so in any case the API will need to change.
There is an open PR, Kuadrant/kuadrant-operator#393, for doing this work with Authorino but as I had being out sick the wind has fallen out of the movement, with summit and now GA targets being focused on. This work while not merged would also need changing to suit the "RFC: Observability API".
Should we remove the current implementation?
Beta Was this translation helpful? Give feedback.
All reactions