provider/maas: persist bridge script #6599
Conversation
Previously the MAAS script that bridges interfaces was deleted from the filesystem after it had run because it was a one-time only event. As we are now moving towards dynamic bridging we need permanent access to the script; the script is now persisted in /var/lib/juju. That path is not hard-coded, it comes from calling: paths.DataDir(series). QA steps: 1) bootstrap on MAAS 2) verify that /var/lib/juju/add-juju-bridge.py exists 3) verify that /var/lib/juju/add-juju-bridge.py is executable 4) reboot machine, and verify (2) and (3) post reboot 5) verify bridge(s) exist: $(brctl show)
frobware
force-pushed
the
persist-bridge-script
branch
from
5a06e8b
to
905cbce
Compare
There was a problem hiding this comment.
Could we actually land this as is? I'm specifically looking at the fact that we are moving where the script is located. I suppose as part of that we're not calling it anymore. Wouldn't we have some sort of functional CI test that would fail to create containers on MAAS in that situation?
| @@ -8,10 +8,7 @@ bridgescript.go: add-juju-bridge.py Makefile | |||
| $(RM) $@ | |||
| echo -n '// This file is auto generated. Edits will be lost.\n\n' >> $@ | |||
| echo -n 'package maas\n\n' >> $@ | |||
| echo -n '//go:generate make -q\n\n' >> $@ | |||
There was a problem hiding this comment.
Why remove this line?
Don't we need "make" in order to build this .go file to include the .py file as a string?
I suppose we don't need "import path", but I think we do want to keep the "//go:generate" line. (I believe it tells 'go build' to run 'make -q' to regenerate this file).
There was a problem hiding this comment.
It was never used. We don't have a top-down rule that runs go generate. If I change the script I have (for ever) just run make in the provider/maas directory, then commit those changes.
There was a problem hiding this comment.
The go generate mechanism never materialised in the build because, for a long time, we were stuck on versions of go that did not support go generate.
| @@ -168,14 +171,18 @@ func (*environSuite) TestNewCloudinitConfigWithDisabledNetworkManagement(c *gc.C | |||
| c.Assert(cloudcfg.RunCmds(), jc.DeepEquals, expectedCloudinitConfig) | |||
| } | |||
|
|
|||
| func (*environSuite) TestRenderEtcNetworkInterfacesScriptMultipleNames(c *gc.C) { | |||
| script := maas.RenderEtcNetworkInterfacesScript("eth0", "eth0:1", "eth2", "eth1") | |||
| func (*environSuite) xTestRenderEtcNetworkInterfacesScriptMultipleNames(c *gc.C) { | |||
There was a problem hiding this comment.
Thank you. Was testing various combos by commenting them out to ensure they did something real. Reinstating.
|
Also note: the script is still executed, bridging interfaces that have a subnet/address as before. Only the location of the script has changed. Was /var/tmp, now /var/lib/juju. |
|
|
||
| var bridgeScriptPath string | ||
|
|
||
| bridgeScriptPath, err = bridgeScriptPathForSeries(forSeries) |
There was a problem hiding this comment.
bridgeScriptPath, err := and drop the var above?
|
|
||
| bridgeScriptPath, err = bridgeScriptPathForSeries(forSeries) | ||
| if err != nil { | ||
| return nil, err |
|
QA steps:
I did follow-up with these in a subsequent commit - they just don't show in the original commit message in GitHub. Not an existing bug; feature work (gasp!). |
|
|
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
Previously the MAAS script that bridges interfaces was deleted from
the filesystem after it had run because it was a one-time only event.
As we are now moving towards dynamic bridging we need permanent access
to the script; the script is now persisted in /var/lib/juju. That path
is not hard-coded, it comes from calling: paths.DataDir(series).