Re: Juju devel 2.0-alpha1 is available for testing
On Thursday, January 21, 2016, Marco Ceppi wrote: > Wow! A lot to play with tomorrow. Thanks for the release core team! > +,1 some solid bits to start testing with. Looking forward to exploring. Thanks juju-core folks. -Antonio > On Thu, Jan 21, 2016, 5:06 PM Curtis Hovey-Canonical > wrote: > >> # juju-core 2.0-alpha1 >> >> A new development release of Juju, juju-core 2.0-alpha1, is now available. >> This release replaces version 1.26-alpha3. >> >> >> ## Getting Juju >> >> juju-core 2.0-alpha1 is available for Xenial and backported to earlier >> series in the following PPA: >> >> https://launchpad.net/~juju/+archive/devel >> >> Windows, Centos, and OS X users will find installers at: >> >> https://launchpad.net/juju-core/+milestone/2.0-alpha1 >> >> Development releases use the "devel" simple-streams. You must configure >> the 'agent-stream' option in your environments.yaml to use the matching >> juju agents. >> >> Upgrading from older releases to this development release is not >> supported. >> >> >> ## Notable Changes >> >> * Terminology >> * Testing Advice >> * Command Name Changes >> * Multi-Model Support Active by Default >> * Native Support for Charm Bundles >> * Multi Series Charms >> * Improved Local Charm Deployment >> * LXD Provider >> * Microsoft Azure Resource Manager Provider >> * Bootstrap Constraints, Series >> * Juju Logging Improvements >> * Unit Agent Improvements >> * API Login with Macaroons >> * MAAS 1.8 Compatibility >> >> >> ### Terminology >> >> In Juju 2.0, environments will now be referred to as "models". Commands >> which referenced "environments" will now reference "models". Example: >> >> juju get-environment >> >> will become >> >> juju get-model >> >> >> The "state-server" from Juju 1.x becomes a "controller" in 2.0. The >> change in terminology will be done across several alphas, so messages >> and errors provided by juju may still reference "environments". >> >> >> ### Testing Advice >> >> Juju 2.0's new features and behaviours will confuse older Juju clients. >> It is best to create a new juju home to ensure you can revert to a 1.x >> Juju client. You can move an existing .juju/ directory out of the way or >> create a new directory and export it for Juju to find like so: >> >> export JUJU_HOME=~/new-juju-testing >> >> If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x >> reports problems with the environment, you can delete ~/.go-cookie and >> the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x. >> Juju 2.0 will store its data in a new location soon. >> >> It is not possible to test an upgrade from Juju 1.x to 2.0 at this time. >> Juju will support this in future releases. >> >> >> ### Command Name Changes >> >> After a while experimenting with nested command structures, the decision >> was made to go back to a flat command namespace as the nested commands >> always felt clumsy and awkward when being used even though they seemed >> like a good idea. >> >> So, we have the following changes: >> >> 1.25 command 2.0-alpha1 command >> >> juju environment destroy juju destroy-environment * >> juju environment get juju get-environment ** >> juju environment get-constraints juju get-constraints ** >> juju environment retry-provisioningjuju retry-provisioning >> juju environment set juju set-environment ** >> juju environment set-constraints juju set-constraints ** >> juju environment share juju share-environment >> juju environment unset juju unset-environment ** >> juju environment unshare juju unshare-environment >> juju environment users juju list-shares >> juju user add juju add-user >> juju user change-password juju change-user-password >> juju user credentials juju get-user-credentials >> juju user disable juju disable-user >> juju user enable juju enable-user >> juju user info juju show-user >> juju user list juju list-users >> >> * the behaviour of destroy-environment has changed, see the section on >> controllers below >> ** these commands existed at the top level before but become the >> recommended approach again. >> >> And for the extra commands previously under the "jes" feature flag but >> now available out of the box: >> >> juju system create-environment juju create-environment >> juju system destroyjuju destroy-controller >> juju system environments juju list-environments >> juju system kill juju kill-controller >> juju system list juju list-controllers >> juju system list-blocksjuju list-all-blocks >> juju system login juju login >> juju system remove-blocks juju remove-all
Re: Juju devel 2.0-alpha1 is available for testing
Wow! A lot to play with tomorrow. Thanks for the release core team! On Thu, Jan 21, 2016, 5:06 PM Curtis Hovey-Canonical wrote: > # juju-core 2.0-alpha1 > > A new development release of Juju, juju-core 2.0-alpha1, is now available. > This release replaces version 1.26-alpha3. > > > ## Getting Juju > > juju-core 2.0-alpha1 is available for Xenial and backported to earlier > series in the following PPA: > > https://launchpad.net/~juju/+archive/devel > > Windows, Centos, and OS X users will find installers at: > > https://launchpad.net/juju-core/+milestone/2.0-alpha1 > > Development releases use the "devel" simple-streams. You must configure > the 'agent-stream' option in your environments.yaml to use the matching > juju agents. > > Upgrading from older releases to this development release is not > supported. > > > ## Notable Changes > > * Terminology > * Testing Advice > * Command Name Changes > * Multi-Model Support Active by Default > * Native Support for Charm Bundles > * Multi Series Charms > * Improved Local Charm Deployment > * LXD Provider > * Microsoft Azure Resource Manager Provider > * Bootstrap Constraints, Series > * Juju Logging Improvements > * Unit Agent Improvements > * API Login with Macaroons > * MAAS 1.8 Compatibility > > > ### Terminology > > In Juju 2.0, environments will now be referred to as "models". Commands > which referenced "environments" will now reference "models". Example: > > juju get-environment > > will become > > juju get-model > > > The "state-server" from Juju 1.x becomes a "controller" in 2.0. The > change in terminology will be done across several alphas, so messages > and errors provided by juju may still reference "environments". > > > ### Testing Advice > > Juju 2.0's new features and behaviours will confuse older Juju clients. > It is best to create a new juju home to ensure you can revert to a 1.x > Juju client. You can move an existing .juju/ directory out of the way or > create a new directory and export it for Juju to find like so: > > export JUJU_HOME=~/new-juju-testing > > If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x > reports problems with the environment, you can delete ~/.go-cookie and > the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x. > Juju 2.0 will store its data in a new location soon. > > It is not possible to test an upgrade from Juju 1.x to 2.0 at this time. > Juju will support this in future releases. > > > ### Command Name Changes > > After a while experimenting with nested command structures, the decision > was made to go back to a flat command namespace as the nested commands > always felt clumsy and awkward when being used even though they seemed > like a good idea. > > So, we have the following changes: > > 1.25 command 2.0-alpha1 command > > juju environment destroy juju destroy-environment * > juju environment get juju get-environment ** > juju environment get-constraints juju get-constraints ** > juju environment retry-provisioningjuju retry-provisioning > juju environment set juju set-environment ** > juju environment set-constraints juju set-constraints ** > juju environment share juju share-environment > juju environment unset juju unset-environment ** > juju environment unshare juju unshare-environment > juju environment users juju list-shares > juju user add juju add-user > juju user change-password juju change-user-password > juju user credentials juju get-user-credentials > juju user disable juju disable-user > juju user enable juju enable-user > juju user info juju show-user > juju user list juju list-users > > * the behaviour of destroy-environment has changed, see the section on > controllers below > ** these commands existed at the top level before but become the > recommended approach again. > > And for the extra commands previously under the "jes" feature flag but > now available out of the box: > > juju system create-environment juju create-environment > juju system destroyjuju destroy-controller > juju system environments juju list-environments > juju system kill juju kill-controller > juju system list juju list-controllers > juju system list-blocksjuju list-all-blocks > juju system login juju login > juju system remove-blocks juju remove-all-blocks > juju system use-environmentjuju use-environment > > Fundamentally, listing things should start with 'list-', and looking at > an individual thing should start with 'show-'. 'remove' is generally > used for things that can be easily added back, whereas 'destroy' is used >
Juju devel 2.0-alpha1 is available for testing
# juju-core 2.0-alpha1 A new development release of Juju, juju-core 2.0-alpha1, is now available. This release replaces version 1.26-alpha3. ## Getting Juju juju-core 2.0-alpha1 is available for Xenial and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/devel Windows, Centos, and OS X users will find installers at: https://launchpad.net/juju-core/+milestone/2.0-alpha1 Development releases use the "devel" simple-streams. You must configure the 'agent-stream' option in your environments.yaml to use the matching juju agents. Upgrading from older releases to this development release is not supported. ## Notable Changes * Terminology * Testing Advice * Command Name Changes * Multi-Model Support Active by Default * Native Support for Charm Bundles * Multi Series Charms * Improved Local Charm Deployment * LXD Provider * Microsoft Azure Resource Manager Provider * Bootstrap Constraints, Series * Juju Logging Improvements * Unit Agent Improvements * API Login with Macaroons * MAAS 1.8 Compatibility ### Terminology In Juju 2.0, environments will now be referred to as "models". Commands which referenced "environments" will now reference "models". Example: juju get-environment will become juju get-model The "state-server" from Juju 1.x becomes a "controller" in 2.0. The change in terminology will be done across several alphas, so messages and errors provided by juju may still reference "environments". ### Testing Advice Juju 2.0's new features and behaviours will confuse older Juju clients. It is best to create a new juju home to ensure you can revert to a 1.x Juju client. You can move an existing .juju/ directory out of the way or create a new directory and export it for Juju to find like so: export JUJU_HOME=~/new-juju-testing If you accidentally use Juju 2.0 with a Juju 1.x home, and Juju 1.x reports problems with the environment, you can delete ~/.go-cookie and the environments/cache.yaml in the Juju home dir to unconfuse Juju 1.x. Juju 2.0 will store its data in a new location soon. It is not possible to test an upgrade from Juju 1.x to 2.0 at this time. Juju will support this in future releases. ### Command Name Changes After a while experimenting with nested command structures, the decision was made to go back to a flat command namespace as the nested commands always felt clumsy and awkward when being used even though they seemed like a good idea. So, we have the following changes: 1.25 command 2.0-alpha1 command juju environment destroy juju destroy-environment * juju environment get juju get-environment ** juju environment get-constraints juju get-constraints ** juju environment retry-provisioningjuju retry-provisioning juju environment set juju set-environment ** juju environment set-constraints juju set-constraints ** juju environment share juju share-environment juju environment unset juju unset-environment ** juju environment unshare juju unshare-environment juju environment users juju list-shares juju user add juju add-user juju user change-password juju change-user-password juju user credentials juju get-user-credentials juju user disable juju disable-user juju user enable juju enable-user juju user info juju show-user juju user list juju list-users * the behaviour of destroy-environment has changed, see the section on controllers below ** these commands existed at the top level before but become the recommended approach again. And for the extra commands previously under the "jes" feature flag but now available out of the box: juju system create-environment juju create-environment juju system destroyjuju destroy-controller juju system environments juju list-environments juju system kill juju kill-controller juju system list juju list-controllers juju system list-blocksjuju list-all-blocks juju system login juju login juju system remove-blocks juju remove-all-blocks juju system use-environmentjuju use-environment Fundamentally, listing things should start with 'list-', and looking at an individual thing should start with 'show-'. 'remove' is generally used for things that can be easily added back, whereas 'destroy' is used when it is not so easy to add back. ### Multi-Model Support Active by Default The multiple model support that was previously behind the "jes" developer feature flag is now enabled by default. Along with the enabling there A new concept has been introduced, that of a "controller". A Juju Controller, also sometimes called the "controller model", d
