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
Apply Fan subnet fixes to Address collection in incoming network configuration #13319
Conversation
the addresses directly and not to the legacy CIDR on the top level object.
!!build!! |
1 similar comment
!!build!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the loop could be tweaked to be easier to understand, but otherwise I think this is ok.
for i := range networkConfig { | ||
for j := range networkConfig[i].Addresses { | ||
for cidr, fanNet := range fanSubnets { | ||
if fanNet != nil && fanNet.Contains(net.ParseIP(networkConfig[i].Addresses[j].Value)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it actually possible for fanNet to be nil? I don't mind the caution, but given you just populate the map a few lines above, I wanted to make sure I understood the algorithm correctly. Is it just that ParsedCIDRNetwork might return nil for the subnet but not give an error?
Or is this just a belt-and-suspenders check to make sure we don't have a panic where it would be stupid to not just skip the item.
Given the nesting, this might be clearer as:
for i, cfg := range networkConfig {
for j, addr := range cfg.Addresses {
ip := net.ParseIP(addr.Value)
for cidr, fanNet := range fanSubnets {
if fanNet == nil {
continue
}
if fanNet.Contains(ip) {
// update the original maps rather than the local variables
networkConfig[i].Addresses[j].CIDR = cidr
break
}
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(it also led me to notice that you're parsing the Address for every fanSubnet, which can be pulled out of the inner loop)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a small tweak to pull out the address parsing to the top of the loop
Addresses: []params.Address{ | ||
{ | ||
Value: "10.10.10.2", | ||
CIDR: "10.0.0.0/8", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this the core testing change? That the NetworkConfig is returning 10.0.0.0/8 but that should not cause us to change the CIDR that we are reporting in line 170/177 ?
|
#13329 This PR forward ports 2.9 into develop. The following PRs are included in this port: - Merge pull request #13324 from achilleasa/2.9-add-ovs-integration-test - Merge pull request #13328 from manadart/2.9-assess-series-upgrade - Merge pull request #13327 from wallyworld/azure-tests-fix - Merge pull request #13325 from SimonRichardson/raft-worker-errors - Merge pull request #13274 from SimonRichardson/lxd-network-devices-config-host-name - Merge pull request #13323 from jujubot/increment-to-2.9.15 - Merge pull request #13321 from wallyworld/more-secret-metadata - Merge pull request #13319 from manadart/2.9-bridge-policy - Merge pull request #13320 from SimonRichardson/revert-lxd-changes - Merge pull request #13194 from juanmanuel-tirado/patch-1 - Merge pull request #13318 from hpidcock/fix-1942948 - Merge pull request #13314 from simondeziel/snap-ack - Merge pull request #13297 from achilleasa/2.9-allow-empty-openvswitch-blocks-in-netplan-config - Merge pull request #13317 from jujubot/increment-to-2.9.14 - Merge pull request #13316 from hpidcock/fix-1942948 - Merge pull request #13296 from ycliuhw/fix/registry-oauth2 - Merge pull request #13311 from wallyworld/unitagent-missing-charm - Merge pull request #13315 from wallyworld/lxd-not-found-fix - Merge pull request #13221 from juanmanuel-tirado/status_watch_flag - Merge pull request #13312 from wallyworld/remove-txnwatcher-started - Merge pull request #13309 from kot0dama/fix-instrospection-posix-shell-2.9 The following files had merge conflicts that had to be resolved (please double-check the changes in last commit): - caas/kubernetes/provider/bootstrap_test.go - feature/flags.go - scripts/win-installer/setup.iss - snap/snapcraft.yaml - state/pool.go - version/version.go - worker/uniter/relation/state_test.go
Some time ago we did a significant overhaul of the payload delivery for updating machine address configuration. Included were changes to use members of the
NetworkConfig.Addresses
entries instead of those on the top levelNetworkConfig
. One of these was the address subnet CIDR.What we missed at the time was to change
NetworkConfigAPI.fixUpFanSubnets
so that it applied the Fan updates to theAddresses
entries and not the top-levelCIDR
member.This meant that Fan addresses were being stored with subnets indicating the /8 overlay instead of the zone-specific /12 segments in AWS, resulting in the observed bug.
Here we fix
fixUpFanSubnets
so that we get the fixed Fan segment subnets against incoming addresses.QA steps
juju bootstrap aws patch-test --debug --no-gui --build-agent
juju add-space space-1 172.31.0.0/20
juju add-machine --constraints "spaces=space-1" --series bionic
juju deploy cs:ubuntu --to lxd:0 --series focal --constraints "spaces=space-1" --bind "space-1"
Documentation changes
None.
Bug reference
https://bugs.launchpad.net/juju/+bug/1942950