Juju devel 2.0-beta5 is released

[Curtis Hovey-Canonical]

# Juju 2.0-beta5

A new development release of Juju, juju 2.0-beta5, is now available.
This release replaces version 2.0-beta4.


## Getting Juju

Juju 2.0-beta5 is available for Xenial 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/2.0-beta5

Upgrading environments to 2.0-beta5 is not supported.


## The complete release notes available on the Web

The release notes for Juju 2.0 beta5 are very long. They are too large
to post to a list. The complete release notes are published at

https://jujucharms.com/docs/devel/temp-release-notes


## Getting started with Juju 2.0

Juju 2.0 allows you to get started creating models without modifying any
definition files.  Just provide your credentials and go!  (*Note: to
fully understand the new bootstrap experience please see the "New
Bootstrap and Cloud Management Experience" section below)

* LXD provider (requires lxd 2.0.0~rc9 or later):
  The LXD provider requires no credentials, so you can create a
  controller by just specifying its name:

juju bootstrap  lxd

Note that the lxdbr0 bridge needs to be properly configured for the lxd
provider to work, for details see:
http://insights.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-explained/

* Public Clouds:
  Known public clouds can be listed with juju list-clouds:

juju list-clouds

CLOUD  TYPEREGIONS
awsec2 us-east-1, us-west-1, us-west-2, ...
aws-china  ec2 cn-north-1
aws-govec2 us-gov-west-1
azure  azure   japanwest, centralindia, eastus2, ...
azure-chinaazure   chinaeast, chinanorth
cloudsigma cloudsigma  mia, sjc, wdc, zrh, hnl
google gce us-east1, us-central1, ...
joyent joyent  us-east-1, us-east-2, us-east-3, …
lxdlxd
maas   maas
manual manual
rackspace  rackspace   lon, syd, hkg, dfw, ord, iad

Add your credentials using either:

juju add-credential 
or
juju add-credential  -f creds.yaml
or
juju autoload-credentials

When specifying just the cloud, juju add-credential will allow a new
credential to be added interactively. You will be prompted type the
required credential attributes. Example:

juju add-credential maas
  credential name: hmaas
  replace existing credential? [y/N]: y
  auth-type: oauth1
  maas-oauth:
credentials added for cloud maas

The new credentials.yaml file at: ~/.local/share/juju/credentials.yaml

The autoload tool will search for existing credentials for AWS,
OpenStack/Rackspace, and Google clouds. You will then be prompted for
which ones you'd like to save.

If you have an existing credential.yaml file, you can also import a
named credential, eg for MAAS

cat credentials.yaml

  credentials:
 maas:
   my-credentials:
 auth-type: oauth1
 maas-oauth: 

or, for AWS

cat credentials.yaml

  credentials:
aws:
  default-credential: my-credentials
  my-credentials:
auth-type: access-key
access-key: 
secret-key: 

Bootstrap using your default credentials:

 juju bootstrap  [/region]

Examples:

 juju bootstrap aws-controller aws

 juju bootstrap mass-controller maas/192.168.0.1

In the MAAS example above, you specify the host address of the MAAS
controller. So to use Juju on MAAS out of the box, you set up a
credentials file (either interactively, or based on the example above)
and then bootstrap. This avoids the need for any cloud configuration.
But it's also possible to set up a named MAAS cloud definition as
explained later.

More details on the new bootstrap experience, including defining private
clouds can be found in the New Bootstrap and Cloud Management Experience
section.


## What's New in Beta5

* Support for local charm repositories removed.
  * All local charms must now be deployed using the path to the charm
instead of a local URL.
  * Bundles support specifying local charms using the path to the charm.

* Notable Bug Fixes:
  * GridFS namespace breaks charm and tools deduping across models
Lp 1569054
  * Unable to download local: charm due to hash mismatch in
multi-model deployment
Lp 1541482
  * Destroyed models still show up in list-models
Lp 1534627


## Notable Changes

This releases addresses stability and performance issues.

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

Re: juju2: format of clouds.yaml for juju add-cloud

[Andrew Wilkins]

On Thu, Apr 21, 2016 at 2:44 AM Andreas Hasenack 
wrote:

> Hi,
>
> I was trying to add another "cloud" so that I could have multiple MAAS
> servers available to bootstrap on, without having to type the MAAS IP
> everytime in the bootstrap command line, and pass --credential.
>
> Some reading lead me to juju add-cloud, but the documentation only has
> examples for openstack clouds, like:
>
> clouds:
>   :
> type: 
> regions:
>   :
> endpoint: 
> auth-types: <[access-key, oauth, userpass]>
>
>
> That does not translate immediately to a MAAS configuration. I asked for
> help on IRC and mgz provided me with this syntax:
>
> clouds:
>   some-name:
> type: maas
> auth-types: [oauth1]
> endpoint: 'http:///MAAS/'
>
>
> Are there other options that could be used here, specific to the "maas"
> type? What about other cloud types, what changes in this template?
>

Everything that you can use is used here:
http://streams.canonical.com/juju/public-clouds.syaml. So the things in
there of note are "storage-endpoint" and "regions".

The "storage-endpoint" field is for clouds that have separate storage API
endpoints. Most clouds only have the one API endpoint, or you can derive
the storage endpoint from the compute one.

The "region" field contains a mapping from region names (e.g. "us-east-1")
to region-specific endpoint and storage-endpoint values.

We intend to add support for interactively adding clouds, similar to what's
been done for credentials, but I don't know when that will happen.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

juju2: format of clouds.yaml for juju add-cloud

[Andreas Hasenack]

Hi,

I was trying to add another "cloud" so that I could have multiple MAAS
servers available to bootstrap on, without having to type the MAAS IP
everytime in the bootstrap command line, and pass --credential.

Some reading lead me to juju add-cloud, but the documentation only has
examples for openstack clouds, like:

clouds:
  :
type: 
regions:
  :
endpoint: 
auth-types: <[access-key, oauth, userpass]>


That does not translate immediately to a MAAS configuration. I asked for
help on IRC and mgz provided me with this syntax:

clouds:
  some-name:
type: maas
auth-types: [oauth1]
endpoint: 'http:///MAAS/'


Are there other options that could be used here, specific to the "maas"
type? What about other cloud types, what changes in this template?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ibm-was-base, ibm-http-server

[Matt Bruzek]

Kevin and I spent some time reviewing the design documents for the IBM
layers ibm-was-base and ibm-http-server today.

https://docs.google.com/document/d/1O7J_SLDdCD-D7J8xG7k_9hAGTo8j7BcfCXbA3iTtkR8/edit

https://docs.google.com/document/d/1PQjZofa9aK4s9m2yKcvMkqsLT_esgZ2iJVf-DnVdNEU/edit

These are great examples of a layer design. They are well written and use
the reactive framework correctly. We look forward to seeing the charms
built from these layers soon.

   - Matt Bruzek 
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju Packaging in Xenial

[Nicholas Skaggs]

As many have noticed, there were some major packaging changes to Juju 
that impact those using Juju on Xenial[1]. I encourage everyone to read 
the full details, but in summary juju-2.0 is now the default Juju in 
Xenial. However, both juju-1.25 and juju-2.0 are available, and can be 
co-installed at the same time. They can be invoked by calling 
/usr/bin/juju-2.0 or /usr/bin/juju-1 (or /usr/bin/juju-1.25 ) 
respectively. To raise awareness, Juju will also display a message on 
first invocation after upgrade to inform the user of this change.



This change in the default version of /usr/bin/juju may cause cause 
issues with any tool or workflow that makes the assumption that 
/usr/bin/juju is juju-1. For instance, this affects deployer and 
amulet[2]. Migrating tools to support juju-2.0 is preferred, but to help 
with the transition, there is an easy way to restore juju-1 as the 
default Juju.  A new package called juju-1-default[3] is available in 
Xenial. If you wish to ensure /usr/bin/juju is juju-1, as it is in 
Trusty, simply install this package. It will keep /usr/bin/juju as 
juju-1 until you remove it. Note, this package is intended to help 
transition, rather than be seen as a permanent fix. Those that need 
juju-1 should migrate to using /usr/bin/juju-1 (/usr/bin/juju-1.25).



This change should help ease the transition to Xenial and Juju 2.0 
without breaking existing workflows. However, I still urge you to update 
tools to support juju-2.0. Being explicit andremoving assumptions about 
which version of juju is /usr/bin/juju should help avoid similar issues 
moving forward.



Thanks!

Nicholas


1. https://lists.ubuntu.com/archives/juju-dev/2016-April/005313.html
2. https://bugs.launchpad.net/juju-deployer/+bug/1571719
3. http://packages.ubuntu.com/xenial/juju-1-default


--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Legacy store problems

[Uros Jovanovic]

Hi all,

We're experiencing problems with the legacy charm store which is blocking
the ingestion process, so at the moment no new charms are getting into any
of the stores (legacy or jujucharms.com).

We're working with IS on resolution, however, if you need any charms to be
available immediately, I suggest that you publish them manually with new
charm 2.0 tools as explained in Marco's email or here
https://jujucharms.com/docs/devel/authors-charm-store [1].

Sorry for the inconvenience, we'll make another announcement when the issue
is resolved.

Uros

[1] Please not that in order to use new charm 2.0 tools, you'll also have
to login to jujucharms.com before you'll be able to "charm push" your
charm.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju