Great news, kudos all! Please note that although the example states "juju upgrade-gui 2.1.1" we've replaced 2.1.1 version with 2.1.2, which is also the default one that get's installed.
Have fun. On Fri, Apr 15, 2016 at 6:38 AM, Curtis Hovey-Canonical < cur...@canonical.com> wrote: > # juju 2.0-beta4 > > A new development release of Juju, juju 2.0-beta4, is now available. > This release replaces version 2.0-beta3. > > > ## Getting Juju > > Juju 2.0-beta4 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-beta4 > > Upgrading to this development releases is not supported. > > > ## The complete release notes available on the Web > > The release notes for Juju 2.0-beta4 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 <controller name> 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 TYPE REGIONS > aws ec2 us-east-1, us-west-1, us-west-2, ... > aws-china ec2 cn-north-1 > aws-gov ec2 us-gov-west-1 > azure azure japanwest, centralindia, eastus2, > ... > azure-china azure 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, … > lxd lxd > maas maas > manual manual > rackspace rackspace LON, SYD, HKG, DFW, ORD, IAD > > Add your credentials using either: > > juju add-credential <cloud> > or > juju add-credential <cloud> -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: <mass-oauth-key> > > or, for AWS > > cat credentials.yaml > > credentials: > aws: > default-credential: my-credentials > my-credentials: > auth-type: access-key > access-key: <key> > secret-key: <secret> > > Bootstrap using your default credentials: > > juju bootstrap <controller name> <cloud>[/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 Beta4 > > * Mongo 3.2 is now used when bootstrapping on Xenial hosts > * address-allocation feature flag no longer supported in MAAS provider > * prefer-ipv6 setting is now ignored in all providers > * MAAS 1.9+ provisioned LXD containers now have a bridge per NIC > * Accurate address selection based on spaces (in MAAS) > * extra-bindings support for charms metadata > * network-get hook tool arguments changed > * Juju GUI in the Controller > * Juju Now Respects CharmStore Channels > > > ### Mongo 3.2 Support > > Juju will now use Mongo 3.2 for its database, with the new Wired Tiger > storage engine enabled. This is initially only when bootstrapping on > Xenial. Trusty and Wily will be supported soon. > > > ### address-allocation feature flag no longer supported in MAAS provider > > In earlier releases, it was possible to get Juju to use static IP > addresses for containers from the same subnet as their host machine, > using the following development feature flag: > > JUJU_DEV_FEATURE_FLAGS=address-allocation juju bootstrap ... > > This flag is no longer supported and will not be accepted. > > > ### Accurate Address Selection Based on Network Spaces (in MAAS) > > MAAS 1.9+ offers native support for Network Spaces, which Juju will > discover and import. This means Juju knows which space any machine > address comes from and can select addresses based on their space. An > example for this improved support is the used by the 'network-get' hook > tool. Earlier versions of Juju (and even this one on providers other > than MAAS) use a simpler address selection based on scope and > lexicographic order. > > > ### network-get Hook Tool Arguments Changed > > The new 'network-get' hook tool introduced in 2.0-alpha3 slightly > changed: > > Before: network-get -r <relation-id> --primary-address > Now: network-get <binding-name> --primary-address > > Instead of taking an (implicit) -r argument with relation ID, the first > expected argument is now a binding name. This can be a name listed > inside the "extra-bindings" section of the charm metadata.yaml, or a > name of a relation (from the "provides", "requires", or "peers" > sections). The output is the same otherwise - a single address returned. > > > ### extra-bindings Support for Charms Metadata > > Many charms use a simple model where a relationship with another charm > also indicates there is a network connection between units of those > services. We have utilized this fact to add a network model that allows > system operators to control where those TCP connections are made by > binding the service relation endpoints onto a network space. > > However, some charms specifically use relation endpoints as simply a way > to pass configuration around, and the relations don't map directly to > services that are running in that charm and/or networking configuration. > These charms want to be able to express that they have more networking > configuration that an operator wants to control without having yet- > another interface that will never be related to another service. > > Juju solves the aforementioned issues by introducing an optional new > section in the charm metadata,yaml. The new section is called "extra- > bindings". Similarly to the peers/provides/requires sections, extra- > bindings contains a list of names, which can be used with 'juju deploy > --bind' like relation names. Unlike relations, you don't have to define > hooks or anything more complex to allow the users of the charm to bind > those names to Juju spaces. > > Example: ceph charm's metadata.yaml would look like: > > name: ceph > summary: Highly scalable distributed storage > maintainer: OpenStack Charmers <openstack-charm...@lists.ubuntu.com> > description: | > Ceph is a distributed storage and network file system designed to > provide > excellent performance, reliability, and scalability. > tags: > - openstack > - storage > - file-servers > - misc > peers: > mon: > interface: ceph > extra-bindings: > cluster: > public: > provides: > nrpe-external-master: > interface: nrpe-external-master > scope: container > … > storage: > osd-devices: > type: block > multiple: > range: 0- > osd-journal: > type: block > multiple: > range: 0-1 > > > As a user then you can deploy this charm and tell Juju to provide > distinct addresses for it on one or more spaces: > > juju deploy ~/path/to/charm/ceph --bind 'cluster=admin-api > public=public-api internal-api' > > Units of the ceph service will be deployed on machines which have access > to the "admin-api", "public-api", and "internal-api" spaces in MAAS, a > different network interface and address for each binding. > > Then, e.g. in a hook of the same charm, running 'network-get cluster > --primary-address' will only return the correct address - the one coming > from the "admin-api" space. > > > ### Juju GUI in the Controller > > Juju GUI is now automatically included in every Juju controller after > bootstrapping, thus eliminating the need to additionally deploy the Juju > GUI charm. > > In order to open the Juju GUI in the default browser the following > command should be used. > > juju gui > > The GUI connects to the model that is currently active. You are greeted > with the login window, where you will have to provide the credentials to > access the model. If you want to output your credentials in the > terminal for easier copy/paste into login window, run the GUI with the > '--show-credentials' option. > > juju gui --show-credentials > > > ### juju upgrade-gui > > The upgrade-gui command downloads the latest published GUI from the > streams and replaces the one on the controller. To verify which versions > of the GUI are available before the upgrade, try: > > juju upgrade-gui --list > > If you want to upgrade (or downgrade) to a specific version of the GUI, > provide the revision as a parameter to the upgrade-gui command, where > the revision listed by the `juju upgrade-gui --list`. For example: > > juju upgrade-gui 2.1.1 > > If you’d like to try a version of the GUI that has not been published in > the streams and is not listed yet, you are able to provide the blob > either from a charm or from the manually built GUI. Example: > > juju upgrade-gui /path/to/release.tar.bz2 > > In order to upgrade the GUI, you need proper access rights to > the controller. When an administrator upgrades the GUI, the users will > have to reload the open sessions in the browser. > > If you don not want to install the GUI into the controller, bootstrap > your controller with the '--no-gui option. > > > ### Juju Now Respects CharmStore Channels > > For more information on the new support for channels in the Charm Store > and how they work, please see our > [documentation](https://jujucharms.com/docs/devel/authors-charm-store > #entities-explained) on the subject. > > Support for channels has been brought into Juju via command options on the > relevant sub-commands: > > juju deploy > Juju upgrade-charm > > > ## Known issues > > * juju lxd bridge detection fallback is not reliable > Lp 1570573 > * Juju 2.0 no longer supports KVM for local provider > Lp 1547665 > * Cannot deploy a dense openstack bundle with native deploy > Lp 1555808 > * Cannot add LXD containers in 2.0beta4 on trusty > Lp 1568895 > * Address Allocation feature flag still enabled for MAAS provider > in Juju 2.0 > Lp 1568925 > * Newly created LXD container has zero network devices > Lp 1564395 > * LXD containers /etc/network/interfaces as generated by Juju gets > overwritten by LXD container start > Lp 1566801 > * juju restore-backup does not complete properly > Lp 1569467 > * Credentials files containing Joyent credentials must be updated to > work with beta3 (See "Joyent Provider No Longer Uses Manta Storage") > > > ## Resolved issues > > * Certificate error when visiting the embedded juju gui > Lp 1555083 > > * The client.watchall api command never responds when the model has > no machines > Lp 1560201 > > * Juju does not fall back to cloud-images if --bootstrap-series not > supplied > Lp 1560625 > > * Error cannot find network interface "lxcbr0": route ip+net: no > such network interface > Lp 1566589 > > * Juju cannot bootstrap on xenial without juju-mongodb3.2 package > Lp 1566628 > > * Agents stuck in "waiting for agent initialization to finish" with > lxd provider > Lp 1567683 > > * Juju should fallback to juju-mongodb after first failure to find > juju-mongodb3.2 > Lp 1568312 > > * Fallback for mongo packages doesn't include wily > Lp 1568390 > > * Region names for rackspace should accept caps and lowercase > Lp 1569024 > > * Jujud fails to start with "could not find a suitable binary for > "0.0/mmapv1"" > Lp 1569097 > > * Enable-ha with placement fails due to invalid jobmanagenetworking > Lp 1569196 > > * Failed to bootstrap because exec: "mongod": executable file not > found in $path > Lp 1569408 > > * Proxyupdater api facade does not set notifywatcherid in the result > Lp 1569725 > > * Provider/azure: creating subnet fails if the environment name is > too long > Lp 1524077 > > * Add xenial to supported series > Lp 1533262 > > * Ec2: destroy-controller blows the rate limit trying to delete > security group - can leave instances around > Lp 1537620 > > * --bootstrap-series can cause "no matching tools available" error > Lp 1538735 > > * Kill-controller fails on missing volume > Lp 1543223 > > * Concurent map access in joyent > Lp 1554251 > > * Help text for juju destroy-controller needs improving > Lp 1555248 > > * The addcharmwithauthorization api endpoint needs to respect > channels. > Lp 1560511 > > * Charm channels must be used on the controller. > Lp 1560520 > > * Charm store macaroons must be used on the controller. > Lp 1560531 > > * Juju 2 beta3 can't bootstrap to lcy02 > Lp 1563576 > > * Destroy-controller blocks when you've not removed an empty default > model > Lp 1563615 > > * "juju upgrade-juju --upload-tools" fails after "juju login" > Lp 1563762 > > * Kvm containers don't use correct parent interface device > Lp 1563853 > > * Juju2: charms fail with series mismatch when deployed to > containers in bundle > Lp 1564057 > > * Juju ssh doesn't work with multiple models > Lp 1566237 > > * Fallback to installing mongo 2.4 if no 3.2 doesn't work > Lp 1567182 > > * "juju destroy-controller" can leak hosted models > Lp 1567228 > > * Juju-run does not work on windows hosts > Lp 1426729 > > * Help text for juju destroy-model needs improving > Lp 1553272 > > * Help text for juju remove-service needs improving > Lp 1554687 > > * Help text for juju list-models needs improving > Lp 1556249 > > * Help text for juju show-cloud needs improving > Lp 1560595 > > * Help text for juju status needs improving > Lp 1560665 > > * Help text for juju list-clouds needs improving > Lp 1560667 > > * Update-clouds message improvement when fully up to date > Lp 1563843 > > * Region names should be case-insensitive but displayed as lowercase > Lp 1563845 > > * Help text for juju set-model-config needs improving > Lp 1563923 > > * Help text for juju get-model-config needs improving > Lp 1563924 > > * Help text for juju get-model-constraints needs improving > Lp 1563927 > > * Help text for juju set-model-constraints needs improving > Lp 1563928 > > * Help text for juju unset-model-config needs improving > Lp 1563938 > > * Help text for juju update-clouds needs improving > Lp 1563958 > > * All: mutex's copied by value > Lp 1563628 > > > Finally > > We encourage everyone to subscribe the mailing list at > juju@lists.ubuntu.com, or join us on #juju on freenode. > > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui > > -- > Juju-dev mailing list > juju-...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju