Use case for: min-version

[Stuart Bishop]

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>