Re: Dynamically registering reactive handlers at runtime

On 12 February 2016 at 22:55, Merlijn Sebrechts wrote: > Hi all > > > We have a layer that can install a number of different packages. It decides > at runtime which packages will be installed. This layer uses the `apt` layer > which sets a state `apt.installed.`. > >

Re: @when('config.changed')

On 18 February 2016 at 01:44, Cory Johns wrote: > If a charm config option has changed, the state "config.changed" will be set > for the duration of the hook. Additionally, specific states will be set for > each config option that changed; that is, if option "foo" has

[Review Queue] lis-test-charm, etcd

I reviewed the HyperV lis-test-charm today that had a few boilerplate files left inside the charm that should be removed before it passes review: https://bugs.launchpad.net/charms/+bug/1513612 I also reviewed a change to the etcd charm. I pushed this charm to the charm store using the new charm2

Layered Hadoop Core

The big data team just updated the apache-core-batch-processing bundle in ~bigdata-dev ( https://jujucharms.com/u/bigdata-dev/apache-core-batch-processing) to use the new layered charms. This makes the charms much easier to understand, maintain, and extend. We're asking for more testing by the

Re: @when('config.changed')

On Wed, Feb 17, 2016 at 5:56 PM Matt Bruzek wrote: > I hate to go against the love-in here. While I desperately want a > configuration changed feature for the reactive framework. I disagree with > the way it was implemented. I brought up issues with this

Re: @when('config.changed')

I hate to go against the love-in here. While I desperately want a configuration changed feature for the reactive framework. I disagree with the way it was implemented. I brought up issues with this implementation in the pull request: https://github.com/juju-solutions/layer-basic/pull/36 It feels

Re: @when('config.changed')

That's a very good point. Marco Ceppi: > Relations are best served being managed by the interface layer. Which > should consume the data and raise states as appropriate. > > On Wed, Feb 17, 2016 at 3:45 PM Nick Moffitt > wrote: > > > Cory Johns: > > > If a charm

Re: @when('config.changed')

Cool! I'll work that into my charms tomorrow. Might as well go all out on the new stuff ;) Tom On 17 Feb 2016 18:48, "Marco Ceppi" wrote: > This is awesome, glad to see this wrapped in the reactive framework. Will > make a lot of my layers much simpler! > > Marco > >

@when('config.changed')

Just wanted to give a heads-up about a feature that landed in the reactive base layer yesterday. If a charm config option has changed, the state "config.changed" will be set for the duration of the hook. Additionally, specific states will be set for each config option that changed; that is, if

Re: Introducing, juju resources!

Hi Moonstone! On Fri, 12 Feb 2016 at 21:27 Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > Moonstone have been working hard on a new feature coming up in Juju 2.0 > called "Juju Resources", and we're now at a point where we can share the > goodness and call for bugs/feedback!

Re: Units & resources: are units homogeneous?

I think it's fine for units to self-organise into specific functions. We'll add a means for these functions to be described to the user, later. The only rule is that the config and resources presented to units are consistent, or trend to consistency. In other words, when I set config or modify

Re: Units & resources: are units homogeneous?

I wanted to add that the reason we're curious about this is because we're working on how Juju can help provide insights into things that could be off/wrong between units. If we expect the units to be the same, then things like warning users that a unit hasn't yet gotten a resource that the others