Upgrade Antrea base image to ubuntu:22.04

[antoninbas]

Ubuntu 20.04 comes with iptables 1.8.4, which seems to have several bugs
when used with nft. In particular, we observe that iptables-restore
sometimes segfaults when restoring the ANTREA-NODE-PORT-LOCAL chain in
the nat table. Ubuntu 22.04 comes with a more recent iptables version, 1.8.7.

As part of this change, we change the tag format for base images
(antrea/openvswitch and antrea/base-ubuntu). We no longer use the OVS
version as the tag, instead we use the Antrea minor version number.

Fixes #4435

Signed-off-by: Antonin Bas [email protected]

[codecov]

Codecov Report

Merging #4459 (77d5acb) into main (2f2d4d2) will increase coverage by 0.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #4459      +/-   ##
==========================================
+ Coverage   67.70%   67.90%   +0.19%     
==========================================
  Files         402      402              
  Lines       57253    57253              
==========================================
+ Hits        38764    38875     +111     
+ Misses      15818    15681     -137     
- Partials     2671     2697      +26     

Flag	Coverage Δ
integration-tests	34.63% <ø> (-0.02%)	⬇️
kind-e2e-tests	47.92% <ø> (+0.86%)	⬆️
unit-tests	56.43% <ø> (-0.03%)	⬇️

Impacted Files	Coverage Δ
pkg/agent/controller/networkpolicy/packetin.go	70.27% <0.00%> (-6.76%)	⬇️
pkg/agent/ipassigner/responder/arp_responder.go	72.94% <0.00%> (-3.53%)	⬇️
pkg/agent/querier/querier.go	83.05% <0.00%> (-3.39%)	⬇️
pkg/controller/ipam/antrea_ipam_controller.go	75.25% <0.00%> (-3.02%)	⬇️
pkg/agent/controller/networkpolicy/fqdn.go	73.78% <0.00%> (-2.34%)	⬇️
.../flowexporter/connections/conntrack_connections.go	81.42% <0.00%> (-1.91%)	⬇️
pkg/agent/util/iptables/iptables.go	45.07% <0.00%> (-1.56%)	⬇️
pkg/ipam/ipallocator/allocator.go	88.14% <0.00%> (-1.55%)	⬇️
pkg/ipam/poolallocator/allocator.go	73.57% <0.00%> (-1.43%)	⬇️
pkg/agent/client.go	76.74% <0.00%> (-1.17%)	⬇️
... and 31 more

[antoninbas]

/test-all

[tnqn]

LGTM

[antoninbas]

/test-e2e

[antoninbas]

/test-e2e

[antoninbas]

@tnqn @luolanzone could you take another look?
I realized that if we wanted to keep using the same Ubuntu version for older Antrea versions, we would need to add the Ubuntu version to the tag for antrea/openvswitch and antrea/base-ubuntu. For example: antrea/openvswitch:20.04-ovs2.17.3 and antrea/base-ubuntu:20.04-ovs2.17.3. Instead of antrea/openvswitch:2.17.3 and antrea/base-ubuntu:2.17.3.

[tnqn]

LGTM

[tnqn]

I realized that if we wanted to keep using the same Ubuntu version for older Antrea versions, we would need to add the Ubuntu version to the tag for antrea/openvswitch and antrea/base-ubuntu.

We could use a more specific tag but I assume we need to backport this to older Antrea versions? Otherwise runner's ubuntu version needs to be pinned and user would meet the issue when running Antrea on Jammy if they don't upgrade to 1.10.

[tnqn]

/test-all

In previous test, ovs-monitor-ipsec failed to start:

