CF Deployment Manifest Should Populate CAPI /v2/info Fields

[davewalter]

What is this issue about?

We received a slack interrupt commenting on the fact that the CAPI build property was not being set by default. I am opening this issue to foster discussion about what we could/should be configuring by default and how it would be kept up to date.

What version of cf-deployment are you using?

v11.0.0

Please include the bosh deploy... command, including all the operations files (plus any experimental operation files you're using):

bosh deploy cf-deployment.yml

Please provide output that helps describe the issue:

$ cf curl /v2/info
{
   "name": "",
   "build": "",
   "support": "",
   "version": 0,
   "description": "",
   "min_cli_version": null,
   "min_recommended_cli_version": null,
   "api_version": "2.140.0",
   "osbapi_version": "2.15",
...
}

What IaaS is this issue occurring on?

N/A

Is there anything else unique or special about your setup?

N/A

Tag your pair, your PM, and/or team!

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/167984672

The labels on this github issue will be updated when the story is started.

[davewalter]

What would you want the build property to be set to? I can see setting the name property to cf-deployment and the version property to v11.0.0, but build is a little harder. I was originally thinking about the commit sha, but that would never actually be 100% accurate due to the commit needed to change the value. It could match the version, but that seems a little redundant. Opinions welcome.

[davewalter]

Actually, we will need to use build for the version number as version is an integer but cf-deployment's versions are semver.

[andrew-edgar]

right it was mainly the "build" that we used to have to override but now making it the same as the cf-deployment version seems good to us. as for "version" yeah good question I think making it just the major release number might work?

[Syerram]

The version should always be the current cf-deployment version. Tagging it with just a major release version can lead to confusion with the cf manifest version property in the yaml (manifest_version).

Few questions,

• What are the required fields for /v2/info?
• Are we guaranteed that /v2/info will not be overridden by other components? (by programmatically calling them)
• What is api_version or osbapi_version? Is this CAPI related info?

Now that I am thinking about this, I am confused by the intent of /v2/info. Dave mentioned CAPI build property was not being set by default. If this CAPI related info, why are we stuffing cf-deployment version into it?

[davewalter]

@Syerram See answers below...

The version should always be the current cf-deployment version.

The problem is that version is an integer, but the current cf-deployment version is semver. This is why I proposed using the build for the full semver version, and just putting the major version in version. We could choose to leave version empty instead, but it seemed more useful to populate it with something meaningful.

What are the required fields for /v2/info?

There aren't any required fields. We do not currently configure anything.

Are we guaranteed that /v2/info will not be overridden by other components? (by programmatically calling them)

We will have to talk to CAPI about that. I believe that the fields are populated solely from the manifest, so the only way they would be overridden is by an operator-applied ops-file.

What is api_version or osbapi_version? Is this CAPI related info?

api_version is the CC API version, which I would assume is populated by CC programmatically and cannot be overridden. I am not familiar with osbapi_version.

Dave mentioned CAPI build property was not being set by default. If this CAPI related info, why are we stuffing cf-deployment version into it?

This is information returned by the /v2/info endpoint about the CF deployment in general.

[ctlong]

🎉 This feature was released in the latest version of CF-D: v32.11.0. 🚀