Skip to content
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

[Bugfix] Install Multicast related iptables rules only on IPv4 chains #6123

Merged
merged 1 commit into from
Mar 28, 2024

Conversation

wenyingd
Copy link
Contributor

@wenyingd wenyingd commented Mar 20, 2024

Add a precheck on the Multicast feature gate status with IPv6-only cluster settings in agent Initializer, and install the iptables rules only in the IPv4 related chains.

Fix: #6113

@wenyingd wenyingd changed the title [Bugfix] Install Multicast related iptables rules only on IPv4 cluster [Bugfix] Install Multicast related iptables rules only on IPv4 chains Mar 20, 2024
@wenyingd wenyingd force-pushed the issue_6113 branch 2 times, most recently from 073fe52 to 47585b4 Compare March 20, 2024 06:12
@wenyingd
Copy link
Contributor Author

/test-all

@wenyingd
Copy link
Contributor Author

/test-ipv6-e2e
/test-ipv6-only-conformance
/test-multicluster-e2e

Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR should close #6113 IMO. We can open another issue to track Multicast IPv6 support.

@@ -130,6 +130,7 @@ type Initializer struct {
enableL7FlowExporter bool
connectUplinkToBridge bool
enableAntreaProxy bool
enableMulticast bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what there an issue with doing the check in mcastController.Initialize to avoid adding this field?

Copy link
Contributor Author

@wenyingd wenyingd Mar 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used to think about placing the check at the step before constructing multicastController instance, then some initial configurations may already be performed at that time, like OpenFlow, routes, cniserver, which seems obey the thought that block at the beginning when configurations is not correct.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @antoninbas. Other than the validation performed in startup stage, other validation logic should be put in its own module to better encapsulate the specific logic, instead of spreading the logic among multiple places, each of which does a piece of the whole.

Generically, we should avoid making a "common" module include unrelated responsibilies. I'm not sure if AgentInitializer's responsibity is really clear today, but my understanding and expectation is that it is a module that initializes the bridge and the host network, not a validator for other modules.

Think about which is easier to maintain when doing something around Multicast:

  • add the static config handling in option.go, add runtime config validation in AgentInitializer, then add initialization error handling in Multicast controller
  • add the static config handling in option.go, add other handling in Multicast controller

And consider what if a config can only be validated after you have made some system calls or API calls, it would be bad to move such business specific system calls or API calls to something like AgentInitializer.

Lastly, it's less redundant to have the validation in multicast controller itself because it doesn't have to check again whether the feature is enabled when doing the validation (the validation doesn't need to run when it's disabled).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, I will update accordingly.

@wenyingd wenyingd force-pushed the issue_6113 branch 2 times, most recently from a09e2d0 to 7af7f6d Compare March 22, 2024 15:48
@wenyingd wenyingd force-pushed the issue_6113 branch 3 times, most recently from 0ade0df to 0cfb8ef Compare March 25, 2024 03:54
@wenyingd
Copy link
Contributor Author

/test-all

@@ -128,8 +128,6 @@ type Client struct {
nodePortsIPv6 sync.Map
// clusterNodeIPs stores the IPv4 of all other Nodes in the cluster
clusterNodeIPs sync.Map
// clusterNodeIP6s stores the IPv6 of all other Nodes in the cluster
clusterNodeIP6s sync.Map
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need clusterNodeIP6s when implementing Multicast for IPv6 in the future?
If yes, perhaps don't remove it, just remove its consumer code and add a comment that it's retained for future Multicast support to avoid back and forth change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shall use it in the future after Multicast is supported with IPv6. Do you mean we can keep the publisher to add Node IPv6 address into this map, but not consume the items?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, just add the comment why it's maintained but not used currently.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated.

@wenyingd wenyingd force-pushed the issue_6113 branch 2 times, most recently from 7f2a52d to 850d2bc Compare March 26, 2024 05:39
@wenyingd
Copy link
Contributor Author

/test-all

Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only minor comments, otherwise LGTM

pkg/agent/multicast/mcast_controller.go Outdated Show resolved Hide resolved
pkg/agent/multicast/mcast_controller_test.go Outdated Show resolved Hide resolved
pkg/agent/multicast/mcast_controller_test.go Outdated Show resolved Hide resolved
pkg/agent/multicast/mcast_controller_test.go Outdated Show resolved Hide resolved
mockController.initMocks()
}
err := mockController.Initialize()
require.Equal(t, err, tc.expErr)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be assert

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update with assert.EqualError as suggested.

pkg/agent/route/route_linux.go Outdated Show resolved Hide resolved
pkg/agent/route/route_linux.go Outdated Show resolved Hide resolved
pkg/agent/route/route_linux.go Outdated Show resolved Hide resolved
pkg/agent/route/route_linux.go Outdated Show resolved Hide resolved
})
}
}

