Juju Packaging in Xenial

Nicholas Skaggs nicholas.skaggs at canonical.com
Wed Apr 20 15:09:43 UTC 2016


As many have noticed, there were some major packaging changes to Juju 
that impact those using Juju on Xenial[1]. I encourage everyone to read 
the full details, but in summary juju-2.0 is now the default Juju in 
Xenial. However, both juju-1.25 and juju-2.0 are available, and can be 
co-installed at the same time. They can be invoked by calling 
/usr/bin/juju-2.0 or /usr/bin/juju-1 (or /usr/bin/juju-1.25 ) 
respectively. To raise awareness, Juju will also display a message on 
first invocation after upgrade to inform the user of this change.


This change in the default version of /usr/bin/juju may cause cause 
issues with any tool or workflow that makes the assumption that 
/usr/bin/juju is juju-1. For instance, this affects deployer and 
amulet[2]. Migrating tools to support juju-2.0 is preferred, but to help 
with the transition, there is an easy way to restore juju-1 as the 
default Juju.  A new package called juju-1-default[3] is available in 
Xenial. If you wish to ensure /usr/bin/juju is juju-1, as it is in 
Trusty, simply install this package. It will keep /usr/bin/juju as 
juju-1 until you remove it. Note, this package is intended to help 
transition, rather than be seen as a permanent fix. Those that need 
juju-1 should migrate to using /usr/bin/juju-1 (/usr/bin/juju-1.25).


This change should help ease the transition to Xenial and Juju 2.0 
without breaking existing workflows. However, I still urge you to update 
tools to support juju-2.0. Being explicit andremoving assumptions about 
which version of juju is /usr/bin/juju should help avoid similar issues 
moving forward.


Thanks!

Nicholas


 1. https://lists.ubuntu.com/archives/juju-dev/2016-April/005313.html
 2. https://bugs.launchpad.net/juju-deployer/+bug/1571719
 3. http://packages.ubuntu.com/xenial/juju-1-default




More information about the Juju mailing list