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

Re: charm layers hooks/install, how are they "merged"?

[fengxia]

Make sense. Thank you Stuart.


On 08/11/2017 06:31 AM, Stuart Bishop wrote:

On 11 August 2017 at 09:02, fengxia  wrote:

Hi Juju,

I'm building a charm by including two layers in layer.yaml:

includes:
   - 'layer:basic'
   - 'layer:pylxca'

Pylxca is a library I packaged into a "layer" format for reuse.

Both layers have a folder called "hooks", and each has a hook called
"install". The curious result is that after `charm build`, the pylxca's
install hook is the one in dist.

The pylxca layer should not be adding the hook stubs if the hooks/
directory. These are declared in layer:basic, and duplicating them in
the pylxca leads to the problem you describe.


So my question now is, if I want to use layers, and each layer defines its
own hooks so to help its implementation, how does `charm build` handle them?
Are they merged? From this test, only the last one will survive. If so, does
it mean only one layer can define hooks?

Only one layer should define the hook stubs. Layers can do it, as you
have found, and it can be useful in some debugging situations to
override and inject behaviour, but I don't think should ever go as far
as a release.

If multiple layers need hook specific code, they can all declare
handlers with the @hook decorator and they are all run in an arbitrary
order. Its best to avoid @hook completely though and just use normal
reactive states. So instead of using @hook('install'), use
@when_not('mycharm.installed') and have that handler set the
mycharm.installed state at the end.



--
Feng xia
Engineer
Lenovo USA

Phone: 5088011794
fx...@lenovo.com

Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums


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

Kafka support for filebeat, topbeat and packetbeat

[Tilman Baumann]

I just added Kafka output to filebeat, topbeat and packetbeat.
If anyone is interested...

"charm test" is broken for me, apologies if I committed a broken test.
I manually tested the filebeat changes, the rest is just copy-pasta.
(same code everywhere)

https://github.com/juju-solutions/layer-beats-base/pull/15
https://github.com/juju-solutions/layer-filebeat/pull/19
https://github.com/juju-solutions/layer-topbeat/pull/13
https://github.com/juju-solutions/layer-packetbeat/pull/5


Cheers
 Tilman Baumann

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

Re: charm layers hooks/install, how are they "merged"?

[Stuart Bishop]

On 11 August 2017 at 09:02, fengxia  wrote:
> Hi Juju,
>
> I'm building a charm by including two layers in layer.yaml:
>
> includes:
>   - 'layer:basic'
>   - 'layer:pylxca'
>
> Pylxca is a library I packaged into a "layer" format for reuse.
>
> Both layers have a folder called "hooks", and each has a hook called
> "install". The curious result is that after `charm build`, the pylxca's
> install hook is the one in dist.

The pylxca layer should not be adding the hook stubs if the hooks/
directory. These are declared in layer:basic, and duplicating them in
the pylxca leads to the problem you describe.

> So my question now is, if I want to use layers, and each layer defines its
> own hooks so to help its implementation, how does `charm build` handle them?
> Are they merged? From this test, only the last one will survive. If so, does
> it mean only one layer can define hooks?

Only one layer should define the hook stubs. Layers can do it, as you
have found, and it can be useful in some debugging situations to
override and inject behaviour, but I don't think should ever go as far
as a release.

If multiple layers need hook specific code, they can all declare
handlers with the @hook decorator and they are all run in an arbitrary
order. Its best to avoid @hook completely though and just use normal
reactive states. So instead of using @hook('install'), use
@when_not('mycharm.installed') and have that handler set the
mycharm.installed state at the end.

-- 
Stuart Bishop 

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