I am using vsphere as provider and I am using placement to machines so I can condense. What ends up happening is that networking is setup on these units with this 10.0.4.0 network which I cannot access. For one of my services, I forgot to do placement and that unit got a dhcp address from my dhcp server and I could only access that unit.
This is from the bundle:
series: trusty
services:
ceilometer:
charm: cs:trusty/ceilometer
num_units: 1
to:
- lxd:3
ceilometer-agent:
charm: cs:trusty/ceilometer-agent
cinder:
charm: cs:trusty/cinder
num_units: 1
hwreqs:
storage: None
options:
block-device: None
ceph-osd-replication-count: 1
glance-api-version: 2
overwrite: 'true'
remove-missing-force: true
to:
- 0
machines:
0:
series: trusty
1:
series: trusty
2:
series: trusty
3:
series: trusty
After all the placement statements were removed in the 2nd bundle, deployment needed 15 units (compared with 5 for dense) and it ran out of resources on the last 2 which was expected. However, I could access all the units since they got DHCP addresses from DHCP server in my network.
I don't know if this issue is for all dense deployment or just deployment with sphere as provider so keeping this specific to vsphere.
I have included both bundles and status in the attachment.
This is density:
model: default
machines:
"0":
juju-status:
current: started
since: 15 Jun 2016 06:37:11Z
version: 2.0-beta8
dns-name: 10.0.4.23
instance-id: juju-72bde5-0
machine-status:
current: pending
since: 15 Jun 2016 06:34:40Z
series: trusty
containers:
0/lxd/0:
juju-status:
current: started
since: 15 Jun 2016 06:42:22Z
version: 2.0-beta8
dns-name: 10.0.4.23
instance-id: juju-72bde5-0-lxd-0
machine-status:
current: running
message: Container started
since: 15 Jun 2016 06:38:28Z
series: trusty
0/lxd/1:
juju-status:
current: started
since: 15 Jun 2016 06:48:20Z
version: 2.0-beta8
dns-name: 10.0.4.181
instance-id: juju-72bde5-0-lxd-1
machine-status:
current: running
message: Container started
since: 15 Jun 2016 06:39:16Z
series: trusty
and this is without machine placement:
model: default
machines:
"0":
juju-status:
current: started
since: 15 Jun 2016 12:15:28Z
version: 2.0-beta8
dns-name: 10.245.42.253
instance-id: juju-493f7f-0
machine-status:
current: pending
since: 15 Jun 2016 12:12:46Z
series: trusty
hardware: arch=amd64 cpu-cores=2 cpu-power=2000 mem=2000M root-disk=8192M
"1":
juju-status:
current: started
since: 15 Jun 2016 12:16:43Z
version: 2.0-beta8
dns-name: 10.245.42.8
instance-id: juju-493f7f-1
machine-status:
current: pending
since: 15 Jun 2016 12:12:54Z
series: trusty
hardware: arch=amd64 cpu-cores=2 cpu-power=2000 mem=2000M root-disk=8192M
"2":
juju-status:
current: started
since: 15 Jun 2016 12:17:42Z
version: 2.0-beta8
dns-name: 10.245.44.30
instance-id: juju-493f7f-2
machine-status:
current: pending
since: 15 Jun 2016 12:13:01Z
series: trusty
hardware: arch=amd64 cpu-cores=2 cpu-power=2000 mem=2000M root-disk=8192M
...
"13":
juju-status:
current: error
message: 'Can''t create instance in any of availability zones, last error: The
amount of CPU resource available in the parent resource pool is insufficient
for the operation.'
since: 15 Jun 2016 12:25:47Z
instance-id: pending
machine-status:
current: pending
since: 15 Jun 2016 12:14:24Z
series: trusty
"14":
juju-status:
current: error
message: 'Can''t create instance in any of availability zones, last error: The
amount of CPU resource available in the parent resource pool is insufficient
for the operation.'
since: 15 Jun 2016 12:26:27Z
instance-id: pending
machine-status:
current: pending
since: 15 Jun 2016 12:14:33Z
series: trusty
Versions:
jenkins@s9-lmic-trusty:~/vmware$ dpkg -l *juju*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-====================-===============-===============-==============================================
ii juju 2.0-beta8-0ubun all next generation service orchestration system
ii juju-2.0 2.0-beta8-0ubun amd64 Juju is devops distilled - client
un juju-core <none> <none> (no description available)
rc juju-core2 2.0-beta1-0ubun amd64 Juju is devops distilled - client
ii juju-deployer 0.8.0~bzr185~55 amd64 A tool to deploy complex stacks of services us
un juju2 <none> <none> (no description available)
ii python-jujuclient 0.50.3-1~ubuntu amd64 Python API client for juju-core
un python2.7-jujuclient <none> <none> (no description available)
jenkins@s9-lmic-trusty:~/vmware$ uname -a
Linux s9-lmic-trusty 3.13.0-87-generic #133-Ubuntu SMP Tue May 24 18:32:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
It almost looks like the lxd addresses are not getting filtered from the machines hosting lxd containers. If you can get it, it would be helpful to see from the hosts that are getting the 10.0.4.* addresses:
1 - /var/log/ cloud-init- output. log interfaces
2 - the contents of /etc/network/