Weekly Development Summary

[Ian Booth]

Hi folks

A summary of what we've been doing this week in Juju.

Two new Azure regions have been added - koreasouth and koreacentral.
To use these on an existing Juju 2.x install, simply run
$ juju update-clouds

We continue to prepare for the 2.2.3 release. We were hoping to pull the trigger
this week but a few new issues from stakeholders were added to the milestone.
https://launchpad.net/juju/+milestone/2.2.3

Some issues fixed or being finalised:
- a particularly nasty Mongo replica set issue affecting some HA deployments
- some model destruction issues
- pending resources when an application is deployed again after failing once
- cloud names with underscores
- better able to handle duplicate instance ids in MAAS when a nodel fails to
deploy and is reused later

A new command "update-series" has been added which allows the series for an
application to be updated. Any new units deployed for that application
will use the specified series. We're working on a variation of the command to
allow the series for existing units/machines to be updated also.

On the cross model relations front, juju status and juju list-offers commands
have been tweaked to improve their output. The "list-offers" (offers) command by
default shows connection details to each offer, including user and relation id.
The "remove-relation" command now accepts a relation id and so it's possible to,
on the offering side, remove a cross model relation. Work is still being done to
support temporarily revoking a relation rather than removing it outright.

We continue to expand CI test coverage of Juju features. This week the
persistent storage feature gained test coverage.

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop
  Recent 2.2 commits: https://github.com/juju/juju/commits/2.2

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

Weekly Development Summary

[Ian Booth]

Hi folks

Here's a quick wrap up of what the Juju team has been doing this week.

We're almost ready for a new 2.2.3 release. Issues addressed are found on the
milestone:
https://launchpad.net/juju/+milestone/2.2.3

Some highlights include bundles supporting local resources, migration and
upgrade fixes, and machine placement directives ignoring constraints.

The work to allow upgrades from 1.25 continues and we're close to a working
proof of concept. Challenges have included lxc to lxd upgrades and dealing with
the significant difference between the 1.25 and 2.x data models.

On the cross model relations front, support for multi-controller relations now
includes a complete macaroon based authentication mechanism.

More usability improvements have landed, including clean up of the juju
resources commands and other papercuts.

The relations section of Juju status in tabular format has been cleaned up based
on feedback from the field. Display of bogus subordinate relations is fixed, and
the content has been enhanced to display both endpoints, ordered by the provider
application. Check it out and any additional feedback welcome.

The Jenkins infrastructure used for landing and CI continues to improve at a
rapid pace. There's been awesome work done to make everything robust and
maintainable and remove all the special case scripts and slave machines. This
has all been behind the scenes. But over the past couple of weeks the work to
integrate the Open Blue Ocean plugin means that developers gain a fantastic view
into the progress of their landing job and can easily drill down to see the
cause of any test failures.

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop
  Recent 2.2 commits: https://github.com/juju/juju/commits/2.2

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

Weekly Development Summary

[Heather Lanigan]

Here are a few highlights of things keeping the Juju team busy this week.

In Cross Model Relations:

   - When run on the offering model, juju status now displays information
   about offers and what connections there are to those offers.
   - The "juju offers" command is now a model command so that you can use
   -m to tell it to operate on a different model to the current one.

For improved user experience:

   - The 'attach' command has been renamed to 'attach-resource' to better
   reflect what it does with the prior addition of the 'attach-storage'
   command.  'attach' is now an alias of 'attach-resource'.
   - The 'charm-resources' has been introduced to replace 'juju charm
   resources' which was not compliant with Juju standard naming convention for
   commands.  'juju charm' and 'juju charm resources' commands have been
   deprecated.
   - Flags '--destroy-storage' and '--release-storage' have been added to
   the 'destroy-model' command.   If the user specifies neither, and there
   is persistent storage remaining, then the destruction fails and they will
   be prompted to choose one of the methods of storage removal.

Work on Juju 2.2.3 and Upgrades from Juju 1.25 to 2.x continues.

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Weekly Development Summary

[Menno Smits]

Hi everyone,

It's time for another update on what the Juju team has been up to. There's
been lots of great progress. Here are the highlights...

*Cross Model Relations*
It is now possible to establish relations between controllers! Here's a
basic example of how this looks on the command line:

$ juju bootstrap aws foo
$ juju deploy mysql
$ juju offer mysql:db

$ juju bootstrap aws bar
$ juju deploy mediawiki
$ juju expose mediawiki
$ juju relate mediawki:db foo:admin/default.mysql

This even works when the controllers are running in different clouds,
opening up all a number of exciting possibilities.

*Upgrades from Juju 1.25 to 2.x*
There's been lots of progress this week with the tooling to allow 1.25
deployments to be upgraded to 2.x. More aspects of Juju's model are now
covered by the export tools and work is now underway to support upgrading
of agent binaries. Work will start soon towards converting LXC containers
to LXD.

*Local Resources in Bundles*
Just as bundles can reference local charms, they can now reference
local resources.
As well as a referencing a revision of a resource in the charm store, you
can now specify a path to a local file when creating a bundle with charm
resources included. Here's a (fake) example of how this looks:

services:
  ubuntu:
charm: "/path/to/ubuntu/charm"
num_units: 1
resources:
  software: "/path/to/bundle/simple-bundle.zip"

Previously, the "software" field above could have only referred to a
resource revision number.

This feature will land in the "develop" branch in the next day or so and
will be released as part of Juju 2.3.

*Operating System Upgrade Support*
Work is underway on a new "update-series" command which allows the operator
to tell Juju that the operating system version for an application or
machine has changed. The idea is that the operator can perform an operating
system upgrade of one or more Juju managed machines and then tell Juju
about the change.

*Juju 2.2.3*
There will be another Juju 2.2 release out soon. It'll have the following
important changes:

   - Fixed a recently introduced upgrade issue
    affecting the Azure and
   vSphere providers.
   - Fixed model watching API to correctly report
    instance status changes.
   - Added  "primary-network"
   configuration attribute for the vSphere provider.
   - Jitter added to metrics collection to spread out load on Juju
   controllers.
   - Fixed to charm resource cleanup.
   - Fixed potential race  when
   completing model migrations.


*Quick Links*
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

Have a great weekend.

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

Re: Weekly Development Summary

[Andrew Wilkins]

On Fri, Jul 21, 2017 at 10:01 AM Anastasia Macmood <
anastasia.macm...@canonical.com> wrote:

> Hi
>
> A quick update on what keeps us, Juju team, busy...
>
> This week the team has been busy with an important task of improving
> developer experience in addition to improving the product.
>
> Of course, we have continued highly desired work on persistent storage
> with this week's focus on storage import [1] as well non-destructive
> storage removal [2] aspects. This effort also led to identifying
> improvements in model destruction that are now under way.
>
> We have made considerable progress in improving actions' footprint with
> work that prunes action results periodically [3].
>
> As usual, with a week that follows a new release of Juju, we have
> provided support to our existing users upgrading to a newer release.
>
> In addition, to excite and expedite developer experience, the team has
> put in place an improved merge job! Now developers can with greater ease
> track running tests when merging code.
>
> This week, the team has also worked on increasing functional coverage
> for persistent storage, relations as well as model migration.
>
> Last but not least, in a "call for arms", we are working on enabling
> users to specify primary network on VSphere overwriting the default VM
> network specified in OVF files shipped with Ubuntu images [4]. The
> nature of VSphere deployments, and the variety of networking
> combinations that are useful in the production environments, means that
> we need a hand from Juju community to verify our current approach. If
> you are interested in the ability to specify network in your VSphere,
> try the patch [5] linked in the bug and reach out to us with your feedback!
>

I've just managed to track down a vCenter suitable for testing, but it only
has standard switches, and they're in use so can't be changed. I tested
with a distributed vswitch/portgroup with a disabled NIC (just to see that
the code would work). It would be great if someone could test with a
working distributed vswitch/porgroup. I don't think we need to block
releasing the fix on that, though.

Cheers,
Andrew

Quick links:
>   Work pending: https://github.com/juju/juju/pulls
>   Recent commits: https://github.com/juju/juju/commits/develop
>
> Sincerely Yours,
>
> Anastasia
>
> [1] https://github.com/juju/juju/pull/7653
>
> [2] https://github.com/juju/juju/pull/7648 and
> https://github.com/juju/juju/pull/7649
>
> [3] https://github.com/juju/juju/pull/7645
>
> [4] https://bugs.launchpad.net/juju/+bug/1619812
>
> [5] https://github.com/juju/juju/pull/7660
>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Weekly Development Summary

[Anastasia Macmood]

Hi

A quick update on what keeps us, Juju team, busy...

This week the team has been busy with an important task of improving
developer experience in addition to improving the product.

Of course, we have continued highly desired work on persistent storage
with this week's focus on storage import [1] as well non-destructive
storage removal [2] aspects. This effort also led to identifying
improvements in model destruction that are now under way.

We have made considerable progress in improving actions' footprint with
work that prunes action results periodically [3].

As usual, with a week that follows a new release of Juju, we have
provided support to our existing users upgrading to a newer release.

In addition, to excite and expedite developer experience, the team has
put in place an improved merge job! Now developers can with greater ease
track running tests when merging code.

This week, the team has also worked on increasing functional coverage
for persistent storage, relations as well as model migration.

Last but not least, in a "call for arms", we are working on enabling
users to specify primary network on VSphere overwriting the default VM
network specified in OVF files shipped with Ubuntu images [4]. The
nature of VSphere deployments, and the variety of networking
combinations that are useful in the production environments, means that
we need a hand from Juju community to verify our current approach. If
you are interested in the ability to specify network in your VSphere,
try the patch [5] linked in the bug and reach out to us with your feedback!

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

Sincerely Yours,

Anastasia

[1] https://github.com/juju/juju/pull/7653

[2] https://github.com/juju/juju/pull/7648 and
https://github.com/juju/juju/pull/7649

[3] https://github.com/juju/juju/pull/7645

[4] https://bugs.launchpad.net/juju/+bug/1619812

[5] https://github.com/juju/juju/pull/7660



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

Weekly Development Summary

[Ian Booth]

It's been a busy week for Juju this week.

The big news is that after 4 betas and a few release candidates, we released
Juju 2.2.0 into the wild [1].

There's a number of great new features, including support for Oracle cloud and
much improved support for vSphere, and a nicer Azure login experience.

One aspect of our work for this release worth calling out is the focus on
improving Juju's scalability - both in terms of running many small/medium
models, as well as a few much larger models with thousands of unit agents. We're
not done yet, and a few improvements missed the deadline, so we're looking to
release a 2.2.1 version end of next week.

Areas where we've made changes so far include:
- throttling controller connections under load
- much improved metrics to allow us to identify scalability issues
- knobs to tune log and status history pruning
- splitting model into separate collections

With the new metrics, we used Prometheus, Telegraf, and Grafana to create a nice
dashboard to monitor and visualise system behaviour. There's a great blog post
by Rick Harding on this general topic [2]. Expect more communications soon
describing the new metrics and dashboards we used in the real world to do this
work. The best bit - using Juju itself makes visualising a running Juju
controller's metrics super easy.

[1] https://jujucharms.com/docs/stable/whats-new
[2] http://mitechie.com/blog/2017/3/20/operations-in-production

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

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

Weekly Development Summary

[Christian Muirhead]

Hi everyone -

It's Friday again! That means it's time for another Juju development
summary, and then the weekend.

Juju 2.2-rc1 was released on Tuesday and rc2 was released today with some
additional bug fixes, and support for loading credentials directly from the
Azure CLI [0]. Team focus has shifted briefly to some issues coming out of
very large Juju deployments. Fixing these bugs will improve stability,
especially in models with large numbers of units.

Key fixes from this effort (with more on the way):
* A field mismatch deleting status history meant that removing units would
cause a lot of load on Mongo [1]
* Rate limiting incoming API connections and log messages on the controller
[2] [3]
* Making the size of the Mongo connection pool configurable [4]
* Collecting more statistics from mgo in Prometheus [5]

Around fixing bugs and handling CI issues for the releases we're continuing
feature work on upgrades from Juju 1.25 to 2.x, cross-model relations, and
more support for persistent storage.

Quick links:
  Work pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

Cheers!
Christian

[0] https://github.com/juju/juju/pull/7457
[1] https://bugs.launchpad.net/juju/+bug/1696491
[2] https://github.com/juju/juju/pull/7470
[3] https://github.com/juju/juju/pull/7474
[4] https://github.com/juju/juju/pull/7481
[5] https://github.com/juju/juju/pull/7482
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Weekly Development Summary - and Juju 2.2-rc1 date

[Tim Penhey]

On 02/06/17 18:07, Anastasia Macmood wrote:
> On 02/06/17 15:11, Tim Penhey wrote:
...
>> Once we have confirmation from Solutions QA and JAAS that they are happy
>> with the release candidate, we will release is as 2.0.0
> 2.2.0 maybe?

Yes. That is what I meant.

Thanks,
Tim

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

Re: Weekly Development Summary - and Juju 2.2-rc1 date

[Anastasia Macmood]

