2.1 network uses lock 1662586

[jameinel]

Description of change

Change the Bridging code to use the machine-lock while executing.

QA steps

I tried to create a charm that would exercise the network while another charm was deployed, but I wasn't successful in reproducing this. The associated bug does have some examples of it happening in the wild. There are a few hypothetical issues:

• You have to be doing something significant over the network that takes enough time during the install hook.
• Your first container does wait for the lock, because it needs the lock to 'apt install lxd' etc. So either the container initialization has to happen first, and then release the lock, or somehow the ordering has to be just right.
• My test was trying to do something with a local service that I could ensure would take a long time, but its possible that even though I was connecting to the IP address that was being brought down and back up again, sockets are smart enough to not die if the downtime is short enough.

It might be possible to "juju deploy $SOMETHING --to lxd:0" and then "juju deploy $ELSE --to 0", and have the lxd initialization trigger, but while it is downloading the container image, the ELSE starts doing its thing and ends up racing with the container image finally downloading and triggering us wanting to change networking with the install hook downloading something. (I'm not entirely sure that we wait for the image to be downloaded before we reconfigure bridging, though, I'm not 100% sure when the image is downloaded vs when the bridging is done.)

Documentation changes

No specific CLI/API changes.

Bug reference

https://pad.lv/1662586

[jameinel]

$$merge$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

[jujubot]

Build failed: Generating tarball failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/10240

[jameinel]

$$merge$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju