The future of Charm Helpers

[James Page]

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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151123/d66d0f7e/attachment.html>