<div dir="ltr">Is there a way to see what commits made it in to this release? I'm curious to know if a few patches (that weren't tied to bugs until recently) made it in.</div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Sep 19, 2014 at 5:32 AM, Samuel Cozannet <<a href="mailto:samuel.cozannet@canonical.com" target="_blank">samuel.cozannet@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for all of this, all good and very helpful stuff :)</div><div class="gmail_extra"><div><div class="h5"> <div class="gmail_quote">On Wed, Sep 17, 2014 at 10:04 PM, Curtis Hovey-Canonical <<a href="mailto:curtis@canonical.com" target="_blank">curtis@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">juju-core 1.21-alpha1 A new development release of Juju, juju-core 1.21-alpha1, is now available. Getting Juju juju-core 1.21-alpha1 is available for utopic and backported to earlier series in the following PPA: <a href="https://launchpad.net/~juju/+archive/devel" target="_blank">https://launchpad.net/~juju/+archive/devel</a> The devel packages in this archive use the devel simple-streams. You must configure the 'tools-metadata-url' option in your environments.yaml to use the matching juju tools. tools-metadata-url: <a href="https://streams.canonical.com/juju/devel/tools" target="_blank">https://streams.canonical.com/juju/devel/tools</a> This ensures a clean separation between the stable tools and the devel tools. Production environments based on stable juju cannot accidentally upgrade to a devel release even when the --version option is passed to the 'upgrade-juju' command. The 'tools-metadata-url' option must be set to clearly state the environment is for evaluating development versions. Upgrading from stable releases to development releases is not supported. You can upgrade test environments to development releases to test new features and fixes, but it is not advised to upgrade production environments to 1.21-alpha1. You can switch your testing environment to use the devel streams like so: juju set-env tools-metadata-url=<a href="https://streams.canonical.com/juju/devel/tools" target="_blank">https://streams.canonical.com/juju/devel/tools</a> This change may take hours to propagate. You can upgrade when the devel url is shown to be in the env. juju get-env tools-metadata-url Notable Changes * Harvest Modes * Disabling apt-get update/upgrade for faster provisioning * Using daily image streams for faster provisioning * Add many machines * Setting the MAAS network rules * Performing autopsies on failed bootstraps Harvest Modes Juju keeps a model of what it thinks the environment looks like, and based on that model, can harvest machines which it deems are no longer required. This can help keep your costs low, and keep you out of web consoles. Juju supports several harvesting modes to suit your needs. that Juju knows about. Unknown instances will not be harvested. This is the default mode. Destroyed: Juju will harvest only machine instances that are dead, and Unknown: Juju will harvest only instances that Juju doesn't know about. All: Juju will terminate all instances – destroyed or unknown – that it finds. This is a good option if you are only utilizing Juju for your environment. None: Juju won't harvest any machines. This is the most conservative mode, and a good choice if you manage your machines utilizing a separate process outside of Juju. Juju's harvesting behaviour is set through the environments.yaml file. provisioner-harvest-mode: <MODE> 'provisioner-harvest-mode' replaces 'safe-mode'. Environments with 'safe-mode' set will be converted to 'provisioner-harvest-mode' when upgraded. Disabling apt-get update/upgrade for faster provisioning When juju provisions a machine, its default behaviour is to update the list of available packages and upgrade the existing packages to the latest version. If your OS images are fresh or the services you deploy don't require updated packages, you can disable updates and upgrades to provision the machine faster. Two configuration options are available to disable apt updates and upgrades. When your OS images are fresh, you can set both 'enable-os-refresh-update', and 'enable-os-upgrade' to false. When you know that some charms want the latest packages to to setup services, you will want to keep 'enable-os-refresh-update' set to "true" You can configure the options in environments.yaml for fast provision like so enable-os-upgrade: false enable-os-refresh-update: false Using daily image streams for faster provisioning Juju prefers to use the well slow changing "released" images when provisioning machines. The 'image-stream' option in environments.yaml can be set to "daily" use more up-to-date images, thus shortening the time it takes to perform apt-get update/upgrade. While this feature has existed since 1.18.0, it was not applied consistently KVM containers. KVM containers will now use "daily" when environments.yaml is set to: image-stream: daily Add many machines Juju's 'add-machine' command now accepts the '-n' option to add many machines. For example, to add two machines: juju add-machine -n 2 The '-n' option can be combined with placement. You can add to lxc containers to machine 1 thusly juju add-machine lxc:1 -n 2 Setting the MAAS network rules The default network bridge is eth0. MAAS environments can specify a different interface using the network-bridge options. For bridge can be set to eth2 in environments.yaml like so: network-bridge: eth2 Juju and MAAS cannot both be in control of the network. When MAAS is managing the bridge and bringing networks up and down, set the 'disable-network-management' option in environments.yaml to "true": disable-network-management: true This tells Juju not to create a network bridge or bringing eth0 up and down during cloudinit. Juju will not make changes to the network config when its agents start. Performing autopsies on failed bootstraps The juju 'bootstrap' command has a new option for testers and anyone examining why a bootstrap failed. Use the '--keep-broken' option to keep the machine up. You can then use ssh to gather logs and investigate the cause of the failure. Resolved issues * Maas provider assumes machine uses dhcp for eth0 Lp 1361374 * Relation-get with invalid relation name panics agent Lp 1365412 * We should remove direct db access for clients Lp 1253652 * Allow specifying a key when doing manual provisioning Lp 1270466 * Juju doesn't use maas' knowledge of system architecture when picking tools Lp 1303853 * Juju add-machine still assumes precise (maas) Lp 1315473 * Local provider is very slow to tranistion from agent-status: pending Lp 1322302 * Juju should wrap apt-get invocations with eatmydata when provisioning cloud instances Lp 1335822 * Juju 1.21-alpha1 local provider does not create all-machines.log Lp 1339715 * Cloudinit does not use ssh client Lp 1339976 * Provisioner-safe-mode is undocumented Lp 1342729 * Networker restarts every 3 seconds with the local provider (missing /etc/network/interfaces) Lp 1343219 * Describe harvesting strategy rather than using "safe mode" name Lp 1345553 * Configstore: if the size of the serialised jenv decreases the .jenv file will be corrupt Lp 1348458 * Juju-core client panics with juju set empty string Lp 1348829 * Juju ignores environments.yaml on failed bootstrap if $provider.jenv exists Lp 1361680 * Saved addresses should omit link-local addresses Lp 1362453 * Add-machine containers should default to latest lts Lp 1363971 * Blobstore's hashing needs improvement Lp 1364750 * --keep-broken option still allows instance to be stopped Lp 1365772 * Removing a unit on an unclean machine should remove that machine Lp 1206532 * Juju log files should not be world readable Lp 1286518 * Juju uses hard-coded regions Lp 1319474 * Cmd/juju: deploy --to a non existent machine fails too late in the process Lp 1212538 * Cmd/juju: add-machine should take a -n param Lp 1214209 * Missing @ syntax for reading config setting from file content Lp 1216967 * Container provisioner may choose bad tools Lp 1347984 * Juju set help is written but not shown Lp 1359187 Finally We encourage everyone to subscribe the mailing list at <a href="mailto:juju-dev@lists.canonical.com" target="_blank">juju-dev@lists.canonical.com</a>, or join us on #juju-dev on freenode. -- Curtis Hovey Canonical Cloud Development and Operations <a href="http://launchpad.net/~sinzui" target="_blank">http://launchpad.net/~sinzui</a> -- Juju mailing list <a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a> </blockquote></div> <div> </div></div></div>-- <div dir="ltr">Samuel Cozannet<div>Cloud, Big Data and IoT Strategy Team <div>Strategic Program Manager</div><div>Changing the Future of Cloud Ubuntu <<a href="http://ubuntu.com/" style="color:rgb(17,85,204)" target="_blank">http://ubuntu.com</a>> / Canonical <<a href="http://canonical.com/" style="color:rgb(17,85,204)" target="_blank">http://canonical.com</a>> UK LTD </div><div><a href="mailto:samuel.cozannet@canonical.com" target="_blank">samuel.cozannet@canonical.com</a></div><div>+33 616 702 389</div><div> </div></div></div> </div> -- canonical-juju mailing list <a href="mailto:canonical-juju@lists.canonical.com">canonical-juju@lists.canonical.com</a> Modify settings or unsubscribe at: <a href="https://lists.canonical.com/mailman/listinfo/canonical-juju" target="_blank">https://lists.canonical.com/mailman/listinfo/canonical-juju</a> </blockquote></div> </div>