Re: Juju devel 1.21-alpha1 is released
Thanks for all of this, all good and very helpful stuff :) On Wed, Sep 17, 2014 at 10:04 PM, Curtis Hovey-Canonical cur...@canonical.com wrote: 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: https://launchpad.net/~juju/+archive/devel 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: https://streams.canonical.com/juju/devel/tools 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=https://streams.canonical.com/juju/devel/tools 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,
Re: Juju devel 1.21-alpha1 is released
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. On Fri, Sep 19, 2014 at 5:32 AM, Samuel Cozannet samuel.cozan...@canonical.com wrote: Thanks for all of this, all good and very helpful stuff :) On Wed, Sep 17, 2014 at 10:04 PM, Curtis Hovey-Canonical cur...@canonical.com wrote: 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: https://launchpad.net/~juju/+archive/devel 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: https://streams.canonical.com/juju/devel/tools 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=https://streams.canonical.com/juju/devel/tools 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
Juju devel 1.21-alpha1 is released
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: https://launchpad.net/~juju/+archive/devel 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: https://streams.canonical.com/juju/devel/tools 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=https://streams.canonical.com/juju/devel/tools 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
