-
Notifications
You must be signed in to change notification settings - Fork 431
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
Fetch calico manifests from release artifacts #2149
Fetch calico manifests from release artifacts #2149
Conversation
|
||
.PHONY: fetch-calico-manifests | ||
fetch-calico-manifests: ## Get Calico release manifests and unzip them. | ||
@echo "Fetching Calico release manifests from release artifacts, this might take a minute..." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this get fetched everytime? can us a file locally prevent that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everytime. The issue I'm trying to deal with is having to fetch it everytime vs. making sure generated files aren't outdated. If we don't fetch it how do we know the base manifest wasn't manually edited?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we drop a symlink to a versioned file name, to check if it is been downloaded and do a diff with previous version on the file to determine if it was changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do a diff with previous version on the file
Are you saying looking at a previous git version to compare the file? our CI just checks out the branch it's running on, we don't have any precedent with comparing things in previous versions... If I make it compare with "main" it wouldn't be accurate once this gets put into a release branch if we want to do a backport and the main file has changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking at the durations in job history for make verify (https://prow.k8s.io/job-history/gs/kubernetes-jenkins/pr-logs/directory/pull-cluster-api-provider-azure-verify) it doesn't look like this is adding that much extra time compared to previous runs, we're talking about ~ 1 minute difference so if we can't find a way around it I think we can take the hit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking from a developer experience perspective since generate flavors calls this:
cluster-api-provider-azure/Makefile
Line 437 in 35782aa
generate-flavors: $(KUSTOMIZE) generate-addons |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the diff on my machine (it's pretty slow so might be faster for others):
➜ cluster-api-provider-azure git:(main) ✗ time make generate-flavors
/Users/cerobert/go/src/sigs.k8s.io/cluster-api-provider-azure/hack/tools/bin/kustomize-v4.5.2 build templates/addons/metrics-server > templates/addons/metrics-server/metrics-server.yaml
/Users/cerobert/go/src/sigs.k8s.io/cluster-api-provider-azure/hack/tools/bin/kustomize-v4.5.2 build templates/addons/calico > templates/addons/calico.yaml
/Users/cerobert/go/src/sigs.k8s.io/cluster-api-provider-azure/hack/tools/bin/kustomize-v4.5.2 build templates/addons/calico-ipv6 > templates/addons/calico-ipv6.yaml
./hack/gen-flavors.sh
make generate-flavors 37.28s user 2.41s system 98% cpu 40.261 total
➜ cluster-api-provider-azure git:(fix-calico-fetch) time make generate-flavors
Fetching Calico release manifests from release artifacts, this might take a minute...
wget -qO- https://github.com/projectcalico/calico/releases/download/v3.22.1/release-v3.22.1.tgz | tar xz release-v3.22.1/manifests/calico-vxlan.yaml release-v3.22.1/manifests/calico-policy-only.yaml
mv release-v3.22.1/manifests/calico-vxlan.yaml templates/addons/calico
mv release-v3.22.1/manifests/calico-policy-only.yaml templates/addons/calico-ipv6
/Users/cerobert/go/src/sigs.k8s.io/cluster-api-provider-azure/hack/tools/bin/kustomize-v4.5.2 build templates/addons/metrics-server > templates/addons/metrics-server/metrics-server.yaml
/Users/cerobert/go/src/sigs.k8s.io/cluster-api-provider-azure/hack/tools/bin/kustomize-v4.5.2 build templates/addons/calico > templates/addons/calico.yaml
/Users/cerobert/go/src/sigs.k8s.io/cluster-api-provider-azure/hack/tools/bin/kustomize-v4.5.2 build templates/addons/calico-ipv6 > templates/addons/calico-ipv6.yaml
./hack/gen-flavors.sh
make generate-flavors 43.69s user 4.54s system 49% cpu 1:36.70 total
I was using the make verify
job for comparison because it runs a full make generate
(which includes make generate-flavors
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to add about six seconds to the related make targets, at least for me. I think that's acceptable.
/retest |
Gathering make verify duration data /test pull-cluster-api-provider-azure-verify |
1 similar comment
Gathering make verify duration data /test pull-cluster-api-provider-azure-verify |
35782aa
to
bf028ec
Compare
rebased on top of #2147 |
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
@jsturtevant thoughts? |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: CecileRobertMichon 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 |
/cherry-pick release-1.2 |
@CecileRobertMichon: #2149 failed to apply on top of branch "release-1.2":
In response to this:
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. |
What type of PR is this?
What this PR does / why we need it: Currently, we fetch Calico manifest from https://docs.projectcalico.org/v3.22/manifests/ with kustomize and add patches to make it work for Azure (since #2021). The issue is that https://docs.projectcalico.org/v3.22/manifests/ is not pinned to a specific release, so the manifests are mutable. This means
make verify
will start failing whenever a new release of Calico causes the manifest to be updated and we'll be forced to update Calico to fix it. To be able to update the version of Calico on our own schedule, we need another level of indirection so we keep a copy of the source manifest in the repo and use it with kustomize to generate the Calico spec.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
TODOs:
Release note: