Closed davewalter closed 11 months ago
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.
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.
Actually, we will need to use build
for the version number as version is an integer but cf-deployment's versions are semver.
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?
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,
/v2/info
? /v2/info
will not be overridden by other components? (by programmatically calling them)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?
@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.
🎉 This feature was released in the latest version of CF-D: v32.11.0. 🚀
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):Please provide output that helps describe the issue:
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!