Re: Juju 1.26-alpha3 moving to 2.0-alpha1

[Cheryl Jennings]

Hi Everyone,

While we are still moving towards a 2.0 release, not all of the CLI /
behavior changes that will occur in Juju 2.0 are ready for an alpha
release.  To allow consumers to test new functionality in a timely manner,
we will be releasing a new development version called 1.26-alpha3.  This
release will contain:
- The new Rackspace Provider
- Support for CentOS and Windows images in streams
- Improved local charm deployment
- Support for Multi Series Charms

The next development release will be in mid-January and will be named
2.0-alpha1.  It will contain additional new features, and CLI / behavior
changes such as:
- Moving to a flat namespace for commands (for example, juju user add will
be juju add-user)
- Multi-environment (soon to be Multi-Model) support active by default

The 2.0-alpha1 release will be accompanied by a listing of CLI and behavior
changes, so that users may adjust any scripts / automation around Juju.

Thanks!
-Cheryl

On Fri, Dec 4, 2015 at 1:06 PM, Alexis Bruemmer <
alexis.bruem...@canonical.com> wrote:

> Hi All,
>
> Juju 2.0 has been a long time coming and we will see it release in April
> 2016 with Ubuntu 16.04!  Among many other improvements, the 2.0 release
> will have a better bootstrap experience that leverages all the great work
> done around multi-model solutions.  Juju 2.0 bootstrapping will
> automatically create a controller (previously known as a Juju State Server)
> with a hosted model (previously known as an environment); the new behavior
> automatically provides the user with a usable model and a clear path for
> adding more models to the bootstrapped controller.  This improvement
> however, changes the expected functionality of the current 1.X bootstrap
> command.  Our commitment to Juju users on LTS releases states clearly that
> we do not break backwards compatibility on point releases (including
> changing base expected behavior).  For this reason we will be dropping
> the 1.26.0 release and turning the current 1.26-alpha3 into 2.0-alpha1.
>
>
> This is an update to our current release plans (
> https://github.com/juju/juju/wiki/Juju-Release-Schedule) which has a
> 1.26.0 release scheduled for January.  Although this means waiting a little
> longer for features, moving to a 2.0 enables the development team to
> deliver a strong and correct 2.0 user experience.  The Juju team will
> continue to release alphas and betas on a regular cadence so that new
> features will be available in the devel ppa (ppa:juju/devel).  The first
> 2.0-alpha1 is scheduled to release the week of December 7th.
>
> If you have any questions please do not hesitate to ask.
>
> Thanks!
> Alexis
>
> --
> Alexis Bruemmer
> Juju Core Manager, Canonical Ltd.
> (503) 686-5018
> alexis.bruem...@canonical.com
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Juju devel 1.26-alpha3 is realeased

[Curtis Hovey-Canonical]

# juju-core 1.26-alpha3

A new development release of Juju, juju-core 1.26-alpha3, is now available.
This release replaces version 1.26-alpha2.


## Getting Juju

juju-core 1.26-alpha3 is available for Wily 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/1.26-alpha3

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 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.26-alpha3.


## Notable Changes

  * New Support for Rackspace
  * Multi Series Charms
  * Improved local charm deployment
  * Centos and Windows Image Streams
  * Azure provider changes


### New Support for Rackspace

A new provider has been added that supports hosting a Juju environment
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: 
region: 
auth-mode: 
username: 
password: 
# access-key: 
# secret-key: 

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.


### 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 
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.


### Centos and Windows Image Streams

A new simplestreams search path is supported when looking up the id of
images to run. As well as searching published Ubuntu images