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

microcloud: Subnet sharing warning should check interfaces not IPs #522

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

gabrielmougard
Copy link
Contributor

closes #516

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch 5 times, most recently from 8e01972 to 3c0887c Compare December 2, 2024 18:36
Copy link
Contributor

@roosterfish roosterfish left a comment

Choose a reason for hiding this comment

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

Thanks for moving the existing check from IPs to interfaces. Please have a look at my last comment, I think we should check the other two remaining ifaces as well.

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch 2 times, most recently from 9cec54a to eb8c057 Compare December 3, 2024 11:49
@roosterfish
Copy link
Contributor

Not related to the PR but since we have switched the runners to the free ones this error seems to become peristent. It's probably caused by this so I am wondering if the test bed reset is just failing here.

Copy link
Contributor

@masnax masnax left a comment

Choose a reason for hiding this comment

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

Looks good, just one suggestion to reduce complexity & prevent having lots of extra fields & types.

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch from eb8c057 to a9f6ca7 Compare December 5, 2024 10:48
@gabrielmougard
Copy link
Contributor Author

@masnax @roosterfish I reworked the approach based on #522 (comment)

Copy link
Contributor

@roosterfish roosterfish left a comment

Choose a reason for hiding this comment

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

Hi, just saw I never submitted the review. Please have a look when you find time.

@roosterfish
Copy link
Contributor

Also requires a rebase now due to the recent CLI changes.

@gabrielmougard
Copy link
Contributor Author

Thanks for the feedback!

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch from a9f6ca7 to e93d076 Compare January 7, 2025 09:39
@gabrielmougard
Copy link
Contributor Author

@roosterfish updated

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch 3 times, most recently from 9f57467 to 1a8b231 Compare January 9, 2025 15:10
@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch from 1a8b231 to 94488b6 Compare January 27, 2025 15:55
@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch from 94488b6 to a3b5fb2 Compare January 29, 2025 15:07
Copy link
Contributor

@roosterfish roosterfish left a comment

Choose a reason for hiding this comment

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

Thanks for adding the test cases!
The validation still seems to be outputting something else in case of single node MicroCloud. Please have a look at my comments.

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch from 673c61f to 2a49acf Compare February 4, 2025 15:19
Copy link
Contributor

@roosterfish roosterfish left a comment

Choose a reason for hiding this comment

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

Hi, looks good already, only a few more smaller comments. Let's have a chat tomorrow morning to go through the details and especially around the verbosity.

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch 4 times, most recently from 4da155f to 0e3a8c7 Compare February 10, 2025 16:07
Copy link
Contributor

@roosterfish roosterfish left a comment

Choose a reason for hiding this comment

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

Hi, thanks for applying the changes we have discussed last week. This looks good to me and resolves the issue about being too verbose and implying something is off.

