Wow! A lot to play with tomorrow. Thanks for the release core team! On Thu, Jan 21, 2016, 5:06 PM Curtis Hovey-Canonical <[email protected]> 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-provisioning juju 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 destroy juju destroy-controller > juju system environments juju list-environments > juju system kill juju kill-controller > juju system list juju list-controllers > juju system list-blocks juju list-all-blocks > juju system login juju login > juju system remove-blocks juju remove-all-blocks > juju system use-environment juju 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", > describes the model that runs and manages the Juju API servers and the > underlying database. > > The controller model is what is created when the bootstrap command is > used. This controller model is a normal Juju model that just happens to > have machines that manage Juju. A single Juju controller can manage many > Juju models, meaning less resources are needed for Juju's management > infrastructure and new models can be created almost instantly. > > In order to keep a clean separation of concerns, it is now considered > best practice to create additional models for deploying workloads, > leaving the controller model for Juju's own infrastructure. Services can > still be deployed to the controller model, but it is generally expected > that these be only for management and monitoring purposes (e.g Landscape > and Nagios). > > When creating a Juju controller that is going to be used by more than > one person, it is good practice to create users for each individual that > will be accessing the models. > > The main new commands of note are: > juju list-models > juju create-model > juju share-model > juju list-shares > juju use-model > > Also see: > juju help controllers > juju help users > > Also, since controllers are now special in that they can host multiple > other models, destroying controllers now needs to be done with more > care. > > juju destroy-model > > does not work on controllers, but now only on hosted models (those > models that the controller looks after). > > juju destroy-controller > > is the way to do an orderly takedown. > > juju kill-controller > > will work in those situations where the API server may be broken. > However forcibly taking down a controller could leave other models > running with no way to talk to an API server. > > > ### Native Support for Charm Bundles > > The Juju 'deploy' command can now deploy a bundle. The Juju Quickstart > or Deployer plugins are not needed to deploy a bundle of charms. You can > deploy the mediawiki-single bundle like so: > > juju deploy cs:bundle/mediawiki-single > > Local bundles can be deployed by passing the path to the bundle. For > example: > > juju deploy ./openstack/bundle.yaml > > Local bundles can also be deployed from a local repository. Bundles > reside in the "bundle" subdirectory. For example, your local juju > repository might look like this: > > juju-repo/ > | > - trusty/ > - bundle/ > | > - openstack/ > | > - bundle.yaml > > and you can deploy the bundle like so: > > export JUJU_REPOSITORY="$HOME/juju-repo" > juju deploy local:bundle/openstack > > Bundles, when deployed from the command line like this, now support > storage constraints. To specify how to allocate storage for a service, > you can add a 'storage' key underneath a service, and under 'storage' > add a key for each store you want to allocate, along with the > constraints. e.g. say you're deploying ceph-osd, and you want each unit > to have a 50GiB disk: > > ceph-osd: > ... > storage: > osd-devices: 50G > > Because a bundle should work across cloud providers, the constraints in > the bundle should not specify a pool/storage provider, and just use the > default for the cloud. To customize how storage is allocated, you can use > the '--storage' option with a new bundle-specific format: --storage > service:store=constraints. e.g. say you you're deploying OpenStack, and > you want each unit of ceph-osd to have 3x50GiB disks: > > juju deploy ./openstack/bundle.yaml --storage > ceph-osd:osd-devices=3,50G > > > ### Multi Series Charms > > Charms now have the capability to declare that they support more than > one series. Previously a separate copy of the charm was required for > each series. An important constraint here is that for a given charm, > all of the listed series must be for the same distro/OS; it is not > allowed to offer a single charm for Ubuntu and CentOS for example. > Supported series are added to charm metadata as follows: > > name: mycharm > summary: "Great software" > description: It works > maintainer: Some One <[email protected]> > categories: > - databases > series: > - precise > - trusty > - wily > provides: > db: > interface: pgsql > requires: > syslog: > interface: syslog > > The default series is the first in the list: > > juju deploy mycharm > > will deploy a mycharm service running on precise. > > A different, non-default series may be specified: > > juju deploy mycharm --series trusty > > It is possible to force the charm to deploy using an unsupported series > (so long as the underlying OS is compatible): > > juju deploy mycharm --series xenial --force > > or > > juju add-machine --series xenial > Machine 1 added. > juju deploy mycharm --to 1 --force > > '--force' is required in the above deploy command because the target > machine is running xenial which is not supported by the charm. > > The 'force' option may also be required when upgrading charms. Consider > the case where a service is initially deployed with a charm supporting > precise and trusty. A new version of the charm is published which only > supports trusty and xenial. For services deployed on precise, upgrading > to the newer charm revision is allowed, but only using force (note the > use of '--force-series' since upgrade-charm also supports '--force- > units'): > > juju upgrade-charm mycharm --force-series > > > ### Improved Local Charm Deployment > > Local charms can be deployed directly from their source directory > without having to set up a pre-determined local repository file > structure. This feature makes it more convenient to hack on a charm and > just deploy it, and it also necessary to develop local charms > supporting multi series. > > Assuming a local charm exists in directory /home/user/charms/mycharm: > > juju deploy ~/charms/mycharm > > will deploy the charm using the default series. > > juju deploy ~/charms/mycharm --series trusty > > will deploy the charm using trusty. > > Note that it is no longer necessary to define a JUJU_REPOSITORY nor > locate the charms in a directory named after a series. Any directory > structure can be used, including simply pulling the charm source from a > VCS, hacking on the code, and deploying directly from the local repo. > > > ### LXD Provider > > The new LXD provider is the best way to use Juju locally. > > The controller is no longer your host machine; it is now a LXC > container. This keeps your host machine clean and allows you to utilize > your local model more like a traditional Juju model. Because > of this, you can test things like Juju high-availability without needing > to utilize a cloud provider. > > The previous local provider remains functional for backwards > compatibility. > > #### Requirements > > - Running Wily (LXD is installed by default) > > - Import the LXD cloud-images that you intend to deploy and register > an alias: > > lxd-images import ubuntu trusty --alias ubuntu-trusty > lxd-images import ubuntu wily --alias ubuntu-wily > lxd-images import ubuntu xenial --alias ubuntu-xenial > > or register an alias for your existing cloud-images > > lxc image alias create ubuntu-trusty <fingerprint> > lxc image alias create ubuntu-wily <fingerprint> > lxc image alias create ubuntu-xenial <fingerprint> > > - For 2.0-alpha1, you must specify the "--upload-tools" flag when > bootstrapping the controller that will use trusty cloud-images. > This is because most of Juju's charms are for Trusty, and the > agent-tools for Trusty don't yet have LXD support compiled in. > > juju bootstrap --upload-tools > > "--upload-tools" is not required for deploying a wily or xenial > controller and services. > > Logs are located at '/var/log/lxd/juju-{uuid}-machine-#/ ? > > > #### Specifying a LXD Controller > > In your ~/.juju/environments.yaml, you'll now find a block for LXD > providers: > > lxd: > type: lxd > # namespace identifies the namespace to associate with containers > # created by the provider. It is prepended to the container names. > # By default the controller's name is used as the namespace. > # > # namespace: lxd > # remote-url is the URL to the LXD API server to use for managing > # containers, if any. If not specified then the locally running LXD > # server is used. > # > # Note: Juju does not set up remotes for you. Run the following > # commands on an LXD remote's host to install LXD: > # > # add-apt-repository ppa:ubuntu-lxc/lxd-stable > # apt-get update > # apt-get install lxd > # > # Before using a locally running LXD (the default for this > provider) > # after installing it, either through Juju or the LXD CLI ("lxc"), > # you must either log out and back in or run this command: > # > # newgrp lxd > # > # You will also need to prepare the cloud images that Juju uses: > # > # lxc remote add images images.linuxcontainers.org > # lxd-images import ubuntu trusty --alias ubuntu-trusty > # lxd-images import ubuntu wily --alias ubuntu-wily > # lxd-images import ubuntu xenial --alias ubuntu-xenial > # > # See: https://linuxcontainers.org/lxd/getting-started-cli/ > # > # remote-url: > # The cert and key the client should use to connect to the remote > # may also be provided. If not then they are auto-generated. > # > # client-cert: > # client-key: > > > ### Microsoft Azure Resource Manager Provider > > Juju now supports Microsoft Azure's new Resource Manager API. The Azure > provider has effectively been rewritten, but old models are still > supported. To use the new provider support, you must bootstrap a new > model with new configuration. There is no automated method for > migrating. > > The new provider supports everything the old provider did, but now also > supports several additional features, as well as support for unit > placement (i.e. you can specify existing machines to which units are > deployed). As before, units of a service will be allocated to machines > in a service-specific Availability Set if no machine is specified. > > In the initial release of this provider, each machine will be allocated > a public IP address. In a future release, we will only allocate public > IP addresses to machines that have exposed services, to enable > allocating more machines than there are public IP addresses. > > Each model is represented as a "resource group" in Azure, with the VMs, > subnets, disks, etc. being contained within that resource group. This > enables guarantees about ensuring resources are not leaked when > destroying a model, which means we are now able to support persistent > volumes in the Azure storage provider. > > Finally, as well as Ubuntu support, the new Azure provider supports > Microsoft Windows Server 2012 (series "win2012"), Windows Server 2012 R2 > (series "win2012r2"), and CentOS 7 (series "centos7") natively. > > To use the new Azure support, you need the following configuration in > environments.yaml: > > type: azure > application-id: <Azure-AD-application-ID> > application-password: <Azure-AD-application-password> > subscription-id: <Azure-account-subscription-ID> > tenant-id: <Azure-AD-tenant-ID> > location: westus # or any other Azure location > > To obtain these values, it is recommended that you use the Azure CLI: > https://azure.microsoft.com/en-us/documentation/articles/xplat-cli/. > > You will need to create an "application" in Azure Active Directory for > Juju to use, per the following documentation: > > https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal/#authenticate-service-principal-with-password---azure-cli > (NOTE: you should assign the role "Owner", not "Reader", to the > application.) > > Take a note of the "Application Id" output when issuing "azure ad app > create". This is the value that you must use in the 'application-id' > configuration for Juju. The password you specify is the value to use in > 'application-password'. > > To obtain your subscription ID, you can use "azure account list" to list > your account subscriptions and their IDs. To obtain your tenant ID, you > should use "azure account show", passing in the ID of the account > subscription you will use. > > You may need to register some resources using the azure CLI when > updating an existing Azure account: > > azure provider register Microsoft.Compute > azure provider register Microsoft.Network > azure provider register Microsoft.Storage > > > ### New Support for Rackspace > > A new provider has been added that supports hosting a Juju model in > Rackspace Public Cloud As Rackspace Cloud is based on OpenStack, > Rackspace provider internally uses OpenStack provider, and most of the > features and configuration options for those two providers are > identical. > > The basic config options in your environments.yaml will look like this: > > rackspace: > type: rackspace > tenant-name: "<your tenant name>" > region: <IAD, DFW, ORD, LON, HKG, or SYD> > auth-url: https://identity.api.rackspacecloud.com/v2.0 > auth-mode: <userpass or keypair> > username: <your username> > password: <secret> > # access-key: <secret> > # secret-key: <secret> > > The values in angle brackets need to be replaced with your rackspace > information. > > 'tenant-name' must contain the rackspace Account Number. 'region' must > contain rackspace region (IAD, DFW, ORD, LON, HKG, SYD). 'auth-mode' > parameter can contain either 'userpass' or 'keypair'. This parameter > distinguish the authentication mode that provider will use. If you use > 'userpass' mode you must also provide 'username' and 'password' > parameters. If you use 'keypair' mode 'access-key' and 'secret-key' > parameters must be provided. > > > ### Bootstrap Constraints, Series > > While bootstrapping, you can now specify constraints for the bootstrap > machine independently of the service constraints: > > juju bootstrap --constraints <service-constraints> > --bootstrap-constraints <bootstrap-machine-constraints> > > You can also specify the series of the bootstrap machine: > > juju bootstrap --bootstrap-series trusty > > > ### Juju Logging Improvements > > Logs from Juju's machine and unit agents are now streamed to the Juju > controllers over the Juju API in preference to using rsyslogd. This is > more robust and is a requirement now that multi-model support is enabled > by default. Additionally, the centralised logs are now stored in Juju's > database instead of the all-machines.log file. This improves log query > flexibility and performance as well as opening up the possibility of > structured log output in future Juju releases. > > Logging to rsyslogd is currently still in place with logs being sent > both to rsyslogd and Juju's DB. Logging to rsyslogd will be removed > before the final Juju 2.0 release. > > The 'juju debug-log' command will continue to function as before and > should be used as the default way of accessing Juju's logs. > > This change does not affect the per machine (machine-N.log) and per unit > (unit-*-N.log) log files that exist on each Juju managed host. These > continue to function as they did before. > > A new 'juju-dumplogs' tool is also now available. This can be run on > Juju controllers to extract the logs from Juju's database even when the > Juju server isn't available. It is intended to be used as a last resort > in emergency situations. 'juju-dumplogs' will be available on the system > $PATH and requires no command line options in typical usage. > > > ### API Login with Macaroons > > Juju 2.0 supports an alternate API long method based on macaroons. This > will support the new charm publishing workflow coming future releases > > > ### Unit Agent Improvements > > We've made improvements to worker lifecycle management in the unit agent > in this release. The resource dependencies (API connections, locks, > etc.) shared among concurrent workers that comprise the agent are now > well-defined, modeled and coordinated by an engine, in a design inspired > by Erlang supervisor trees. > > This improves the long-term testability of the unit agent, and should > improve the agent's resilience to failure. This work also allows hook > contexts to execute concurrently, which supports features in development > targeting 2.0. > > > ### MAAS 1.8 Compatibility > > Juju 2.0-alpha1 includes the fix for bug #1483879: MAAS provider: > terminate-machine --force or destroy-environment don't DHCP release > container IPs. The fix uses the "devices" feature of MAAS, which has a > known bug on MAAS 1.8 (bug #1527068: MAAS retains child devices' IP > addresses when a parent node is released). There is a work around to > clean up the leaked IPs available in bug #1527068: > https://bugs.launchpad.net/juju-core/+bug/1527068/comments/10 > > Users on MAAS 1.8 should also set the default gateway for the interface > used by juju to avoid problems with container networking. You can > verify whether a default gateway has been set on an interface by looking > at the network details in the "Networks" tab. > > > ## Known issues > > * Some providers release wrong resources when destroying hosted models > Lp 1536792 > > * Destroying a hosted model in the local provider leaves the controller > unusable > Lp 1534636 > > * Unable to create hosted environments with MAAS provider > Lp 1535165 > > > ## Resolved issues > > * Unit loses network connectivity during bootstrap: juju 1.25.2 + > maas 1.9 > Lp 1534795 > > * Juju debug-log and eof > Lp 1390585 > > * I/o timeout errors can cause non-atomic service deploys > Lp 1486553 > > * Azure provider does not appear to be opening ports > Lp 1527681 > > * 1.25.2 doesn't set up dns information with maas > Lp 1528217 > > * Lxd: cannot create multiple environments > Lp 1531064 > > * Wrong command displayed when trying to destroy a controller with > destroy-environment > Lp 1534353 > > > Finally > > We encourage everyone to subscribe the mailing list at > [email protected], or join us on #juju-dev on freenode. > > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
