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 > <[email protected] <mailto:[email protected]>> wrote: > > On 11 August 2015 at 03:32, Matt Bruzek > <[email protected] <mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]>> > > -- > Juju-dev mailing list > [email protected] <mailto:[email protected]> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
