Release 1.0.1 #2139

When dispatching the build workflow to the vmware-tanzu/antrea-build-infra repository (to build the multi-arch Antrea docker image), the docker-tag parameter was wrong (empty string instead of the Github tag).

The second parameter to wait.PollImmediate (the timeout) is a time.Duration value. When using 5 as the parameter value, it is interpreted as 5ns, and not 5s. This means that EnableHostInterface basically never does any retry.

A Policy rule may have multiple AppliedToGroups, not all of which select some workloads on the Nodes that the Policy applies to. It's by design that an AppliedToGroup won't be sent to a Node if it doesn't select any workload on it, so agents shouldn't require all AppliedToGroups to be received before it can realize a rule. What's more, it may happen that none of its AppliedToGroups is sent to a Node when the rule itself is being evaluated on the Node if it's sent to the Node because other rules of its parent Policy apply to it. This patch fixes the logic by making the controller install a rule when any of its AppliedToGroups can be populated and all of its AddressGroups can be populated, and uninstall it when none of its AppliedToGroups can be populated.

IsPresent field of connection should be updated before having IsConnectionDying check otherwise IsConnectionDying will always return true, which makes existing connections cannot be updated and octetDeltaCount always return 0. This commit also changes the delta count of first record from zero to its total delta count, modifies throughput calculation of first record in logstash config and changes names of thoughput diagram from 'throughput' to 'cumulative bytes'.

Packets to the tunnel or gateway port will go directly to ConntrackCommitTable and bypass the IngressMetricsTable, which causing these packets uncounted when applying by certain Networkpolicy with ingress rules. Fixed by forwarding these packets to IngressMetricsTable.

…pped in AntreaProxy (antrea-io#2101) For antrea-io#2092 Due to the message size and the implementation of Service in AntreaProxy, the maximum number of Endpoints that AntreaProxy can support now is 800. If the the number of Endpoints in given Service exceeds 800, the extra Endpoints will be dropped and a warning will be logged. In AntreaProxy, OVS group is the key part of Service implementation. For now, Antrea is using Openflow 1.3 to communicate with OVS. In previous design, every bucket of a OVS group has five actions. Two actions for loading Endpoint IP and port to registers and resubmit action must be preserved.The other two actions for loading values to register can be moved to flows (in current patch, they are moved to table 41), and then one message can hold more bucket items. As a result, the maximum Endpoint has changed from 511 to 800. Unfortunately, to ensure AntreaProxy running correctly, the extra Endpoints will be dropped.

The Group objects were not reset correctly when attempting to replay them, leading to confusing error log messages and invalid datapath state. We fix the implementation of Reset() for groups and we ensure that the method is called during replay. We also update the TestOVSFlowReplay e2e test to make sure it is more comprehensive: instead of just checking Pod-to-Pod connectivity after a replay, we ensure that the number of OVS flows / groups is the same before and after a restart / replay. We confirmed that the updated test fails when the patch is not applied. Fixes antrea-io#2127

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release 1.0.1 #2139

Release 1.0.1 #2139

Commits on Apr 29, 2021