-
Notifications
You must be signed in to change notification settings - Fork 35
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 init
does not perform sanity checks on the uplink network input
#210
Comments
I agree we should do this. |
@masnax yes lets do the same pre-check that LXD does in microcloud to allow earlier detection & correction, and then microcloud can provide the picked subnet directly to LXD. |
@MggMuggins So for this one, I think the best place to put a validation check is at the end of the config collecting process just before we set up the cluster, so that the validation is consistent for both interactive and preseed initialization. How this works in microcloud is that we carry a You can probably add a Since we only apply the config keys when first setting up the cluster, you would need to check if we are bootstrapping (should be the case if the local node is included in the InitSystem map. We usually check that like this). There may be other network structs in the The actual validation should just be like this for now, we can grow the validation steps as needed in the future:
|
See canonical/microcloud#210; this is essentially a constructor so it would be handy to be able to use it in microcloud. Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210; this is essentially a constructor so it would be handy to be able to use it in microcloud. Also moves/renames `IPRangeOverlap` to a method. Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210; this is essentially a constructor so it would be handy to be able to use it in microcloud. Also moves/renames `IPRangeOverlap` to a method `Overlaps`. Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210; this is essentially a constructor so it would be handy to be able to use it in microcloud. Also moves/renames `IPRangeOverlap` to a method `Overlaps`. Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210; this is essentially a constructor so it would be handy to be able to use it in microcloud. Also moves/renames `IPRangeOverlap` to a method `Overlaps`. Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
See canonical/microcloud#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
…ster Fixes canonical#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
…ster Fixes canonical#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
…ster Fixes canonical#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
…ster Fixes canonical#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
…ster Fixes canonical#210 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
…ster Fixes canonical#210 This catches two situations: 1. Invalid OVN ranges in UPLINK networks (range outside gateway subnet, etc) 2. UPLINK gateway subnets that contain any system's management address; these should be on separate interfaces and shouldn't conflict Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
This should certainly be checked for (in both MicroCloud and LXD and if not already).
This configuration is valid. It should be allowed to use the same or different subnets for the microcloud and ovn networks (after all the OVN uplink network interface may be connected to the same or different external network as the microcloud network interfac). We should check that none of the OVN external IPv4 ranges cover the uplink gateway address, external DNS addresses or any of the microcloud member IPs (that's asking for trouble). But the problem the OP is experiencing in case 2:
is unrelated to the differing subnets and more likely because their host has a the entire LXD is using this function to find a free OVN subnet: And this is considering any subnet in the host's routing table as unavailable. And thus it cannot find a free /24 in the So I would suggest creating a separate issue over at LXD's repo for the case 2 and then case 1 (and the other suggestions here) can be implemented in microcloud. |
…ster Fixes canonical#210 1. Invalid OVN ranges in UPLINK networks (range outside gateway subnet, etc) 2. UPLINK OVN ranges that contain any system's management address; 3. Invalid dns nameserver IPs Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
…ster Fixes canonical#210 1. Invalid OVN ranges in UPLINK networks (range outside gateway subnet, etc) 2. UPLINK OVN ranges that contain any system's management address; 3. Invalid dns nameserver IPs Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com>
microcloud init
does not perform many sanity checks on the inputs for configuring the OVN uplink network. I can identify two cases where the user can easily make a mistake while entering the network configuration, which causes the init to fail at the last stage, requiring that the user starts again.Case 1: first and last addresses are outside the gateway's subnet
The first and last addresses should maybe be validated to ensure that they are within the gateway's subnet.
Case 2: uplink network is in the same subnet as the management network (here the management network has the subnet 10.0.0.0/8 and the uplink network is configured to 10.254.254.0/24)
The text was updated successfully, but these errors were encountered: