juju devel 2.0-beta4 is released
Uros Jovanovic
uros.jovanovic at canonical.com
Fri Apr 15 04:46:20 UTC 2016
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 <
curtis at 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-charmers at 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 at 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-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160415/703377d9/attachment.html>
More information about the Juju
mailing list