juju-deployer deploys the wrong unit series from charm store
The OpenStack Charms recently switched to multi-series. After that, the Amulet tests for Trusty are inoperable due to this bug in deployer. As illustrated below and in the attached files, Xenial units are deployed even when series is set to Trusty in the bundle. This causes series mismatches in subordinates, among other test failures which make assertions based on expected series.
Assertions re: attached
Machine 1: Should be Trusty, but is Xenial.
Machine 2: Is Trusty, but only because of the CS URL.
Machine 3: Should be Trusty, but is Xenial.
Machine 4: Should be Trusty, but is Xenial.
Machine 5: Is Trusty, but only because of the CS URL.
Machine 6: Should be Trusty, but is Xenial.
juju-deployer deploys the wrong unit series from charm store
The OpenStack Charms recently switched to multi-series. After that, the Amulet tests for Trusty are inoperable due to this bug in deployer. As illustrated below and in the attached files, Xenial units are deployed even when series is set to Trusty in the bundle. This causes series mismatches in subordinates, among other test failures which make assertions based on expected series.
⟫ pip freeze ssl-match- hostname= =3.5.0. 1 =0.9.2 =0.0.0 client= =0.37.0
backports.
juju-deployer=
jujuclient==0.53.3
pkg-resources=
PyYAML==3.12
six==1.10.0
websocket-
.
Assertions re: attached
Machine 1: Should be Trusty, but is Xenial.
Machine 2: Is Trusty, but only because of the CS URL.
Machine 3: Should be Trusty, but is Xenial.
Machine 4: Should be Trusty, but is Xenial.
Machine 5: Is Trusty, but only because of the CS URL.
Machine 6: Should be Trusty, but is Xenial.