(juju-deployer 0.9.0 + python-jujuclient 0.53.2 + juju 1.25.6) machine placement is broken

[Ryan Beisner]

Machine placement is broken for this combo:
juju-deployer 0.9.0 + python-jujuclient 0.53.2 + juju 1.25.6

Whereas the version combo that shipped with Xenial works well:
juju-deployer 0.6.4 + python-jujuclient 0.50.5 + juju 1.25.6

Several bundles that previously worked well wind up with applications on the wrong units, and in some cases more machines or fewer machines than expected.

The openstack-base, openstack-telemetry bundles are affected.

Here's a test example bundle with the unexpected juju status output as well: http://pastebin.ubuntu.com/23205474/

[Ryan Beisner (1chb1n)]

Added attachments (test-A*) from test runs with juju-deployer 0.6.4 and 0.9.0. The bundle works with 0.6.4 (7 machines) but is mis-rendered with 0.9.0 (18 machines).

Will be adding another set of attachments to illustrate the impact to the openstack-telemetry bundle.

[Ryan Beisner (1chb1n)]

This is a blocker for OSCI to ramp up Juju 2 while continuing to test Juju 1.25.6, as 0.9.0 is where the Juju 2 deployer features exist.

[Ryan Beisner (1chb1n)]

Also added telemetry bundle attachments, with juju status yaml output from a 0.6.4 run (ok) and a 0.9.0 run (not ok).

There are a number of things wrong with the picture when comparing expected output with actual. Here is one example:

ceph-osd/0 on machine 1
ceph-osd/1 on machine 2
ceph-osd/2 on machine 2 instead of 3.

Machine 3 doesn't exist, but sure should.

[Tom Haddon (mthaddon)]

Marking as invalid in Mojo as this has been addressed in juju-deployer

[Tom Haddon (mthaddon)]

Marking as fix released as this has been committed in a version of juju-deployer that has been released for some time.