From 19b1fdb3e3bd4543a52ec8841237ba70ebf718d8 Mon Sep 17 00:00:00 2001 From: R-Lawton Date: Tue, 30 Jul 2024 14:45:06 +0100 Subject: [PATCH] adding alternate sugestion observability policy --- rfcs/0000-observability-api.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/rfcs/0000-observability-api.md b/rfcs/0000-observability-api.md index 6654784..870d5e1 100644 --- a/rfcs/0000-observability-api.md +++ b/rfcs/0000-observability-api.md @@ -180,11 +180,15 @@ If a values is being configure either being added, modified or removed all chang If the value is removed from the Observability CR it will also be removed from the relevant component CRs. If the value is removed from the component CR but not the Observability CR it will be overridden and added back. -If no value is provided as the default is acceptable and the component CR is updated to something that changed the default. The value will get overridden to what the default was. -If no value is given and there is no default in the Observability CR and the component CR is updated to add a value it will be overridden back to no value. # Unresolved questions -Do we want a value where a person just wants everything "on", they want sll the observing. Where a value a the root of the observability section can be set to say give me all you got? And potentially + +1. Do we want a value where a person just wants everything "on", they want all the observing. Where a value a the root of the observability section can be set to say give me all you got? +2. Do we add the values to the Kuadrant CR instead? +3. Do we go with a observability policy instead of the proposed configuration style CR like whats being suggested? TLDR of what that would look like is quite similar to the observability CR in the fact that the observability piece is pulled out but instead of there just being one source of truth with the current method, and having the fine grained capabilities be in the one location. Instead you would have for most use cases a single observability policy that would be attached at the Kuadrant component level, in there you would have a Kuadrant level view i.e if i enable tracing here its enabled for all the components that can handle it. From there if a component needs some special configuration a separate policy can be created and attached to that specific component instead. + +In terms of Adding, modifying and deleting values or no values. Adding a value to the Kuadrant level view populates the values to the relevant component CR's. If finer configuration is needed then another policy is created for said component. If values are deleted from the Kuadrant level policy they are also then deleted from the relevant components CR's but if a component level policy is in place that will remain. If there is a observability policy in place in the Kuadrant level and a value is changes in the component CR then it will get overridden by the Kuadrant level policy. If there is no values in the Kuadrant level policy and a user changes the component level CR the value will not get overridden but the user will have to be made aware if something is added at the Kuadrant level in the future it will be overridden. + #### Work thats needed The indirect approach allows for not much if any changes to the Authorino operator and the Limitador operator etc . The bulk of the work that would be needed would be in the Kuadrant operator.