Decision: Uniform method to transfer information from ODA Canvas to ODA Component

[ferenc-hechler]

New decision: Uniform method to transfer information from ODA Canvas to ODA Component

Context

The ODA Canvas offers supporting functions for ODA Components. A service discovery for these supporting functions has to be implemented. Following the descriptions in the use-cases the endpoints of those supporting functions have to be configured in the values.yaml. Beside the "static" endpoints, an ODA Component also needs to retrieve dynamically resolved information, like communication parameters for dependent APIs it requested in the component.yaml. To manually configure this in the values.yaml is error prone and also breaks the automation chain. Therefore a generic solution for transferring data from the ODA Canvas to the ODA Component is needed.

Decision

Technically there are multiple possibilities for the ODA Canvas to "inject" information into the ODA Component. As discussed in the ODA Canvas Innovation HUB Architecture meeting, here is a list of possibilities:

ID	Method	Description
1	Manual configuration	Information has to be added manually in the values.yaml and the helm chart (or equivalent packaging manager) starts a redeployment of the ODA Component redeployed.
2	Patch Deployment	A Mutating Webhook patches the deployment and writes the information into the environment variables (of each container). This will trigger a restart of the deployment.
3	ConfigMap/Secret as Environment variables	Information is stored in a Kubernetes ConfigMap/Secret and the deployment is patched to add the content of the ConfigMap/Secret to the environment variables. Restart of the Deployment is needed to get the latest values
4	ConfigMap/Secret mounted into the filesystem	Information is stored in a Kubernetes ConfigMap/Secret and the deployment is patched to mount this in the filesystem. Updates in the ConfigMap are directly visible (without restart)
5	Canvas Information API	The ODA Canvas offers an endpoint implementing an OpenAPI which allows the ODA Component to query necessary information, like endpoints of other supporting functions or dynamically resolved dependent APIs. The endpoint is configured in the values.yaml. In case of Dependent APIs, the component could ask for the dependent API by providing the name which was configured for the dependent API in the component.yaml. As a response it would get the communication parameters needed to communicate with this API (endpoint, ...) or the status "PENDING" or "NOT_FOUND". Handling of sensitive data, like credentials should not be managed by the information endpoint.

In the Architecture meeting we voted for trying out Method 5. The Canvas Information API provides the flexibility and also needs very little manual configuration. By defining a default endpoint name, like "info.canvas.svc.cluster.local", the ODA Component deployment can be done without touching the values.yaml.

The abstraction of the Canvas Information API should be high enough to not directly rebuild querying the status of the custom resources. Also it should not rebuild a Service-Discovery solution like HashiCorp Consul.

Consequences

The first use-case to implement this will be the Dependent API resolution. Based on the experiences the decision can be rethought.

[LesterThomas]

Starting with Method 5 looks like the right approach to me.

[hvaughanattmforum]

Excellent. Do we have a target date for this to be proven?

[LesterThomas]

For the option 5, should we use one of the TM Forum Open-APIs? We could adopt the Resource Inventory API TMF639? We are allowing access from the component software to view the Component/Dependent APIs in Kubernetes.