-
Notifications
You must be signed in to change notification settings - Fork 346
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
Switch to VMware Harbor registry for Antrea Docker images #1617
Switch to VMware Harbor registry for Antrea Docker images #1617
Conversation
Thanks for your PR. The following commands are available:
|
Codecov Report
@@ Coverage Diff @@
## master #1617 +/- ##
==========================================
+ Coverage 63.31% 63.96% +0.64%
==========================================
Files 170 181 +11
Lines 14250 15433 +1183
==========================================
+ Hits 9023 9871 +848
- Misses 4292 4527 +235
- Partials 935 1035 +100
Flags with carried forward coverage won't be shown. Click here to find out more.
|
@@ -99,7 +99,7 @@ if $coverage; then | |||
manifest_args="$manifest_args --coverage" | |||
COMMON_IMAGES_LIST+=("antrea/antrea-ubuntu-coverage:latest") | |||
else | |||
COMMON_IMAGES_LIST+=("antrea/antrea-ubuntu:latest") |
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 you have any good way to define the registry URL once in a file and other code just read the URL?
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.
Or maybe have an update-image-name-with-registry.sh
script to update all images' names in the repo? Then we don't need to add logic in the code.
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 guess specifically for test / CI, we can have something like this:
images.yml
antrea/antrea-ubuntu: projects.registry.vmware.com/antrea/antrea-ubuntu
get_img.sh
function get_img {
while read -r line; do
IFS=':' read -ra ADDR <<< "$line"
name=$(echo ${ADDR[0]} | xargs)
img=$(echo ${ADDR[1]} | xargs)
if [[ $name == $1 ]]; then echo $img; fi
done < "images.yml"
}
[[ $_ != $0 ]] || get_img $1
for example, CI scripts can source get_img.sh
and use "$(get_img antrea/antrea-ubuntu)"
I am not sure it's much better though. Maybe we can wait a bit and see how things evolve in the short term? Right now we have to push and pull from different registries which is making things a bit tricky.
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.
Good idea. Yes we can wait and see.
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
/test-all |
d537fcb
to
9744fd4
Compare
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
9744fd4
to
89f8554
Compare
/test-all |
/test-e2e |
89f8554
to
63c2778
Compare
/test-all |
All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows, antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor distribution registry (projects.registry.vmware.com) to avoid Docker pull rate limiting. The YAML manifests (top-of-tree and releases) now refer to the new registry. This is not a complete transition from Dockerhub to Harbor. Images used for build purposes (e.g. antrea/openvswitch) are still pulled from Dockerhub by default. Rate limiting is not as much of an issue for these (not user-facing, Github workflows are not subject to rate limiting, we have workarounds for the Jenkins CI jobs). One thing to keep is mind is that we cannot push to the VMware Harbor registry from outside of the the VMware corporate network. This is why all images are pushed to the Dockerhub registry, which is then mirrored by the distribution Harbor registry. See antrea-io#1555
63c2778
to
9a002c1
Compare
/test-all |
@lzhecheng I need a new review & approval for this. I found a couple issues during testing that I had to address (see second and third commits) |
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
Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
Changes are the same as in #1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
…o#1650) Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
…o#1650) Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
…o#1650) Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
…o#1650) Changes are the same as in antrea-io#1617 but for the antrea/flow-aggregator Docker image. There was also a typo in the flow-aggregator YAML: the image key didn't match the one used in generate-manifest-flow-aggregator.sh when invoking kustomize.
* Switch to VMware Harbor registry for Antrea Docker images All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows, antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor distribution registry (projects.registry.vmware.com) to avoid Docker pull rate limiting. The YAML manifests (top-of-tree and releases) now refer to the new registry. This is not a complete transition from Dockerhub to Harbor. Images used for build purposes (e.g. antrea/openvswitch) are still pulled from Dockerhub by default. Rate limiting is not as much of an issue for these (not user-facing, Github workflows are not subject to rate limiting, we have workarounds for the Jenkins CI jobs). One thing to keep is mind is that we cannot push to the VMware Harbor registry from outside of the the VMware corporate network. This is why all images are pushed to the Dockerhub registry, which is then mirrored by the distribution Harbor registry. See #1555 * Changes for Jenkins scripts * Fix issue in generate-manifest.sh when enabling ipsec and coverage
Following antrea-io#1617, the default image name in the antrea.yml file changed to use the harbor image. Although the patch includes a change in the make file to change the image name correctly in case the image was built, the hw-offload CI uses `docker build` to build the image, and this made it so that the CI would not use the image it was building, but the upstream latest image. This patch fixes that by building the antrea manifests with the image name being the same as the one that was built.
Following antrea-io#1617, the default image name in the antrea.yml file changed to use the harbor image. Although the patch includes a change in the make file to change the image name correctly in case the image was built, the hw-offload CI uses `docker build` to build the image, and this made it so that the CI would not use the image it was building, but the upstream latest image. This patch fixes that by building the antrea manifests with the image name being the same as the one that was built.
Following antrea-io#1617, the default image name in the antrea.yml file changed to use the harbor image. Although the patch includes a change in the make file to change the image name correctly in case the image was built, the hw-offload CI uses `docker build` to build the image, and this made it so that the CI would not use the image it was building, but the upstream latest image. This patch fixes that by building the antrea manifests with the image name being the same as the one that was built.
Following antrea-io#1617, the default image name in the antrea.yml file changed to use the harbor image. Although the patch includes a change in the make file to change the image name correctly in case the image was built, the hw-offload CI uses `docker build` to build the image, and this made it so that the CI would not use the image it was building, but the upstream latest image. Also changed the way to enable the hw-offload to use the generate-manifests.sh instead of using `sed`. This patch fixes that by building the antrea manifests with the image name being the same as the one that was built.
All "user-facing" images (antrea/antrea-ubuntu, antrea/antrea-windows,
antrea/octant-antrea-ubuntu) are now pulled from the VMware Harbor
distribution registry (projects.registry.vmware.com) to avoid Docker
pull rate limiting.
The YAML manifests (top-of-tree and releases) now refer to the new
registry.
This is not a complete transition from Dockerhub to Harbor. Images used
for build purposes (e.g. antrea/openvswitch) are still pulled from
Dockerhub by default. Rate limiting is not as much of an issue for these
(not user-facing, Github workflows are not subject to rate limiting, we
have workarounds for the Jenkins CI jobs). One thing to keep is mind is
that we cannot push to the VMware Harbor registry from outside of the
the VMware corporate network. This is why all images are pushed to
the Dockerhub registry, which is then mirrored by the distribution
Harbor registry.
See #1555