juju-deployer deploys the wrong unit series from charm store

[Ryan Beisner]

juju-deployer (with juju 1.25) deploys the wrong series unit from the charm store.

⟫ pip freeze
backports.ssl-match-hostname==3.5.0.1
juju-deployer==0.9.2
jujuclient==0.53.3
pkg-resources==0.0.0
PyYAML==3.12
six==1.10.0
websocket-client==0.37.0

[Ryan Beisner (1chb1n)]

Further clarification:

juju-deployer remains a critical library in the charm test story, as Amulet uses juju-deployer, whether Juju 1.x or Juju 2.x, and Bundletester uses Amulet.

The OSCI test gate is blocked for testing any series other than Xenial at this time.

[Liam Young (gnuoy)]

I'm looking into this but looking at the output from your example I'd say that
all deployments have done what I'd expect and honoured the series encoded in the
charm store url if there is one. Only the 'auto' deployments are wrong and I don't
think juju-deployer can do anything about them in a juju 1.X environment apart from
grab a copy of the charm from charmstore create a local dir inside a 'series' dir and
deploy from that. Perhaps this is what deployer used to do but I can't find any evidence of that
atm

Application Name Location Specified in Bundle Location Displayed in Status Machine No Series
rabbitmq-server-auto cs:~openstack-charmers-next/rabbitmq-server cs:~openstack-charmers-next/xenial/rabbitmq-server-244 1 xenial
rabbitmq-server-trusty cs:~openstack-charmers-next/trusty/rabbitmq-server cs:~openstack-charmers-next/trusty/rabbitmq-server-244 2 trusty
rabbitmq-server-xenial cs:~openstack-charmers-next/xenial/rabbitmq-server cs:~openstack-charmers-next/xenial/rabbitmq-server-244 3 xenial
ubuntu-auto cs:ubuntu cs:xenial/ubuntu-8 4 xenial
ubuntu-trusty cs:trusty/ubuntu cs:trusty/ubuntu-8 5 trusty
ubuntu-xenial cs:xenial/ubuntu cs:xenial/ubuntu-8 6 xenial

Application Name Location Specified in Bundle Location Displayed in Status Machine No Series
rabbitmq-server-auto cs:~openstack-charmers-next/xenial/rabbitmq-server-244 1 xenial
rabbitmq-server-trusty cs:~openstack-charmers-next/trusty/rabbitmq-server-244 2 trusty
rabbitmq-server-xenial cs:~openstack-charmers-next/xenial/rabbitmq-server-244 3 xenial
ubuntu-auto cs:xenial/ubuntu-8 4 xenial
ubuntu-trusty cs:trusty/ubuntu-8 5 trusty
ubuntu-xenial cs:xenial/ubuntu-8 6 xenial

[Liam Young (gnuoy)]

Update with formatting: http://paste.ubuntu.com/23511967/

[Ryan Beisner (1chb1n)]

See the attached bundle reproducer and sample Juju status output.

[Ryan Beisner (1chb1n)]

Re-classed medium as we have worked around it. It is still an unexpected trip hazard for users, so still tracking.

[Ryan Beisner (1chb1n)]

Triaged high for lp:openstack-charm-testing, as the next and default yaml bundle reference files already contain cs:foo, and for example, the trusty-mitaka deploy target results in xenial aodh, designate and designate-bind units, mixed with trusty everything else.

[Tom Haddon (mthaddon)]

I'm going to assume this is no longer needed as we'd use native juju bundles for this now.