Use case for: min-version

[Tim Penhey]

It would be trivial for the Juju version to be exported in the hook
context as environment variables.

Perhaps something like this:

JUJU_VERSION=1.24.4
JUJU_VERSION_MAJOR=1
JUJU_VERSION_MINOR=24
JUJU_VERSION_PATCH=4
# tag for 'alpha' 'beta'
JUJU_VERSION_TAG=

Thoughts?

Tim

On 12/08/15 07:48, Marco Ceppi wrote:
> 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 <mailto:stuart.bishop at canonical.com>> wrote:
> 
>     On 11 August 2015 at 03:32, Matt Bruzek
>     <matthew.bruzek at canonical.com <mailto: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
>     <mailto:stuart.bishop at canonical.com>>
> 
>     --
>     Juju-dev mailing list
>     Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
>