juju-core 1.16.0 A new stable release of Juju, juju-core 1.16.0, is now available.
Getting Juju juju-core 1.16.0 is available in Saucy and backported to earlier series in the following PPA https://launchpad.net/~juju/+archive/stable New and Notable * bootstrap now matches on major and minor version numbers when locating tools * public-bucket-url is deprecated, use tools-url and/or image-metadata-url instead * users running from source no longer need to manually specify --upload-tools in order to have tools available for bootstrapping * tools retrieval is now handled using simplestreams metadata, similar to how image id lookup works * tools no longer have to be located in a publicly readable cloud storage instance; they can be served by any HTTP server eg apache * new constraint: tags. This constraint is currently only supported by MaaS environments, and allows you to specify nodes by tags applied to them in MaaS. Example: juju deploy mysql --constraints tags=foo,bar will deploy mysql to a node that is tagged with both the "foo" tag and the "bar" tag. * the "null" provider is now available, for creating environments with existing machines. * admin-secret is now chosen automatically if omitted from the configuration of a new environment. * control-bucket is now chosen automatically if omitted from the configuration for new ec2 and openstack environments. * Logging has changed. You can specify an environment variable "JUJU_LOGGING_CONFIG", or you can specify --log-config on the command line. To show the log on the command line, now use --show-log. The --debug has been kept to be short-hand for "--log-config=<root>=DEBUG --show-log", and --verbose has been deprecated with its current meaning. Resolved issues * "juju add-machine ssh:..." no longer fails when an IP address is specified instead of a hostname. LP #1225825 * Bootstrap nodes will now only run one copy of Mongodb, this will result in lower resource utilisation and faster startup of the bootstrap node. Closes LP #1210407 * EC2 accounts in default VPC mode now work with juju. LP #1221868 * The unset command is now available from the command line. LP #1237929 Configuration changes * tools-url is a new configuration option used to specify the location where the tools tarballs may be found. If specified, this overrides the default tools repository. * image-metadata-url is a new configuration option used to specify the location where image metadata may be found. This is only normally required for private Openstack deployments. * public-bucket-url is deprecated - use tools-url to specify where tools are located (if not handled automatically by your cloud provider). Testing on Canonistack and HP Cloud Starting with this release, there is no longer any requirement to use a public-bucket-url configuration attribute when bootstrapping Canonistack or HP Cloud environments. The public-bucket-url attribute is deprecated and you are advised to remove it from your environment configuration. Bootstrapping and tools When Juju bootstraps an environment, it searches for a tools tarball matching the version of the Juju client used to run the bootstrap. Prior to this release, any tools with the same major version number as the Juju client were considered a match. Starting with this release, both the major and minor version numbers must match. This is to prevent any subtle and hard to find bugs due to version mismatch from manifesting themselves. For users of Juju on EC2, HP Cloud, Azure, and Canonistack, where the tools are maintained by Canonical in the cloud itself, and MASS, with access to the web to download the tools, there will be no noticeable change. For private cloud setups, more care will be needed to ensure all the required tools tarballs are available. Configuring tools A focus of this release is to make bootstrapping a Juju environment work better out of the box, eliminating the need for manual configuration steps. To this end, the following improvements are delivered: 1. HP Cloud and Canonistack users no longer need any special configuration over and above what goes into any generic Openstack setup for Juju. 2. Users who compile and run Juju from source can bootstrap without manually having to tell Juju to upload a custom tools tarball. The upload-tools bootstrap option is still available to force a tools upgrade, but it is no longer required just to bootstrap the first time or when starting again after an environment has been destroyed. Users who wish to run Juju in HP Cloud from scratch can now just follow the same steps as used for EC2: 1. run juju init 2. source a credentials file containing username, password, region etc, or edit the newly created ~/.juju/environments.yaml file to add username, password, region etc to the hpcloud environment block 3. run juju bootstrap -e hpcloud HP Cloud users can run juju switch hpcloud to make the default environment hpcloud and remove the need to use the -e parameter with each Juju command. Private Openstack deployments Tools can now be served by any http server, or from a shared mounted directory accessible from the cloud, removing the requirement to place the tools in a cloud storage instance. Using a cloud storage instance is still possible of course, but this option may be more desirable for users who wish to set up a private cloud without outgoing web access. The steps are as follows: 1. Copy the tools tarballs for a given Juju version to a directory named like: <some path>/tools/releases 2. run juju sync-tools --all --source=<some path> --destination=<some path> 3. Configure your http server to serve to contents of <some path> under http://<your url> 4. Add tools-url: http://<your url> to your environments.yaml file. An alternative to using http is to copy the tools directory itself, from <some path>, to a shared drive which is accessible to client machines and cloud instances via a common mounted directory. In that case, add an entry like this to your environments.yaml: tools-url: file://mounted_dir Users who still wish to place the tools in a cloud instance should copy the tools directory itself to a publicly readable storage instance. Then add the tools-url entry to environments.yml: tools-url: https://<path to storage instance>/tools A final alternative for locating tools is to copy the entire tools directory created above to the cloud’s control bucket, as specified in the environments.yaml file. No tools-url configuration is required, but note that these tools will only be visible to that one particular Juju environment. Configuring image metadata Just as private Openstack deployments need to configure where tools are located, so too does the location of the image metadata need to be specified. This is not applicable for supported openstack clouds like HP Cloud and Canonistack, only private deployments. Prior to this release, the public-bucket-url was used to point to the location of the metadata. Now, configure the image-metadata-url as follows: image-metadata-url: <old-public-bucket-url>/juju-dist Note that the image metadata no longer has to be kept in a cloud storage instance. The above example simply assumes the metadata will be kept in the same location as prior to this release. But as with tools, the image metadata may be server from any http url or even a directory using file://<dir name>. The same caveats apply. Finally We encourage everyone to subscribe the mailing list at [email protected], or join us on #juju-dev on freenode. Curtis Hovey On behalf of the Juju team https://launchpad.net/juju-core -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
