Decision: handling of exposed APIs by different operators
Description
Exposed APIs should be labelled for treatment by different operators according to their purpose. For example, core APIs will be managed by the API Management Operator, but open metrics endpoints will additionally be handled by the observability management/config operator.
Rationale
Today, all APIs are surfaced as exposed APIs. For APIs that serve different purposes, it may be necessary to treat them in different ways. Rather than creating new CRDs for different categories (API, observability, identity etc.) we should simply label them and allow the operators to act on Exposed APIs based on labels that are relevant to them.
Implication
Any operator that manages or configures resources that expose APIs will need to be aware of labels on exposed APIs and treat them accordingly. For example, labelling the OpenMetrics endpoint for observability should cause the API operator to expose the API as usual, but then the observability mgt/config operator should also pick up the API and ensure it is exposed to the correct consumers. The identity config operator may also ensure that roles are appropriately assigned to consumers.
Context
This was raised in the Canvas Spec Jam workshop on 2024-04-11. The discussion was around whether specific APIs should be moved to a new observability CRD or whether annotation in an existing CRD is adequate for the observability mgt/config operator to do what it needs to do.
Decision: handling of exposed APIs by different operators
Description
Exposed APIs should be labelled for treatment by different operators according to their purpose. For example, core APIs will be managed by the API Management Operator, but open metrics endpoints will additionally be handled by the observability management/config operator.
Rationale
Today, all APIs are surfaced as exposed APIs. For APIs that serve different purposes, it may be necessary to treat them in different ways. Rather than creating new CRDs for different categories (API, observability, identity etc.) we should simply label them and allow the operators to act on Exposed APIs based on labels that are relevant to them.
Implication
Any operator that manages or configures resources that expose APIs will need to be aware of labels on exposed APIs and treat them accordingly. For example, labelling the OpenMetrics endpoint for observability should cause the API operator to expose the API as usual, but then the observability mgt/config operator should also pick up the API and ensure it is exposed to the correct consumers. The identity config operator may also ensure that roles are appropriately assigned to consumers.
Context
This was raised in the Canvas Spec Jam workshop on 2024-04-11. The discussion was around whether specific APIs should be moved to a new observability CRD or whether annotation in an existing CRD is adequate for the observability mgt/config operator to do what it needs to do.