Hi Merlijn On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts < [email protected]> wrote:
> I'm all for requiring everything under the charms namespace to be reactive > aware. > > It is hard for people who are less involved to make sense of all the > different ways to Charm. It's even harder because some ways get deprecated > faster than they get adopted (services framework). I think it's vital to > have a very clear message to charmers about what the recommended way is. We > shouldn't confuse them by exposing deprecated and risky ways to charm. > Let's bite the bullet and use this namespace change to start over with a > clear message. > I agree with the clear messaging here, but please lets not dead-end all of the charms that don't use reactive; The OpenStack charmers team and the ecosystem of partners who have charms that integrate into the OpenStack charm set have a large codebase which is not reactive based and won't be in the near term. Requiring that anything under the charms namespace is reactive aware is fine - but lets make that 'aware' not 'required' please. > > I'd say it like this: use bash or use reactive. Everything else is nice to > have but they shouldn't stumble upon it by accident. > > > > 2015-11-23 9:47 GMT+01:00 Stuart Bishop <[email protected]>: > >> On 23 November 2015 at 02:23, Marco Ceppi <[email protected]> >> wrote: >> >> > Under this proposal, `charmhelpers.core.hookenv` would more or less >> become >> > `charms.helper` and items like `charmhelpers.contrib.openstack` would be >> > moved to their own upstream project and be available as >> `charms.openstack`. >> > They will instead depend on `charms.helper` for previous `hookenv` >> methods. >> > This is a cleaner namespace that still providing the discoverability >> (search >> > pypi index for `charms` and you'll see the ecosystem basically owns that >> > space) desired from the current source tree. >> >> > With the new charm build pattern and reactive framework this would fit >> in >> > nicely as we continue on a "charming 2.0" march for quick, easy, and >> concise >> > ways to create charms. I welcome a continued discussion on the subject >> with >> > the hope we can reach a consensus soon on the best way forward. One >> thing is >> > clear, the current way of maintaining charm-helpers is neither scalable >> or >> > manageable. >> >> I don't think it matters what you do with the low level hookenv >> library, as reactive charms should be using a higher level library >> that sets states appropriately (and mixing calls just means state and >> hook environment will get out of sync). >> >> I think it is worth doing this in tandem with creating >> charms.reactive.hookenv. It is really, really useful having handlers >> watching for states like 'leadership.set.foo' or 'config.changed.bar' >> or 'workloadstatus.blocked', but if layers start using the lower level >> API then state will get out of sync with the hook environment. >> >> Or should everything under the charms namespace be reactive framework >> aware, with charms.reactive just being where the engine is stored? >> >> -- >> Stuart Bishop <[email protected]> >> >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > > > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
