Problem:

Primaza currently support only the service binding spect mechanism to project Service Endpoint Definitions (SEDs) as secrets mounted in the application. If the application supports the spec is all good (Quarkus does already for example). However, if application does not support the spec the developer will have to have an extra step in their application to file all the files mounted represented fields of the SEDs they need to consume.

Goal:

We will like to create a mechanism to make the projection of SEDs to the application more extensible. This means supporting different formats of the SEDs as required by the application framework and the developer team. We will start with a few popular formats and then allow the Primaza community to extend with formatters that apply to their needs. The scope of this Epic will be to support JSON, YAML and GO Templates as the initial formats. The impart part is to create a pattern that can be used for more formatters to come.

Why is it important?

One of the main value proposition of Primaza is that it does not require a give specification but it provides multiple choices for both discovery of services and projection of services, having this flexibility actually standardizes on the API used to consume the services without putting hard requirements on stakeholders. This Epic allows us to execute on that core principle.

Use cases

• As a developer, I will like to be able to consume SEDs as JSON, so that my application can continue to use standard configuration input.
• As a developer, I will like to be able to consume SEDs as YAML, so that my application can continue to use standard configuration input.
• As a developer, I will like to be able to consume SEDs as Go Template, so that I can easily customize the format of the configuration input as my application evolves.

Demo requirements

• Show a demo with JSON as the SED Format projected
• Show a demo with YAML as the SED Format projected
• Show a demo of an ini file customized via go templates as the SED Format projected

UI requirements

Acceptance criteria

Development:

• I can project SEDs as YAML
• I can project SEDs as JSON
• I can project SEDs as a Go Template

QE:

• There are Acceptance test added for each of the formats supported

Documentation:

• There is documentation explaining how to request the format in the claims

Dependencies (External/Internal)

Design Artifacts

See proposal in Discussion: https://github.com/primaza/primaza/discussions/200

Exploration

Note

Github Epic

https://github.com/primaza/primaza/issues/282