Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

report correct version when multiple images invoked #327

Merged
merged 1 commit into from
Jan 5, 2023

Conversation

sanchezl
Copy link
Contributor

@sanchezl sanchezl commented Aug 23, 2022

Fix the generation of the /must-gather/version file such that if multiple must-gather images are invoked at once, the only the version of the currently running image will be recorded in the /must-gather/version file.

If a semantic-like version cannot be parsed from the image's repository:tag name (note that :latest is not a semantic-like version), use the imageID (typically a repository@digest) value.

@ingvagabund
Copy link
Member

Just for reference: #129 is a PR introducing the version generator for the first time

@ingvagabund
Copy link
Member

From https://github.com/openshift/enhancements/blob/a5841f75dbc9afbab22e5baa8d2f1ff2f43e2df7/enhancements/oc/must-gather.md?plain=1#L88:

3. Must produce a text `/must-gather/version` that indicates the product (first line) and the version (second line, `major.minor.micro.qualifier`), so that programmatic analysis can be developed.

It's unclear whether the mentioned version corresponds to the must-gather image version or to the OCP version. Worth updating those lines to be explicit the version corresponds to must-gather version.

# if version not found, fallback to imageID
[ -z "${version}" ] && version=$(oc status | grep '^pod.*runs' | sed -r -e 's/^pod.*runs //')
# get gather container image and imageID
read -r image imageID < <(oc get pod ${POD_NAME} -o jsonpath='{range .status.containerStatuses[?(@.name=="gather")]}{.image} {.imageID}{end}')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming the script is not run outside a container, it's ok to read POD_NAME variable (always set in the must-gather pod spec). Nevertheless:

  • reading POD_NAME env creates a new dependency on the pkg/cli/admin/mustgather code (when the POD_NAME variable is removed, the version will fall back into "Unknown")
  • .status.containerStatuses does not always have to be set at the time when the version command is invoked

What about to update the building pipeline to inject the must-gather version directly? So version() can be a simple reading of a file?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sanchezl I am a bit indifferent to the solution here. What do you think is best/easiest?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sanchezl were you or @ingvagabund looking to make updates to this PR to close on this thread?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like I have the following available (with example values from 4.12.8):

"BUILD_RELEASE=202210242028.p0.ge105f12.assembly.stream",                                                                     
"BUILD_VERSION=v4.12.0",                                                                                                      
"OS_GIT_MAJOR=4",                                                                                                             
"OS_GIT_MINOR=12",                                                                                                            
"OS_GIT_PATCH=0",                                                                                                             
"OS_GIT_TREE_STATE=clean",                                                                                                    
"OS_GIT_VERSION=4.12.0-202210242028.p0.ge105f12.assembly.stream-e105f12",                                                     
"SOURCE_GIT_TREE_STATE=clean",                                                                                                
"OS_GIT_COMMIT=e105f12

Looks like OS_GIT_VERSION might be appropriate.

Copy link
Contributor

@oarribas oarribas Nov 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sanchezl , is it possible with that OS_GIT_VERSION to know the exact version/commit of the must-gather scripts (https://github.com/openshift/must-gather/commits/master/collection-scripts) used?

@oarribas
Copy link
Contributor

oarribas commented Nov 17, 2022

As per last comment in #314 , the current version script is not showing the version of the must-gather is used to collect it. It only shows 4.0-art-dev. Tested with oc 4.11.9 in a cluster with the same version.

@sferich888
Copy link
Contributor

@oarribas the version file here; is more about identifying what; image (or collector was used) and not what 'oc client' triggered the collection. Thus I don't think its is of a huge significance or issue that the client version isn't denoted.

[ -z "${version}" ] && version="Unknown"

echo ${version}
if [[ ! -z $OS_GIT_VERSION ]] ; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OS_GIT_VERSION is defined only during the building phase. Once built, the env gets unpopulated. What about to inject the env value in https://github.com/openshift/must-gather/blob/master/Dockerfile.rhel7? E.g. re-generating the version file from scratch?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following are embedded into the images during build, and as such are available when the image is run:

'OS_GIT_MAJOR': major_version,
'OS_GIT_MINOR': minor_version,
'OS_GIT_PATCH': patch_version,
'OS_GIT_VERSION': f'{major_version}.{minor_version}.{patch_version}{release_suffix}',
'OS_GIT_TREE_STATE': 'clean',
'SOURCE_GIT_TREE_STATE': 'clean',
'BUILD_VERSION': version,
'BUILD_RELEASE': release if release else '',

You can download the must-gather.tar from one of the jobs on this PR, and see that the version file contains:

openshift/must-gather
4.13.0-202211071433.p0.g63e9a04.assembly.stream-63e9a04

Copy link
Member

@ingvagabund ingvagabund Dec 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following https://github.com/openshift/enhancements/blob/master/enhancements/oc/must-gather.md#must-gather-images and the version string major.minor.micro.qualifier. I wonder what the expected mapping should be: major=4, minor=13, micro=0-202211071433, qualifier=p0.g63e9a04.assembly.stream-63e9a04? Compared to https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_must-gather/327/pull-ci-openshift-must-gather-master-images/1597782051325480960/artifacts/ci-operator-step-graph.json:

  • OS_GIT_MAJOR=4
  • OS_GIT_MINOR=13
  • OS_GIT_PATCH=0
  • BUILD_RELEASE=202211071433.p0.g63e9a04.assembly.stream

We might as well update the version string in enhancements/oc/must-gather.md to major.minor.micro-qualifier with major/minor/micro as [0-9]+ so the parts turn into major=4, minor=13, micro=0, qualifier=202211071433.p0.g63e9a04.assembly.stream-63e9a04.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ingvagabund I've updated the enhancement to specify the SemVer format (original intention) used elsewhere in OpenShift (vs. the OSGi-type format specified there originally).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With openshift/enhancements#1294 merged we are good here. @soltysh would you please approve the PR?

@oarribas
Copy link
Contributor

@sferich888 the current code (not this PR) of the version script (https://github.com/openshift/must-gather/blob/release-4.11/collection-scripts/version) is not working properly and only shows 4.0-art-dev in the version file.

@ingvagabund
Copy link
Member

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Dec 1, 2022
@sferich888
Copy link
Contributor

sferich888 commented Dec 9, 2022

@sanchezl please review #314 as a possible issue that this resolves.

@sferich888
Copy link
Contributor

/retest

Copy link
Contributor

@soltysh soltysh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 5, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ingvagabund, sanchezl, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 5, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 5, 2023

@sanchezl: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants