always record machine network config. #6896

Merged
merged 1 commit into from Feb 1, 2017

Conversation

Projects
None yet
3 participants
Owner

jameinel commented Feb 1, 2017

Description of change

We were only recording it if we had provider config to merge with it.
However, this will be useful to have everywhere and it lets us move forward
with some of our explicit decisions on how we want to do bridging, etc.
Note that containers now start 'properly' on AWS, but only because
of a sequence of failures and fallbacks that gets us to invoke old
code paths.

Namely, we see the machine, we trigger the 'fallback' to bridge all
interfaces, which says 'create br-eth0'. The bridge script runs, but
fails to actually create br-eth0 because the definition of eth0 is
actually in /e/n/interfaces.d/50cloud.cfg, and it doesn't read it.
However, the call to 'prepareHost' already succeeded, so we continue
with the next step. It then asks what devices to create for the
container it is starting, which comes back with 'I dont know',
which it then says, 'well then, I'll fall back to lxdbr0', and thus
starts a container in the old way.

QA steps

"juju bootstrap" on any cloud that isn't MAAS and inspect the database to notice db.linklayerdevices.find().pretty() returns actual values. (without this patch there are no records.)

Bug reference

This is part of fixing https://pad.lv/1657449 but doesn't fully address that yet.

Only a nit but LGTM

return m.SetMachineAddresses(hostAddresses)
}
func (mr *Machiner) Handle(_ <-chan struct{}) error {
+ logger.Infof("got a Machiner.Handle() event")
@perrito666

perrito666 Feb 1, 2017

Contributor

do you want this to be Info?

@jameinel

jameinel Feb 1, 2017

Owner

nope, it was a debug at one point in the past while I figured out what was going on, should be just removed.

always record machine network config.
We were only recording it if we had provider config to merge with it.
However, this will be useful to have everywhere and it lets us move forward
with some of our explicit decisions on how we want to do bridging, etc.
Note that containers now start 'properly' on AWS, but only because
of a sequence of failures and fallbacks that gets us to invoke old
code paths.

Namely, we see the machine, we trigger the 'fallback' to bridge all
interfaces, which says 'create br-eth0'. The bridge script runs, but
fails to actually create br-eth0 because the definition of eth0 is
actually in /e/n/interfaces.d/50cloud.cfg, and it doesn't read it.
However, the call to 'prepareHost' already succeeded, so we continue
with the next step. It then asks what devices to create for the
container it is starting, which comes back with 'I dont know',
which it then says, 'well then, I'll fall back to lxdbr0', and thus
starts a container in the old way.
Owner

jameinel commented Feb 1, 2017

$$merge$$

Contributor

jujubot commented Feb 1, 2017

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

Contributor

jujubot commented Feb 1, 2017

Build failed: Tests failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/10166

Owner

jameinel commented Feb 1, 2017

$$merge$$ BundleTimeout

Contributor

jujubot commented Feb 1, 2017

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

@jujubot jujubot merged commit 89a4a8d into juju:2.1 Feb 1, 2017

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