On 02/06/17 15:11, Tim Penhey wrote:
> Hi all,
>
> Sorry for the weird encrypted one.
>
> The date for the release candidate is Tuesday the 6th of June. We really
> wanted to get it out this week, but we hit two issues that we just had
> to get done before the release candidate. We decided that a few extra
> days for a better quality release was worth it.
>
> On Tuesday we will be branching develop into a 2.2 branch. Also, we are
> enacting a slightly different policy around landing changes into the 2.2
> branch during the RC period. No extra bug fixes will be landed in 2.2
> once the release candidate has been cut unless it is a critical
> regression, in which case another candidate will be released. The
> intention here is that the release candidate will be a true candidate,
> and not just be another week to get fixes in before the final release.
> Once we have confirmation from Solutions QA and JAAS that they are happy
> with the release candidate, we will release is as 2.0.0
2.2.0 maybe?
>  final. Once this
> happens the landing restrictions will be lifted on the 2.2 branch.
>
> We already have a number of bugs that we want to get fixed for 2.2.1.
> Bugs that we have decided need to be fixed and put into the user's hands
> before the 2.3 release, which won't be for a number of months.
>
> The notable fixes of the last week:
>  * a number of race test fixes, Go 1.8 found more than 1.6
>  * long awaited log compression during log rotation
>  * additional configuration around max txn log size so large controllers
> can better handle large workloads happening very quickly
>  * issues with migrating models that use local charms
>
> There are just a couple more changes that we hope to land over the next
> day, that will improve performance on larger models.
>
> Also, the 2.2-rc1 milestone on Launchpad got significantly cleaned up.
> There were bugs that were marked as high priority that had been bounced
> from milestone to milestone with no one addressing them. These have been
> removed from milestones as they just weren't getting addressed that way.
>
> A lot of work has gone into the CI infrastructure this week to make it
> more robust and to produce less noise on the test runs. We are looking
> much better across all the CI tests. There are a few intermittent tests
> still bugging us, and a few CI tests that needed updating due to changes
> that landed over the week. On the whole though, we are very happy with
> the stability and robustness of this upcoming release.
>
> Cheers,
> Tim
>


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

Weekly Development Summary - and Juju 2.2-rc1 date

[Tim Penhey]

Hi all,

Sorry for the weird encrypted one.

The date for the release candidate is Tuesday the 6th of June. We really
wanted to get it out this week, but we hit two issues that we just had
to get done before the release candidate. We decided that a few extra
days for a better quality release was worth it.

On Tuesday we will be branching develop into a 2.2 branch. Also, we are
enacting a slightly different policy around landing changes into the 2.2
branch during the RC period. No extra bug fixes will be landed in 2.2
once the release candidate has been cut unless it is a critical
regression, in which case another candidate will be released. The
intention here is that the release candidate will be a true candidate,
and not just be another week to get fixes in before the final release.
Once we have confirmation from Solutions QA and JAAS that they are happy
with the release candidate, we will release is as 2.0.0 final. Once this
happens the landing restrictions will be lifted on the 2.2 branch.

We already have a number of bugs that we want to get fixed for 2.2.1.
Bugs that we have decided need to be fixed and put into the user's hands
before the 2.3 release, which won't be for a number of months.

The notable fixes of the last week:
 * a number of race test fixes, Go 1.8 found more than 1.6
 * long awaited log compression during log rotation
 * additional configuration around max txn log size so large controllers
can better handle large workloads happening very quickly
 * issues with migrating models that use local charms

There are just a couple more changes that we hope to land over the next
day, that will improve performance on larger models.

Also, the 2.2-rc1 milestone on Launchpad got significantly cleaned up.
There were bugs that were marked as high priority that had been bounced
from milestone to milestone with no one addressing them. These have been
removed from milestones as they just weren't getting addressed that way.

A lot of work has gone into the CI infrastructure this week to make it
more robust and to produce less noise on the test runs. We are looking
much better across all the CI tests. There are a few intermittent tests
still bugging us, and a few CI tests that needed updating due to changes
that landed over the week. On the whole though, we are very happy with
the stability and robustness of this upcoming release.

Cheers,
Tim

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

Weekly Development Summary - and Juju 2.2-rc1 date

[Tim Penhey]

bintUcW_UQOrQ.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Weekly Development Summary

[Andrew Wilkins]

Hi all,

It's been a busy week as we continue towards the 2.2-rc1 release. As Tim
said earlier in the week, the release will slip to next week as we continue
ironing out the kinks. One of the main things we've been focusing on this
week is improving scalability and resilience in large deployments, such as
JAAS.

