Skip to content

data/bootstrap: Check if release image architecture matches host architecture #4592

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.

Sign up for GitHub

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

Merged
openshift-merge-robot merged 1 commit into from
Mar 26, 2021
Merged

data/bootstrap: Check if release image architecture matches host architecture #4592

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions data/data/bootstrap/files/usr/local/bin/release-image-download.sh.template
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,3 +26,17 @@ do
echo "Pull failed. Retrying $RELEASE_IMAGE..."
fi
done

# Sanity check the image metadata to see if the arches match
image_arch=$(podman inspect $RELEASE_IMAGE --format {{ "{{.Architecture}}" }})
host_arch=$(uname -m)
case $host_arch in
Copy link
Contributor

@staebler staebler Mar 21, 2021

Choose a reason for hiding this comment

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

Are the ppc64le and s390x architectures not included here because they do not need any mangling?

Copy link
Contributor Author

@Prashanth684 Prashanth684 Mar 22, 2021

Choose a reason for hiding this comment

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

correct. x86_64 and aarch64 map to amd64 and arm64 resp. it is a cause of confusion in many places.

"x86_64") host_arch="amd64" ;;
"aarch64") host_arch="arm64" ;; # not used, just for completeness
esac

if [[ "$image_arch" != "$host_arch" ]]; then
record_service_stage_failure
echo "ERROR: release image arch $image_arch does not match host arch $host_arch"
exit 1
Copy link
Contributor

@staebler staebler Mar 21, 2021

Choose a reason for hiding this comment

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

A failing release-image.service won't prevent other services from starting. So is the purpose of this just to have a failing unit in the bootstrap gather?

Copy link
Contributor Author

@Prashanth684 Prashanth684 Mar 22, 2021

Choose a reason for hiding this comment

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

essential services like crio and kubelet won't start if release-image.service throws an error. so in that sense, we have caught this error early and let the user know that there is an arch mismatch in the specified release image.

Copy link
Contributor

@staebler staebler Mar 22, 2021

Choose a reason for hiding this comment

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

A release-image.service that fails will not prevent crio.service or kubelet.service from starting.

Copy link
Contributor Author

@Prashanth684 Prashanth684 Mar 23, 2021

Choose a reason for hiding this comment

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

ah..right ..yeah. but it does prevent crio-configure.service from starting which in turn disables bootkube.service when there is an error, so in that sense , this error is visible right away after running journalctl -b -f -u release-image.service -u bootkube.service

Copy link
Contributor

@staebler staebler Mar 23, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

No, my point is that it does not prevent any of those services from starting.

Copy link
Contributor

@staebler staebler Mar 23, 2021

Choose a reason for hiding this comment

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

No, my point is that it does not prevent any of those services from starting.

Ah, my bad. You are correct. Sorry for the noise. I looked at crio.service and kubelet.service but not bootkube.service.

fi