Naming convention for Canvas Operators

[LesterThomas]

Description

We should have a standard naming convention for Canvas Operators to ensure clarity and consistency. The proposal is to use:

• \<Noun> Management for operators that are managing individual resources.
• \<Noun> Config for operators that are setting-up and configuring the common service exposed by the canvas.
• \<Noun> Control for operators that are setting up mechanisms where the canvas is enabling components to control some aspects of their behavior.

Rationale

We have some Canvas Operators that manage individual resources (for example the Exposed APIs or Published Notifications). These should be called \<Noun> Management operators.

We have other Canvas Operators that only configure the associated common services (for example the Identity Config Operator is setting up a mechanism for handling identities). These should be called \<Noun> Config operators.

We have other Canvas Operators that are setting up control mechanisms (for example for Cost Control or Carbon Control). These operators set-up mechanisms where a canvas will offer services towards components that enable those components to control their behavior. The canvas may also provide data for analysis. These should be called \<Noun> Control operators.

This follows common naming patterns used in the wider Operator ecosystem.

Implication

We need to re-name some of the existing operators and the use-cases that use these names. We will also create a markdown file with this naming convention. The names will be (for current operators):

Old Name	New Name
Component Management Operator	Component Lifecycle Management Operator
API Management Operator	API Management Operator
Event Management Operator	Event Management Operator
Identity Management Operator	Identity Config Operator
Observability Management Operator	Observability Config Operator
Secrets Management Operator	Secrets Management Operator
Carbon Management Operator	Carbon Control Operator
Cost Management Operator	Cost Control Operator

[ferenc-hechler]

In our logical view we made a distiction between ComponentVaultProvider and ComponentVaultOperator.

Component-vault provider provisions the component specific vaults based on the extracted ComponentVault CRD

Component-vault operator injects the sidecar for seamles communication with the ComponentVault. Authentication is handled automatically by Kubernetes Service-Account Tokens (JWT)

Based on this functionality we could rename ComponentVaultProvider to Secrets-Config-Operator. But we need another name for ComponentVaultOperator

We can discuss this today in the Tech/Arch meeting.

[ferenc-hechler]

Discussed this in todays Tech/Arch meeting and we stick to the previous name "Secrets-Management-Operator".