Juju devel 1.21-alpha1 is released

Marco Ceppi marco.ceppi at canonical.com
Fri Sep 19 17:31:34 UTC 2014


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.cozannet at 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 <
> curtis at 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, 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
>> juju-dev at lists.canonical.com, or join us on #juju-dev on freenode.
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
>
> --
> Samuel Cozannet
> Cloud, Big Data and IoT Strategy Team
> Strategic Program Manager
> Changing the Future of Cloud
> Ubuntu <http://ubuntu.com> / Canonical <http://canonical.com> UK LTD
> samuel.cozannet at canonical.com
> +33 616 702 389
>
>
> --
> canonical-juju mailing list
> canonical-juju at lists.canonical.com
> Modify settings or unsubscribe at:
> https://lists.canonical.com/mailman/listinfo/canonical-juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140919/32b15b0c/attachment.html>


More information about the Juju mailing list