Dynamic v3/info endpoint

[gogolok]

Is there a related GitHub Issue?

#2914

What is this change about?

Extend Korifi configuration to provide dynamic content to the endpoint v3/info.

The previous step was to introduce static content:
#3239

Does this PR introduce a breaking change?

No

Acceptance Steps

Switch to this PR's branch, set the infoConfig configuration in helm/korifi/values.yaml
to some nonempty values, run ./scripts/deploy-on-kind.sh korifi and check cf curl v3/info after loggin into Korifi via cf CLI.

Tag your pair, your PM, and/or team

None

Further Information

• The CLI version information properties have been named after https://github.com/cloudfoundry/capi-release/blob/develop/jobs/cloud_controller_ng/spec#L397 .
• Not sure whether the InfoConfig should have been passed via repository pattern to the v3 info endpoint handler?

[danail-branekov]

Same as above, renaming minRecommendedCLIVersion to recommendedCLIVersion would probably make sense

[gogolok]

I've changed it.

[danail-branekov]

The API docs are not really clear on what build semantic is. Is there a use-case where this value is used? If not, we would prefer a lean approach and only put stuff that are actually needed.

Other than that, the docs example value sounds like a commit SHA. If that is the case, the same approach as to the version should be applied (i.e. should not be configurable via a helm value)

[gogolok]

I think the v3/info endpoint in general is very open for interpretation and how you as an operator use and configure it. I think the 'old' approach of cf-deployment to put here the current release number is:

cloudfoundry/cf-deployment@ab93783

For my future usage, I would probably put here not a Korifi specific hash tag alone, but my own interpretation of the current build (some semver for my current Korifi + Kubernetes + cert-manager + ... setup).

[danail-branekov]

Hey @gogolok

A general question: do you know use cases where each property of the /v3/info endpoint is used? We would refrain from implementing things that noone uses, especially things that are not clear when reading the CF API spec (which is the case with /v3/info)

[danail-branekov]

I wonder whether it makes sense to default cli versions to something? No idea what default values should be though.

[danail-branekov]

On a second glance, it seems that we already have some "min version" code in place. I guess returning this constant in the /v3/info presenter would make sense, moreover it is already used to error if cli version is tool low.

[gogolok]

For cf-deployment, those properties seem to be empty.

Some real-life output:

{"build":"v1.56.0","cli_version":{"minimum":"","recommended":""},"custom":{},"description":"","name":"cf-deployment","version":39,"links":{"self":{"href":"https://api.system.EXAMPLE.com/v3/info"},"support":{"href":"support@EXAMPLE.com"}}}

I think I would keep minimum and recommended version empty by default and let the operator decide how to use it.

For example if you would fix cf whoami ( #1724 ), you would probably require a new CF CLI version and the operator could point out the fact you need a specific CLI version.

I consider
https://github.com/cloudfoundry/korifi/blame/c353c9ecd6f55a14799d22bedfaf5a822d15d8cc/api/middleware/cli_version.go#L14
to be a hard requirement the Korifi release imposes, but the operator might be more strict.

[gogolok]

A general question: do you know use cases where each property of the /v3/info endpoint is used? We would refrain from implementing things that noone uses, especially things that are not clear when reading the CF API spec (which is the case with /v3/info)

As I said before, I tried to mimic the old behaviour. The only property I see critical is version. I guess using a string instead of an integer is better.

Besides from this, I only see for my scenario the following properties to be useful:

• build: I can put there some bundled version number, but via custom property I could also achieve the same; so more of a cf-deployment version number or helm chart version or whatever I will use in the future to bundle Korifi with other components
• custom: I want to put there some custom labels that make it easier to identify that Korifi installation (project, customer id)
• support: set my own support email/http(s) address
• description: explain human readable this is a Korifi installation
• name: give it a unique name OR the software (helm chart, ...) that has rolled out this Korifi installation
• version: if changed to string, I would put here the Korifi version (0.11.0 for example)

[georgethebeatle]

Maybe we should default name and description so that it looks more similar to current CF systems. Something generic like:

name: "korifi"
description: "Korifi Cloud Foundry Environment"

[georgethebeatle]

Looks good @gogolok. Dropped a small comment inline. Just one more request - can you squash your commits into one and force push before we approve and merge this PR. This way we will have cleaner history. Thank you for your contribution!