The future of Charm Helpers

[Cory Johns]

I feel like there's some confusion here about reactive vs. hookenv.  I've
never felt that there was any conflict between the two.  The reactive
pattern is intended to help your charm decide *when* to do something, while
hookenv encapsulates the methods that it will use to actually *do* that
thing.

Especially in the new proposed charms.helper (or charms.core, which I'm
fine with), I see that as containing all of the Python-friendly bindings
that let you call out to the Juju system.  The reactive framework itself
will use those, but I also fully expect charm layers to rely heavily on
them as well.  (Interface layers not so much, since they should be using
the conversation metaphor on top of the relations and ideally not getting
or setting data directly on the relation.)

For example, while I haven't worked with leadership so can't really speak
to that, I haven't felt the need to translate workload statuses into
reactive states and vice versa, and have had no issues with calling
hookenv.status_set() directly.  In particular,
https://github.com/johnsca/layer-apache-spark/blob/master/reactive/spark.py
is roughly how I think about managing workload status in a reactive charm.
 (Of course, if that approach is missing some significant benefit to
another approach, please let me know!)

On Mon, Nov 23, 2015 at 5:12 AM, Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> Yes thank you for this explanation.
>
>
> From my understanding, and please correct me if I'm wrong, hookenv is a
> low-level library operating below the reactive framework. A truly reactive
> Charm has no business in that library. Making that library reactive aware
> means removing it, since these functions can break reactive functionality.
> If there is functionality in the hookenv library that is still relevant in
> a reactive charm, then it should be put in charms.helper. Low-level hookenv
> functionality used by the reactive framework itself should be clearly
> separated. For example by putting it in charms.reactive.internal (I don't
> know the python way to hide internal functionality).
>
> Charms who are not reactive aware and need the low-level hookenv functions
> can keep using charmhelpers.core.hookenv.
>
>
>
> Kind regards
> Merlijn
>
>
>
>
>
> 2015-11-23 10:51 GMT+01:00 James Page <james.page at ubuntu.com>:
>
>> On Mon, Nov 23, 2015 at 9:49 AM, Merlijn Sebrechts <
>> merlijn.sebrechts at gmail.com> wrote:
>>
>>> 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.
>>>
>>
>>
>> Well charmhelpers.openstack will want to use charms.hookenv for example -
>> so charms.hookenv should be reactive aware, but should also be functional
>> without the reactive framework - does that make things clearer?
>>
>>
>>
>>>
>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> 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/fed261cf/attachment.html>