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