In my comments there is another small remark on askAddress, some comments on the output formatting (to be in line with the other outputs) and a hint on how to check for the preseed mode during validation.

}
} else {
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for differentiating between interactive/preseed.
Instead of passing another bool you can just check for c.autoSetup == true to indicate if we are in preseed mode.
We also use this pattern at other places in the code to check whether or not we should output something.

Having said this when in preseed mode the collision warning shouldn't be printed anymore. It isn't consistent and was the reason for logging #516.

@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch 7 times, most recently from 2d08734 to dfdebd6 Compare February 12, 2025 17:09
@roosterfish
Copy link
Contributor

Linter errors should disappear after #632 got merged.

@roosterfish
Copy link
Contributor

Can now be rebased.

This type will be used to store a variety of subnet informations and which local network interface
they will use. This will be used both for configuring MicroCloud but for running validation as well (e.g, interface collisions within a member, subnet collisions between members of a cluster)

Signed-off-by: Gabriel Mougard <[email protected]>
This will be needed to get a network interface info from a CIDR subnet notation (e.g, mostly in the case of configuring MicroCloud internal and public networks)

Signed-off-by: Gabriel Mougard <[email protected]>
* This introduce the `OVNGeneveNetwork`, `MicroCephPublicNetwork`, `MicroCephInternalNetwork` and `MicroCloudInternalNetwork` instead of `OVNGeneveAddr`, `MicroCephPublicNetworkSubnet`, `MicroCephInternalNetworkSubnet` and MicroCloud internal network information.

Signed-off-by: Gabriel Mougard <[email protected]>
This function detect the local shared network interfaces and the global shared subnets.

Signed-off-by: Gabriel Mougard <[email protected]>
… are in preseed or interactive mode

* If we are not in preseed, the call the `detectSharedNetworks` that output advanced network info (shared nics within a system for different services, shared subnet accross a cluster, i.e same subnet in multiple machines used for different services)
* Else, we use the former approach: check if the OVN underlay and Ceph cluster network is a valid CIDR subnet notation and output a warning if the subnets are shared.

Signed-off-by: Gabriel Mougard <[email protected]>
@gabrielmougard gabrielmougard force-pushed the fix/subnet-sharing-warning branch from dfdebd6 to 2057603 Compare February 13, 2025 09:04
Copy link
Contributor

@roosterfish roosterfish left a comment

Choose a reason for hiding this comment

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

Hi, ran through another set of tests. The formatting of the messages now follows the general standard, thanks.

Those are my open findings:

  1. The list of selected cluster members is now missing an address of the node who runs the initialization
Verify the fingerprint c4e78dfa47ef is displayed on joining systems.

Selected micro01 at 
Selected micro02 at 10.87.144.136
Selected micro03 at 10.87.144.215

Gathering system information ...

  1. The MicroCloud internal network from the joiners doesn't show up in the network detection (even though addresses from the same network are used).
    I was under the impression this should be covered by the newly added populateMicroCloudNetworkFromState func. But there seems to be a problem. Maybe related to 4), see below, I'll shortly add a PR to address this.
    Also the OVN underlay doesn't show up but it's using the same network:
What subnet (IPv4/IPv6 CIDR) would you like your Ceph internal traffic on? [default=10.87.144.0/24]: 10.87.144.0/24
What subnet (either IPv4 or IPv6 CIDR notation) would you like your Ceph public traffic on? [default=10.87.144.0/24]: 10.87.144.0/24
Configure distributed networking? (yes/no) [default=yes]: yes

Using enp6s0 on micro01 for OVN uplink
Using enp6s0 on micro02 for OVN uplink
Using enp6s0 on micro03 for OVN uplink

Specify the IPv4 gateway (CIDR) on the uplink network (empty to skip IPv4): 10.1.2.1/24
Specify the first IPv4 address in the range to use on the uplink network: 10.1.2.10
Specify the last IPv4 address in the range to use on the uplink network: 10.1.2.100
Specify the IPv6 gateway (CIDR) on the uplink network (empty to skip IPv6): 
Specify the DNS addresses (comma-separated IPv4 / IPv6 addresses) for the distributed network [default=10.1.2.1]: 10.1.2.1
Configure dedicated OVN underlay networking? (yes/no) [default=no]: yes
Using "10.87.144.24" for OVN underlay traffic on "micro01"
Using "10.87.144.136" for OVN underlay traffic on "micro02"
Using "10.87.144.215" for OVN underlay traffic on "micro03"

Checking network configuration ...
Ceph cluster network, Ceph public network, MicroCloud internal network, OVN underlay network sharing network interface enp5s0 on micro01
Ceph cluster network, Ceph public network, OVN underlay network sharing network interface enp5s0 on micro02
Ceph cluster network, Ceph public network, OVN underlay network sharing network interface enp5s0 on micro03
Ceph cluster network, Ceph public network, MicroCloud internal network sharing subnet 10.87.144.24/24

  1. When running microcloud add there isn't any network sharing message. I thought we agreed on only printing it for new cluster members as getting the used networks from already existing members should be another story as it's not straightforward. Has something changed in this regard?

  2. The subnet sharing warning prints an IP from the network instead of the actual network address: Ceph cluster network, Ceph public network, MicroCloud internal network sharing subnet 10.87.144.24/24. But we can fix this separately from your PR as it's falsely populated in askAddress anyway so no blocker.

I have the feeling the PR is almost there it just requires some more testing for consistency.

@roosterfish
Copy link
Contributor

To address comment 4) from above #634.

@roosterfish
Copy link
Contributor

Requires a rebase now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Subnet sharing warning should check interfaces not IPs
3 participants