install az & aws clis in the kubekins e2e image #33225
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: upodroid 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 |
k8s-ci-robot
added
approved
| @@ -74,6 +74,13 @@ RUN wget -O google-cloud-sdk.tar.gz -q $GCLOUD_SDK_URL && \ | |||
| gcloud components install alpha beta && \ | |||
| gcloud info | tee /workspace/gcloud-info.txt | |||
|
|
|||
| # Install aws cli | |||
There was a problem hiding this comment.
I'm concerned about making this image even more risky to update.
Where are we using the CLI instead of some tool that links the SDK?
There was a problem hiding this comment.
(if we could remove gcloud we should, but that requires eliminating kube-up realistically, which is not happening anytime soon)
There was a problem hiding this comment.
az cli is installed via apt and isn't an issue. You should be able to tweak it further on job execution if necessary. So many capz/sig-windows jobs install the cli on every run :( hundreds of times a day
The aws cli is also like that as well, the zip gets dropped in /usr/local/bin along with the self contained python libraries.
They can be updated without affecting the rest of the image tooling.
There was a problem hiding this comment.
So many capz/sig-windows jobs install the cli on every run :( hundreds of times a day
The aws cli is also like that as well, the zip gets dropped in /usr/local/bin along with the self contained python libraries.
Yes, but on the other hand this means the version installed is controlled by the test code.
We have lots of things we live-install and increasingly only depend on the image for bootstrapping (e.g. go 1.21+ toolchain)
/cc @dims