One major issue [0] fixed is that if we overflow the transaction log
collection in Mongo, the controller will now automatically restart to get
all of the watchers back into the appropriate state. A new controller
config attribute, "max-txn-log-size", has been introduced, which allows you
to change the transaction log collection size from the default of 10MB.

Another critical fix is to prevent resource-get from blocking indefinitely
when fetching the resource fails [1]. Juju will now retry fetching
resources for a set number of attempts, and then abort if it continues to
fail, giving the operator a chance to fix the charm resources or charm code
itself.

Work is underway to run one log forwarding worker per model, instead of one
per controller as we have now. This will enable us to optimise the way in
which logs are managed, to improve scalability and performance. Having
per-model log forwarders will also enable future improvements to support
forwarding logs to cloud-specific logging facilities.

A handful of other notable fixes:
 - better validation of custom simplestreams metadata [2]
 - simplified mongo oplog size calculation, to prevent frequent mongo
restarts [3]
 - fixed an issue with add-storage, where the specified pool was not used
in some cases [4]
 - several fixes [5] [6] for model migration related to resources

Last week, Ian mentioned that there would be a snap forthcoming containing
a preview of storage improvements scheduled for the 2.3 release. This was
sent out earlier this week, and we're waiting for feedback. If you have a
moment, please try it out and let us know what you think. Next week we'll
aim to release an update to the snap, with the next bits: adding
--attach-storage to add-unit, and automatically placing VMs in the same AZ
as the attached volumes (at least for AWS).

Thanks for reading!

Cheers,
Andrew

---

Quick links:
  Work Pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

[0] https://bugs.launchpad.net/juju/+bug/1692792
[1] https://bugs.launchpad.net/juju/+bug/1627127
[2] https://bugs.launchpad.net/juju/+bug/1690456
[3] https://bugs.launchpad.net/juju/+bug/1677592
[4] https://bugs.launchpad.net/juju/+bug/1692729
[5] https://bugs.launchpad.net/juju/+bug/1692610
[6] https://bugs.launchpad.net/juju/+bug/1692646
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Weekly Development Summary

[Ian Booth]

Hi folks

That time of the week again - almost beer o'clock for those of us in Aus/NZ
timezones - and also time to recap on the happenings in the land of Juju
development over the past 7 days.

We're working hard to get a Juju 2.2 out the door. The week saw a release of 2.2
beta4 which included usability improvements to actions, openstack and oracle
providers. Focus this week has been on squashing a number of stakeholder bugs
and CI test failures. We aim to release an RC in a week or so all going well.

A couple of key development highlights apart from the usual fare of bug fixes
include:

- close to finishing improvements to how Juju storage operates - expect a snap
early next week to try out the feature which is targetted for Juju 2.3. You will
gain the ability to destroy a unit but leave its storage behind; this storage
can then be attached to a different unit or re-used when deploying a new
application instance.

- all of the CI and QA tools and scripts and test frameworks have been moved
across from Launchpad to live under the Juju repo on github. This is part of the
ongoing process to revamp and improve our test infrastructure to make everything
more robust and maintainable, and make writing CI tests as easy as possible.

- model migration improvements so that things play nicely together in a JAAS
world in addition to individual controllers

Quick links:
  Work Pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

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

Weekly Development Summary

[Tim Penhey]

Hi folks,

We are trying a new initiative to provide a simple way for casual 
observers of the mailing list to be able to get a quick view into the 
work being done in Juju.


There are several key areas of development that are ongoing within the 
Juju team.


Polish for the upcoming 2.2 release. Working out kinks in the openstack 
and oracle providers to make them easier to use, continuing improvements 
around memory and disk usage on the controller machines. 2.2-beta4 
should be coming out very shortly to get the latest fixes into peoples 
hands through the snap beta channel. Instructions will be in the release 
notes.


Continued work on the Cross Model Relations (CMR) commands and 
functionality. This is to allow applications to relate to other 
applications running in different models. At this stage work is focusing 
on making this work within a single controller, but done in such a way 
that expanding this to work with JAAS will be a progressive step. The 
CMR work is currently behind the feature flag "cross-model".


A key new feature is support for OpenSUSE 
(https://github.com/juju/juju/pull/7257) using series "opensuseleap".


Quick links:
  Work Pending: https://github.com/juju/juju/pulls
  Recent commits: https://github.com/juju/juju/commits/develop

Until next time...

Tim

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