/juju

Simplify and refactor merging observed and provider network configs #6219

Closed
wants to merge 6 commits into
from

Conversation

Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@dimitern
@dimitern
Contributor

dimitern commented Sep 12, 2016 •
Edited 1 time

Follow-up to #6158, part of the necessary steps to fix http://pad.lv/1566791

Most of the complicated logic around merging, sorting, etc. is gone and
as lost simpler approach was taken - use the observed config and only
update the provider-specific bits, matching the corresponding provider
config by name of the interface or the address.

QA Steps:

  • On vMAAS Version 1.9.4+bzr4592-0ubuntu1 (trusty1)
  • Using 2 nodes, configured like this: http://pasteboard.co/2GPHldImy.png (maas-19-node-5), http://pasteboard.co/2GQDmB4WI.png (maas-19-node-3).
  • juju bootstrap m19 vmaas-19 --config=~/.j/conf-x-fast.yaml --to maas-19-node-5 (config used: http://paste.ubuntu.com/23174815/)
  • juju switch controller
  • juju add-machine maas-19-node-3
  • juju add-machine lxd:0
  • juju add-machine lxd:1
  • watch 'juju status'
  • Wait for all machines to show as 'started'.
  • Expect 0/lxd/0 to come up with 1 NIC: eth0 on subnet 10.20.19.0/24
  • Expect 1/lxd/0 to come up with 8 NICs: eth0 and eth4 on subnet 10.20.19.0/24, eth1 on 10.100.19.0/24, eth2 on 10.150.19.0/24, eth3 on 10.50.19.0/24, eth5 on 10.200.19.0/24, eth6 on 10.250.19.0/24, eth7 on 10.30.19.0/24.
  • juju kill-controller m19
  • On the same MAAS, using the same nodes and steps, but with a trusty config: juju bootstrap m19 vmaas-19 --config=~/.j/conf-t-fast.yaml --to maas-19-node-5 (config: http://paste.ubuntu.com/23175071/)
  • Expect the same results, albeit the initial boot on maas-19-node-3 will be noticeably slower, due to the known ntpdate lockfile race with trusty.
  • On vMAAS Version 2.0.0+bzr5189-0ubuntu1 (16.04.1)
  • Same steps, as above, same xenial config, nodes configured the same way: http://pasteboard.co/2GOU0r6Kw.png (maas-20-node-5), http://pasteboard.co/2GPfJJv44.png (maas-20-node-3)
  • Expect the same results for the number of NICs on the LXD containers (albeit with the respective subnets - 10.20.20.0/24, 10.100.20.0/24, 10.150.20.0/24, 10.150.20.0/24, 10.50.20.0/24, 10.200.20.0/24, 10.250.20.0/24, 10.30.20.0/24).

(Review request: http://reviews.vapour.ws/r/5654/)

This was referenced Sep 15, 2016

Closed
Merged
Merged

jujubot added a commit that referenced this pull request Sep 20, 2016

@jujubot
Merge pull request #6281 from frobware/lp-1566791-bridge-all 
mass/provider: bridge all devices

Fixes [LP:#1566791](https://bugs.launchpad.net/juju/+bug/1566791)

Previously interfaces in MAAS that were unconfigured would not have
corresponding interfaces in the container and the resultant
combination of the providers network configuration and what was
observed after bridging meant that all interfaces in the container
would use lxdb0 as their parent device - they should have been using
their respective parent bridges on the host.

We now bridge all interfaces even if a parent interface has no subnet
or is unconfigured.

This commit rolls up PR #6219, PR #6257, PR #6219. It also reinstates
PR #6156. Each of these PRs have been individually reviewed. This
branch has also had a full CI run:

http://reports.vapour.ws/releases/4406 

And quoting Curtis:

    "this shows 3 classes of issue, non of which is related to the
     branch under test. You can merge, you won't do any more damage
     than is already there."

We have also had independent verification from two other sources that
had broken LXD networking on MAAS and this change fixed their cases.

QA verification: without this fix on either MAAS 1.9 or MAAS 2.0 if
you have a network setup that has a VLAN but its parent device is
unconfigured, ala:

    eth0 192.168.1.0/24 <unconfigured>
    eth0.100 192.168.100.0 <auto|static>

then:

    $ juju add-machine
    $ juju add-machine lxd:0
    $ juju status

You will see from the status output that the container is on a
10.0.0.x address. It should be on the 192.168.100.0/24 subnet.
9472d9d
@dimitern
Contributor

dimitern commented Sep 20, 2016

Merged along with #6258

@dimitern dimitern closed this Sep 20, 2016

@dimitern dimitern deleted the dimitern:lp-1566791-apiserver-2 branch Sep 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment