[BUG] Harvester API VIP address is configured on the harvester0 bridge

[janeczku]

Describe the bug
When configuring separate physical interfaces for the management network and the VLAN network respectively, then the VIP IP address for Harvester API/UI is still configured on the harvester-0 bridge interface.

Expected behavior

The Harvester management VIP should only be configured on the physical interface configured as management NIC.

Environment:

• Harvester ISO version: 0.3-preview
• Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.

[yasker]

@janeczku I am not sure it's a bug since once the bridge was created, the original nic won't have an IP anyway IIUC.

The VIP will be on the same NIC or bridge as the mgmt network.

[yaocw2020]

The rule of how Harvester selects which network interface for the VIP is as following.
The VIP is configured on the management NIC at default. After users enable the VLAN network, if the management NIC in any one of the nodes is used by the VLAN network, the VIP will be configured on the harvester bridge. Once users disable the VLAN network, if the VIP is still on the harvester bridge, it will be configured back to the management NIC.

[yaocw2020]

We ignore one case that if users change the VLAN NIC to make the management NIC is not used by the VLAN network on every node.

[janeczku]

After users enable the VLAN network, if the management NIC in any one of the nodes is used by the VLAN network, the VIP will be configured on the harvester bridge.

That seems wrong. The VIP should never be configured anywhere but on the management interface. Why does it move to the bridge interface in the first place?

[guangbochen]

This is only required when users use the same management NIC for the VLAN network since it is a bridge VLAN setup.
If users use a separate NIC for the VLAN, then the VIP will always sit on the management NIC by default.

[yaocw2020]

After users enable the VLAN network, if the management NIC in any one of the nodes is used by the VLAN network, the VIP will be configured on the harvester bridge.

That seems wrong. The VIP should never be configured anywhere but on the management interface. Why does it move to the bridge interface in the first place?

The VIP on the management interface attached to the harvester bridge is unable to be reached.

[yasker]

@janeczku Let me know if you still think this is an issue. In conclusion, the VIP is only configured either on the mgmt network (when it's not double purposed for VLAN nic), or the bridge that contains the previous mgmt NIC with the mgmt network IP (when it's double purposed for VLAN nic).

[janeczku]

We will add more information once we are able to reproduce

[guangbochen]

@janeczku can u please help to check if this is still an issue of the v0.3.0, thanks.

[tjjh89017]

This issue will be solved once harvester bump the version of kube-vip and network-controller-harvester
In further version of harvester, it will not detect and set vip_interface for kube-vip, kube-vip will detect it directly.

checked with @yaocw2020

kube-vip/kube-vip#339
harvester/network-controller-harvester@7a7f054

[lanfon72]

@tjjh89017 do we need test this? if so, can you provide test plan?

[tjjh89017]

manual test plan

1. Setup Node VLAN network interface to harvester-mgmt
2. check the harvester-br0 has VIP, don't care about harvester-mgmt
3. modify Node VLAN network interface to another interface.
4. check the harvester-mgmt has VIP, check harvester-br0 will not have VIP.

step 4 is most important to test

Thanks a lot

[harvesterhci-io-github-bot]

Pre Ready-For-Testing Checklist

• Where is the reproduce steps/test steps documented?
  The reproduce steps/test steps are at: [BUG] Harvester API VIP address is configured on the harvester0 bridge #1239 (comment)

• Is there a workaround for the issue? If so, where is it documented?
  The workaround is at:

• Does the PR include the explanation for the fix or the feature?

• Does the PR include deployment change (YAML/Chart)? If so, where are the PRs for both YAML file and Chart?
  The PR for the YAML change is at:
  The PR for the chart change is at:

• Have the backend code been merged (harvester, harvester-installer, etc) (including backport-needed/*)?
  The PR is at

• Which areas/issues this PR might have potential impacts on?
  Area
  Issues

• If labeled: require/HEP Has the Harvester Enhancement Proposal PR submitted?
  The HEP PR is at

• If labeled: area/ui Has the UI issue filed or ready to be merged?
  The UI issue/PR is at

• If labeled: require/doc Has the necessary document PR submitted or merged?
  The documentation issue/PR is at

• If labeled: require/automation-e2e Has the end-to-end test plan been merged? Have QAs agreed on the automation test case? If only test case skeleton w/o implementation, have you created an implementation issue?
  The automation skeleton PR is at
  The automation test case PR is at
  The issue of automation test case implementation is at (bot will auto create one using the template)

• If labeled: require/integration-test Has the PR includes the integration test?
  The integration test PR is at

• If labeled: require/manual-test-plan Has the manual test plan been documented?
  The updated manual test plan is at

• If the fix introduces the code for backward compatibility Has a separate issue been filed with the label release/obsolete-compatibility?
  The compatibility issue is filed at

[harvesterhci-io-github-bot]

Automation e2e test issue: harvester/tests#201

[lanfon72]

Verified this bug has been fixed.

Test Information

• Environment: qemu/KVM 3 nodes
• Harvester Version: master-9ecb4f9d-head
• ui-source Option: Auto

Verify Steps:

based on #1239 (comment)