The future of Charm Helpers

[Merlijn Sebrechts]

Hi James


> Requiring that anything under the charms namespace is reactive aware is
fine - but lets make that 'aware' not 'required' please.

I'm not sure I understand what you are saying. Could you explain this a bit
more?

For more context: What I propose is that everything under the Charms
namespace is reactive aware. Code does not get included in that namespace
if it isn't reactive aware. From my point of view this would pose no
problem to the ecosystems that are not yet reactive aware since they can
still use their current charmhelpers.xyz code. I think devs will assume
that everything in the charms namespace works together well.

2015-11-23 10:40 GMT+01:00 James Page <james.page at canonical.com>:

> Hi Merlijn
>
> On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts <
> merlijn.sebrechts at gmail.com> 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'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.
>>
>
>
> 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.
>
>
>>
>>
>>
>> 2015-11-23 9:47 GMT+01:00 Stuart Bishop <stuart.bishop at canonical.com>:
>>
>>> On 23 November 2015 at 02:23, Marco Ceppi <marco.ceppi at canonical.com>
>>> 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 <stuart.bishop at canonical.com>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151123/3c52a788/attachment.html>