Use case for: min-version

[Marco Ceppi]

I'm not sure how I missed this bit of code, but I'm not a fan of it as it
assumes paths in the deployed environment which have changed already in
Juju's history and could potentially change again.

Instead of globing around for juju binaries and parsing outputs of commands
(which themselves may very well change in the future). I'm a much bigger
fan of what Chuck B and Matt B did in the etcd charm. A lot of the juju
commands in the charm-helpers library will degrade cleanly (ie status-set
will degrade to using juju-log) the commands that can't degrade, like
leader-is, leader-set, and leader-get will raise a NotImplementedError
which the code can respond to. They've done this by adding an attempt to
invoke the command at the top of the file and handling the exception from
there.

https://github.com/whitmo/etcd-charm/commit/7eb5166ded7609fffb0b66df9a4cb5ef66713bdc

I'd much rather see charms check for features existence rather than attempt
to perform version matching until Juju gains the ability to signal version
compat for charms.

Marco Ceppi

On Tue, Aug 11, 2015 at 3:46 AM Stuart Bishop <stuart.bishop at canonical.com>
wrote:

> On 11 August 2015 at 03:32, Matt Bruzek <matthew.bruzek at canonical.com>
> wrote:
> >
> > We wrote a charm that needed election logic, so we used the new Juju
> feature
> > "is_leader".  A user was interested in using a bundle that contained this
> > charm and it failed on them.  It was hard to track down the cause of the
> > problem.  It appears they were using an earlier version of Juju that is
> > available from universe and only the PPA had the more current version.
> >
> > Read more about the problem here:
> > https://bugs.launchpad.net/charms/+source/etcd/+bug/1483380
> >
> > I heard the "min-version" feature discussed at previous Cloud sprints
> but to
> > my knowledge we do not have it implemented yet.  The idea was a charm
> could
> > specify in metadata.yaml what min-version of Juju they support.
> >
> > There are a lot of new features that juju-core are cranking out (and
> that is
> > *awesome*)!  We have already run into this problem with a real user, and
> > will have the problem in the future.
> >
> > Can we reopen the discussion of min-version?  Or some other method of
> > preventing this kind of problem in the future?
>
> charmhelpers already supports this with
> charmhelpers.core.hookenv.has_juju_version, thanks to Curtis who
> described a reliable way of accessing it.
>
> Adding it to the official hook environment is
> https://bugs.launchpad.net/juju-core/+bug/1455368
>
> It is particularly useful for:
>
> hookenv.status_set('blocked', "I'm in a right pickle. Help!")
> if hookenv.has_juju_version('1.24'):
>     raise SystemExit(0)  # Blocked state, 1.24+
> raise SytemExit(1)  # Error state, <1.23
>
> I've also got version checks in charmhelpers.coordinator, which
> requires leadership.
>
> --
> Stuart Bishop <stuart.bishop at canonical.com>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150811/d82b138b/attachment.html>