On 03/21/2016 06:54 PM, Stuart Bishop wrote:
On 22 March 2016 at 11:42, Rick Harding <rick.hard...@canonical.com> wrote:
I believe that went out and is ok Stuart. The charmstore update is deployed
and when you upload a multi-series charm to the charmstore it creates
separate charms that work on older clients. If you hit issues with that
please let me know.
Its only fixed for charms served from the charm store. CI systems and
such test branches, for example ensuring tests pass before uploading a
release to the charm store. I suspect this is exactly what Ryan needs
to do and why I mentioned the open bug. Unless 1.25 is updated to
handle the different data types, CI systems will need to work around
the issue by either roundtripping through the charm store (in a
personal namespace to avoid mid air collisions) or munging
metadata.yaml.
This is correct. OpenStack charms will be affected. For much of our CI
before publishing to the charm store we pull from branches both git and
bzr. Using 1.25 we will either have to delay implementing series in the
metadata.yaml or we will have to work around and alter metadata.yaml on
disk.
Having a juju solution for Bug#1545686 would greatly help our testing.
--
David Ames
Rationale and use case:
A single Keystone charm supports deployment (thereby enabling continued
CI &
testing) of Precise, Trusty, Wily, Xenial and onward. It is planned to
have
a min-juju-version value of 1.25.x. That charm will support >= 1.25.x,
including 2.x, and is slated to release with 16.04. This is
representative
of all of the OpenStack charms.
Bug #1545686 will cause you issues too, unless you are always testing
charms served from the store rather than local branches. 'series' is
more involved than min-juju-version, as the data type change to the
existing setting causes old versions to fail.
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