[�[1;34m2022-12-12T21:15:34Z �[0;32mINFO �[0;36mantrea-ovs�[0m]: Started ovs-vswitchd
[�[1;34m2022-12-12T21:15:34Z �[0;32mINFO �[0;36mantrea-ovs�[0m]: Started the loop that checks OVS status every 30 seconds
[�[1;34m2022-12-12T21:17:03Z �[0;32mINFO �[0;36mantrea-ipsec�[0m]: Checking for IPsec prerequisites
[�[1;34m2022-12-12T21:17:03Z �[0;32mINFO �[0;36mantrea-ipsec�[0m]: Starting ovs-monitor-ipsec and strongswan agents
Traceback (most recent call last):
  File "/usr/share/openvswitch/scripts/ovs-monitor-ipsec", line 25, in <module>
    import ovs.daemon
ModuleNotFoundError: No module named 'ovs'

[tnqn]

/test-all

[luolanzone]

LGTM overall, one nit. And you may need to update the PR's summary as well.

[antoninbas]

I realized that if we wanted to keep using the same Ubuntu version for older Antrea versions, we would need to add the Ubuntu version to the tag for antrea/openvswitch and antrea/base-ubuntu.

We could use a more specific tag but I assume we need to backport this to older Antrea versions? Otherwise runner's ubuntu version needs to be pinned and user would meet the issue when running Antrea on Jammy if they don't upgrade to 1.10.

By "more specific tag", I assume you mean something based on the current Antrea version?

I also consider using a hash (md5sum) of all dependency versions as the build tag (that's what we do for Windows), but decided against it in the end.

For the backporting, we have the choice. I think we should at least backport to 1.9, we can also do 1.8 and 1.7. The iptables issue that this is trying to fix is pretty specific: only when using NodePortLocal and only for a specific scenario (sequence of rules). What do you think?

[antoninbas]

I have squashed commits

[antoninbas]

/test-all

[antoninbas]

@tnqn I changed the tag format, it is now 22.04_v1.10_f26634ec4c.

I just remembered as I was working on this that we always build all base images from scratch when we generate an image for a patch release. I introduced this mechanism a long time ago to avoid such issues. In other words, we only push base images to the Docker registry when we build the "latest" Antrea image, and this is for caching purposes only.

I still decided to update the tag, as I don't think it makes sense to keep using the OVS version as the tag forever. In theory we could just use latest since it is for caching purposes only, but maybe it's not that great.

The reason for including the Antrea version is if we want to identify and delete old images from the registry.

If this is merged, to add Suricata please:

1. add build/images/deps/suricata-version with the correct version number
2. update build/images/chains/ubi.def and build/images/chains/ubuntu.def to indicate that Suricata is included in the image

[antoninbas]

/test-all

[tnqn]

/test-latest-all

[tnqn]

/test-latest-all

[tnqn]

@tnqn I changed the tag format, it is now 22.04_v1.10_f26634ec4c.

I just remembered as I was working on this that we always build all base images from scratch when we generate an image for a patch release. I introduced this mechanism a long time ago to avoid such issues. In other words, we only push base images to the Docker registry when we build the "latest" Antrea image, and this is for caching purposes only.

I still decided to update the tag, as I don't think it makes sense to keep using the OVS version as the tag forever. In theory we could just use latest since it is for caching purposes only, but maybe it's not that great.

The reason for including the Antrea version is if we want to identify and delete old images from the registry.

If this is merged, to add Suricata please:

1. add build/images/deps/suricata-version with the correct version number
2. update build/images/chains/ubi.def and build/images/chains/ubuntu.def to indicate that Suricata is included in the image

@antoninbas thanks for the explanation. It also reminds me the original purpose of the base images. Then does it make sense to just use the major + minor parts of antrea VERSION as the tag? Then there will be a "latest" image for each release and we don't need to care about the changes of dependencies and the base images generated during the development cycle. I see it's also a little difficult to predict the image tag in various scripts, for instance, the tag used in build/images/test/Dockerfile. Using a stable tag should resolve it.

But to avoid confusion caused by the tag, "openvswitch:1.10", perhaps we could have some prefix to indicate it's not OVS version, like "openvswitch:antrea-1.10", "base-ubuntu:antrea-1.10"?

[antoninbas]

@tnqn the simpler approach works for me. I changed the tag to antrea-v1.10. It helps to have the same tag for both build chains (ubuntu and ubi).

[antoninbas]

/test-latest-all

[antoninbas]

/test-latest-all

[tnqn]

/test-conformance

[tnqn]

LGTM, thanks