juju use lxcbr0 rather than juju-r0

[Lei Wang]

Run "juju deploy <services> --to lxc:0" to deploy service in a container. it's always pending, by checking the logs

itialisation.go:105 initial container setup with ids: [3/lxc/16]
2015-08-28 10:11:59 INFO juju.provisioner provisioner_task.go:408 found machine pending provisioning id:3/lxc/16, details:3/lxc/16
2015-08-28 10:11:59 INFO juju.provisioner provisioner_task.go:253 provisioner-harvest-mode is set to destroyed; unknown instances not stopped []
2015-08-28 10:11:59 INFO juju.provisioner.lxc lxc-broker.go:84 starting lxc container for machineId: 3/lxc/16
2015-08-28 10:11:59 DEBUG juju.provisioner lxc-broker.go:96 address allocation feature flag not enabled; using DHCP for container "3/lxc/16"
2015-08-28 10:12:00 DEBUG juju.service discovery.go:65 discovered init system "upstart" from series "trusty"
2015-08-28 10:12:00 INFO juju.container.lxc clonetemplate.go:32 wait for flock on juju-trusty-lxc-template
2015-08-28 10:12:00 INFO juju.container lock.go:50 acquire lock "juju-trusty-lxc-template", ensure clone exists
2015-08-28 10:12:00 INFO juju.container.lxc clonetemplate.go:74 template exists, continuing
2015-08-28 10:12:00 INFO juju.container lock.go:66 release lock "juju-trusty-lxc-template"
2015-08-28 10:12:00 INFO juju.container.lxc clonetemplate.go:32 wait for flock on juju-trusty-lxc-template
2015-08-28 10:12:00 INFO juju.container lock.go:50 acquire lock "juju-trusty-lxc-template", clone
2015-08-28 10:12:02 INFO juju.container lock.go:66 release lock "juju-trusty-lxc-template"
2015-08-28 10:12:02 INFO juju.provisioner.lxc lxc-broker.go:166 started lxc container for machineId: 3/lxc/16, juju-machine-3-lxc-16, arch=amd64
2015-08-28 10:12:03 INFO juju.provisioner provisioner_task.go:714 started machine 3/lxc/16 as instance juju-machine-3-lxc-16 with hardware "arch=amd64", networks [], interfaces [], volumes [], volume attachments map[]

It looks like the configuration of lxc containers use wrong bridge

[Lei Wang (raywang)]

the containers deployed by juju may use /var/lib/lxc/juju-trusty-lxc/template/config, so this bug might be invalid

[Lei Wang (raywang)]

Even the /var/lib/lxc/juju-trusty-lxc/template/config is correct, but the containers deployed by juju is still all pending.
Maybe i'm wrong, I expect someone could mark this as invalid

[Dimiter Naydenov (dimitern)]

Please, provide some more information: environments.yaml config (scrubbed of secrets/keys/passwords), the bootstrap log with --debug, if you can reproduce the issue.

Juju is not changing /etc/default/lxc.conf (the system-wide bridge to use), but rather generates the config for each LXC container, the template one included. So it will be also useful to see any logs and configs you have in /var/lib/juju/containers/, /var/log/lxc/, /var/lib/lxc/.

[Dimiter Naydenov (dimitern)]

Forgot to mention that the agent.conf in /var/lib/juju/agents/ on the host machine of the failed LXC container can also be useful to see (apply same scrubbing for secrets/keys as for environments.yaml).

[Lei Wang (raywang)]

It turns out to be the ports are tagged automatically by HP C7000 backplane.
So mark this bug as invalid

Thanks Dimiter for the help.