func (c *Controller) initialize(t *testing.T) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The t parameter is unused?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, removed in the latest change.

Comment on lines +1291 to +1294
if tc.expErr == "" {
mockController.initMocks()
}
err := mockController.Initialize()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we just call err := mockController.initialize() unconditionally here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, there are some mock functions inside mockController.initialize(), which are called only when mockController.Initialize() returns nil. If we call it (initialize not Initialize) unconditionally, the IPv6-only case would fail as those mock expects are missing.

antoninbas
antoninbas previously approved these changes Mar 27, 2024
Copy link
Contributor

@antoninbas antoninbas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@antoninbas antoninbas added action/backport Indicates a PR that requires backports. action/release-note Indicates a PR that should be included in release notes. labels Mar 27, 2024
@antoninbas
Copy link
Contributor

@wenyingd Please backport when this is merged

@antoninbas
Copy link
Contributor

/test-multicast-e2e

@wenyingd
Copy link
Contributor Author

@wenyingd Please backport when this is merged

Sure, I would do it.

@@ -128,7 +128,8 @@ type Client struct {
nodePortsIPv6 sync.Map
// clusterNodeIPs stores the IPv4 of all other Nodes in the cluster
clusterNodeIPs sync.Map
// clusterNodeIP6s stores the IPv6 of all other Nodes in the cluster
// clusterNodeIP6s stores the IPv6 address of all other Nodes in the cluster. It is maintained but not consumed
// since Multicast supports IPv6.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// since Multicast supports IPv6.
// since Multicast doesn't support IPv6 yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would update it as It is maintained but not consumed until Multicast supports IPv6. It seems I missed this comment previously.

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
@wenyingd
Copy link
Contributor Author

/test-all

Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tnqn tnqn merged commit fcfbe9d into antrea-io:main Mar 28, 2024
53 of 56 checks passed
wenyingd added a commit to wenyingd/antrea that referenced this pull request Mar 29, 2024
…-io#6123)

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
wenyingd added a commit to wenyingd/antrea that referenced this pull request Mar 29, 2024
…-io#6123)

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
wenyingd added a commit to wenyingd/antrea that referenced this pull request Mar 29, 2024
…-io#6123)

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
wenyingd added a commit to wenyingd/antrea that referenced this pull request Apr 1, 2024
…-io#6123)

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
tnqn pushed a commit that referenced this pull request Apr 2, 2024
…#6175)

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
tnqn pushed a commit that referenced this pull request Apr 2, 2024
…#6174)

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
tnqn pushed a commit that referenced this pull request Apr 2, 2024
…#6173)

Add a pre-check on the Multicast feature gate status with IPv6-only cluster
settings in agent Initializer, and install the iptables rules only in the IPv4
related chains.

Signed-off-by: Wenying Dong <wenyingd@vmware.com>
@wenyingd wenyingd deleted the issue_6113 branch April 3, 2024 05:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action/backport Indicates a PR that requires backports. action/release-note Indicates a PR that should be included in release notes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ip6tables agent error on dual-stack with multicast enabled
3 participants