juju deploy <service> --to lxd:0 does not work with lxd provider

[Adam Stokes]

Doing a test against latest upstream dd9828e, lxd provider, bootstrap with trusty series.

$ juju add-machine
$ juju deploy mysql --to lxd:0
$ juju deploy wordpress --to lxd:1

$ juju status
[Services]
NAME STATUS EXPOSED CHARM
mysql error false cs:trusty/mysql-38
wordpress error false cs:trusty/wordpress-4

[Relations]
SERVICE1 SERVICE2 RELATION TYPE
mysql mysql cluster peer
wordpress wordpress loadbalancer peer

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
mysql/0 error lost cannot add a new machine: machine 0 cannot host lxd containers
wordpress/0 error lost cannot add a new machine: machine 1 cannot host lxd containers

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 10.0.4.147 juju-8e293a57-9df1-4428-85c6-89f2b23f14cd-machine-0 trusty
1 started 10.0.4.159 juju-8e293a57-9df1-4428-85c6-89f2b23f14cd-machine-1 trusty

With Xenial we get the following:

[Services]
NAME STATUS EXPOSED CHARM
wordpress unknown false cs:trusty/wordpress-4

[Relations]
SERVICE1 SERVICE2 RELATION TYPE
wordpress wordpress loadbalancer peer

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
wordpress/0 unknown allocating 1/lxd/0 Waiting for agent initialization to finish

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 10.0.4.179 juju-d3c94e58-6fd5-45da-8986-de930799684a-machine-0 trusty
1 started 10.0.4.39 juju-d3c94e58-6fd5-45da-8986-de930799684a-machine-1 xenial

+-----------------------------------------------------+---------+--------------------------------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-----------------------------------------------------+---------+--------------------------------+------+------------+-----------+
| juju-cb22aa8b-762b-43cd-808d-7b5a76002285-machine-0 | RUNNING | 10.0.3.1 (lxcbr0) | | PERSISTENT | 0 |
| | | 10.0.4.209 (eth0) | | | |
+-----------------------------------------------------+---------+--------------------------------+------+------------+-----------+
| juju-d3c94e58-6fd5-45da-8986-de930799684a-machine-0 | RUNNING | 10.0.4.179 (eth0) | | PERSISTENT | 0 |
+-----------------------------------------------------+---------+--------------------------------+------+------------+-----------+
| juju-d3c94e58-6fd5-45da-8986-de930799684a-machine-1 | RUNNING | 10.0.4.39 (eth0) | | PERSISTENT | 0 |
| | | 10.0.3.1 (lxcbr0) | | | |
| | | 10.0.5.1 (lxdbr0) | | | |
+-----------------------------------------------------+---------+--------------------------------+------+------------+-----------+

lxdbr0 is created for the nested lxd's (10.0.5.1) but the nested container is never fully started.

[Cheryl Jennings (cherylj)]

There is an explicit check to determine whether or not a machine can host containers. When a machine agent starts up, it checks to see if the machine is running in a container, and if it is, that machine cannot host containers.

Whether or not we change that behavior for the lxd provider will need to be discussed for 2.1.

[Anastasia (anastasia-macmood)]

Related to, if not a duplicate of, bug # 1577638.

[Anastasia (anastasia-macmood)]

Removing 2.1 milestone as we will not be addressing this issue in 2.1.

[Heather Lanigan (hmlanigan)]

The LXD provider has significantly changed since this bug was originally filed, `juju deploy ubuntu --to lxd:0` now works, provided that machine 0 exists.