Re: [Ecosystem-engineering] The future of Charm Helpers

[Billy Olsen]

Cory,

Yeah, my understanding is that the namespace support in Python 3 is far
improved, and there was some support for it in Python 2.7 which still had
some unique issues from time to time. I'll play around with it a bit and if
I find anything worth mentioning I'll report back. At the very least, it
can go into a known issues/limitations list.

Part of the main reasons I offered this as only a mild concern is that I'm
not fully aware if oslo had made different choices in how namespaces were
being handled that directly impacted the compatibility between python 2 and
python 3 and using namespaced projects.

Thanks!

- Billy



On Mon, Nov 23, 2015 at 12:39 PM, Cory Johns 
wrote:

> Billy,
>
> I also notice that oslo used the following to define the namespace
> packages:
>
> __import__('pkg_resources').declare_namespace(__name__)
>
> My reading indicates that the preferred way to handle namespace packages
> in Python 2 (which is future-compatible with Python 3) is:
>
> from pkgutil import extend_path
> __path__ = extend_path(__path__, __name__)
>
> I tested this (https://github.com/johnsca/nspkg) and it seems to address
> the issues you had with oslo, even in Python 2.  (Note that I did also
> manually test the --system-site-packages + virtualenv case, though I didn't
> commit that code to test.sh in that repo.)
>
> This is the approach we've been using with the charms.X namespace, so I'm
> optimistic that we won't have the same issues you did with oslo.  And, as
> noted in my previous email, we'll probably be switching to Python 3  very
> soon anyway.  However, further testing is always welcome.
>
>
> On Mon, Nov 23, 2015 at 2:01 PM, Cory Johns 
> wrote:
>
>>
>> On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen 
>> wrote:
>>
>>> Secondly, I'm mildly concerned with the namespace of choice (using the
>>> shared charms. as the parent namespace). There may be a magical python 3ism
>>> that resolves the mixed development + packaged use of common code (think
>>> pip, virtualenvs, etc), but there were some issues that the oslo components
>>> within OpenStack ran into with a shared common namespace ((some are in a
>>> blog here
>>> ,
>>> and the spec to remove the namespaces within the oslo packages is here
>>> ).
>>> As the libraries are broken up, as I believe they should be, we need to
>>> make sure we've carefully considered how we expect some of these flows to
>>> work and make sure they work (and preferably well). Maybe its not really an
>>> issue, but I'd love to be convinced of that.
>>>
>>
>> I do think that namespace package support has been much improved in
>> Python 3 (in particular, 3.3 and above), but I must admit that I had not
>> run into nor been aware of the issues with namespace packages under earlier
>> versions of Python.  However, there has already been discussion of making
>> all layered / reactive charms Python 3 anyway, so maybe we can do some
>> quick tests to determine if those issues have been resolved with the new
>> namespace package support?
>>
>
>


-- 
Billy Olsen

billy.ol...@canonical.com
Software Engineer
Canonical USA
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju stable 1.25.1 is proposed

[Curtis Hovey-Canonical]

# juju-core 1.25.1

A new proposed stable release of Juju, juju-core 1.25.1, is now available.
This release may replace version 1.25.0 on Tuesday Dec 1.


## Getting Juju

juju-core 1.25.1 is available for Wily and backported to earlier
series in the following PPA:

https://launchpad.net/~juju/+archive/proposed

Windows, Centos, and OS X users will find installers at:

https://launchpad.net/juju-core/+milestone/1.25.1

Proposed releases use the "proposed" simple-streams. You must configure
the `agent-stream` option in your environments.yaml to use the matching
juju agents.


## Notable Changes

This releases addresses stability and performance issues.


## Resolved issues

  * "cannot allocate memory" when running "juju run"
Lp 1382556

  * Bootstrap with the vsphere provider fails to log into the virtual
machine
Lp 1511138

  * Add-machine with vsphere triggers machine-0: panic: juju home
hasn't been initialized
Lp 1513492

  * Using maas 1.9 as provider using dhcp nic will prevent juju
bootstrap
Lp 1512371

  * Worker/storageprovisioner: machine agents attempting to attach
environ-scoped volumes
Lp 1483492

  * Restore: agent old password not found in configuration
Lp 1452082

  * "ignore-machine-addresses" broken for containers
Lp 1509292

  * Deploying a service to a space which has no subnets causes the
agent to panic
Lp 1499426

  * /var/lib/juju gone after 1.18->1.20 upgrade and manual edit of
agent.conf
Lp 1444912

  * Maas provider: terminate-machine --force or destroy-environment
don't dhcp release container ips
Lp 1483879

  * Juju bootstrap fails to successfully configure the bridge juju-br0
when deploying with wily 4.2 kernel
Lp 1496972

  * Incompatible cookie format change
Lp 1511717

  * Error environment destruction failed: destroying storage: listing
volumes: get https://x.x.x.x:8776/v2//volumes/detail: local
error: record overflow
Lp 1512399

  * Replica set emptyconfig maas bootstrap
Lp 1412621

  * Juju can't find daily image streams from cloud-
images.ubuntu.com/daily
Lp 1513982

  * Rsyslog certificate fails when using ipv6/4 dual stack with
prefer-ipv6: true
Lp 1478943

  * Improper address:port joining
Lp 1518128


Finally

We encourage everyone to subscribe the mailing list at
juju-...@lists.canonical.com, or join us on #juju-dev on freenode.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Ecosystem-engineering] The future of Charm Helpers

[Cory Johns]

Billy,

I also notice that oslo used the following to define the namespace packages:

__import__('pkg_resources').declare_namespace(__name__)

My reading indicates that the preferred way to handle namespace packages in
Python 2 (which is future-compatible with Python 3) is:

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

I tested this (https://github.com/johnsca/nspkg) and it seems to address
the issues you had with oslo, even in Python 2.  (Note that I did also
manually test the --system-site-packages + virtualenv case, though I didn't
commit that code to test.sh in that repo.)

This is the approach we've been using with the charms.X namespace, so I'm
optimistic that we won't have the same issues you did with oslo.  And, as
noted in my previous email, we'll probably be switching to Python 3  very
soon anyway.  However, further testing is always welcome.


On Mon, Nov 23, 2015 at 2:01 PM, Cory Johns 
wrote:

>
> On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen 
> wrote:
>
>> Secondly, I'm mildly concerned with the namespace of choice (using the
>> shared charms. as the parent namespace). There may be a magical python 3ism
>> that resolves the mixed development + packaged use of common code (think
>> pip, virtualenvs, etc), but there were some issues that the oslo components
>> within OpenStack ran into with a shared common namespace ((some are in a
>> blog here
>> ,
>> and the spec to remove the namespaces within the oslo packages is here
>> ).
>> As the libraries are broken up, as I believe they should be, we need to
>> make sure we've carefully considered how we expect some of these flows to
>> work and make sure they work (and preferably well). Maybe its not really an
>> issue, but I'd love to be convinced of that.
>>
>
> I do think that namespace package support has been much improved in Python
> 3 (in particular, 3.3 and above), but I must admit that I had not run into
> nor been aware of the issues with namespace packages under earlier versions
> of Python.  However, there has already been discussion of making all
> layered / reactive charms Python 3 anyway, so maybe we can do some quick
> tests to determine if those issues have been resolved with the new
> namespace package support?
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Ecosystem-engineering] The future of Charm Helpers

[Cory Johns]

On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen 
wrote:

> Secondly, I'm mildly concerned with the namespace of choice (using the
> shared charms. as the parent namespace). There may be a magical python 3ism
> that resolves the mixed development + packaged use of common code (think
> pip, virtualenvs, etc), but there were some issues that the oslo components
> within OpenStack ran into with a shared common namespace ((some are in a
> blog here
> ,
> and the spec to remove the namespaces within the oslo packages is here
> ).
> As the libraries are broken up, as I believe they should be, we need to
> make sure we've carefully considered how we expect some of these flows to
> work and make sure they work (and preferably well). Maybe its not really an
> issue, but I'd love to be convinced of that.
>

I do think that namespace package support has been much improved in Python
3 (in particular, 3.3 and above), but I must admit that I had not run into
nor been aware of the issues with namespace packages under earlier versions
of Python.  However, there has already been discussion of making all
layered / reactive charms Python 3 anyway, so maybe we can do some quick
tests to determine if those issues have been resolved with the new
namespace package support?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 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.sebrec...@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 :
>
>> On Mon, Nov 23, 2015 at 9:49 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@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 :
>>>
 Hi Merlijn

 On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts <
 merlijn.sebrec...@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 :
>
>> On 23 November 2015 at 02:23, Marco Ceppi 
>> wrote:
>>
>> > Under this proposal, `charmhelpers.core.hookenv` would more or less
>> beco

usr and pwd of openstack------>答复: juju deploy failure on nova

[wuwenbin]

Hi Billy：
   You’re right about relationship. Now another problem occurs that 
username and password to log openstack-dashboard can’t be found. I check 
keystone config.yaml, and  find related config below, while that doesn’t work. 
I also try to use mysql while password is also not known. So if you know what 
they are or how to find them, please help me.
   Thanks.
Best regards
Cathy

admin-user:
default: admin
type: string
description: Default admin user to create and manage.
  admin-password:
default: None
type: string
description: |
  Admin password. To be used *for testing only*. Randomly generated by
  default.

发件人: Billy Olsen [mailto:billy.ol...@canonical.com]
发送时间: 2015年11月23日 1:57
收件人: wuwenbin
抄送: ad...@canonical.com; jiangrui (D); juju@lists.ubuntu.com; Weidong.Shao; 
Qinchuan; Ashlee Young; Zhaokexue
主题: Re: juju deploy failure on nova

Hi Cathy,

These messages are used to indicate why the service is not a fully functional 
service.. As you point out, the software packages for the base charm service 
has been installed at this point in time, but needs additional relations in 
order to make the service a fully functioning service. These are normally 
expected messages when the service has just been deployed.

If you proceed at this point to adding the missing relations, you'll see this 
message disappear from the status output.

Thanks,

Billy


On Sat, Nov 21, 2015 at 1:59 AM, wuwenbin 
mailto:wuwenb...@huawei.com>> wrote:
Hi Adam:
 I download trusty codes and use juju to deploy openstack. While there 
are problems about nova-cloud-controller and nova-compute.
 Error info is as follows. I think that installing charm is an 
independent operation because later we will add relationship between those 
charms. I have no idea what’t going on.
 Looking forward for your replay.
 Thanks.
Best regards
Cathy

Error info:
nova-cloud-controller:
charm: local:trusty/nova-cloud-controller-501
exposed: false
service-status:
  current: blocked
  message: 'Missing relations: messaging, image, compute, identity, 
database'
  since: 21 Nov 2015 12:44:35+08:00
relations:
  cluster:
  - nova-cloud-controller
units:
  nova-cloud-controller/0:
workload-status:
  current: blocked
  message: 'Missing relations: messaging, image, compute, identity, 
database'
  since: 21 Nov 2015 12:44:35+08:00
agent-status:
  current: idle
  since: 21 Nov 2015 16:39:38+08:00
  version: 1.25.0.1
agent-state: started
agent-version: 1.25.0.1
machine: "5"
open-ports:
- /tcp
- 8773/tcp
- 8774/tcp
- 9696/tcp
public-address: 192.168.122.242
  nova-compute:
charm: local:trusty/nova-compute-133
exposed: false
service-status:
  current: blocked
  message: 'Missing relations: messaging, image'
  since: 21 Nov 2015 16:40:46+08:00
relations:
  compute-peer:
  - nova-compute
units:
  nova-compute/0:
workload-status:
  current: blocked
  message: 'Missing relations: messaging, image'
  since: 21 Nov 2015 16:40:46+08:00
agent-status:
  current: idle
  since: 21 Nov 2015 16:40:48+08:00
  version: 1.25.0.1
agent-state: started
agent-version: 1.25.0.1
machine: "1"
public-address: 192.168.122.56

log info:
unit-nova-compute-0[3088]: 2015-11-21 08:50:56 WARNING 
unit.nova-compute/0.juju-log server.go:268 messaging relation is missing and 
must be related for functionality.
unit-nova-compute-0[3088]: 2015-11-21 08:50:56 WARNING 
unit.nova-compute/0.juju-log server.go:268 image relation is missing and must 
be related for functionality.

--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju



--
Billy Olsen
billy.ol...@canonical.com
Software Engineer
Canonical USA
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: The future of Charm Helpers

[Merlijn Sebrechts]

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 :

> On Mon, Nov 23, 2015 at 9:49 AM, Merlijn Sebrechts <
> merlijn.sebrec...@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 :
>>
>>> Hi Merlijn
>>>
>>> On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts <
>>> merlijn.sebrec...@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 :

> On 23 November 2015 at 02:23, Marco Ceppi 
> 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 l

Re: The future of Charm Helpers

[James Page]

On Mon, Nov 23, 2015 at 9:49 AM, Merlijn Sebrechts <
merlijn.sebrec...@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 :
>
>> Hi Merlijn
>>
>> On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@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 :
>>>
 On 23 November 2015 at 02:23, Marco Ceppi 
 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 

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju

>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 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 :

> Hi Merlijn
>
> On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts <
> merlijn.sebrec...@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 :
>>
>>> On 23 November 2015 at 02:23, Marco Ceppi 
>>> 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 
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: The future of Charm Helpers

[James Page]

Hi Merlijn

On Mon, Nov 23, 2015 at 9:32 AM, Merlijn Sebrechts <
merlijn.sebrec...@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 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 :
>
>> On 23 November 2015 at 02:23, Marco Ceppi 
>> 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 
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Fwd: The future of Charm Helpers

[Merlijn Sebrechts]

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.



2015-11-23 9:47 GMT+01:00 Stuart Bishop :

> On 23 November 2015 at 02:23, Marco Ceppi 
> 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 
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Ecosystem-engineering] The future of Charm Helpers

[James Page]

Hi Marco

On Sun, Nov 22, 2015 at 7:23 PM, Marco Ceppi 
wrote:

> Hello everyone,
>
> I'm rebooting this conversation because it never fully came to a
> resolution and since this topic was discussed a lot has happened in the
> Charm Ecosystem. I still hold firm, and a lot of charmers I've spoken with
> agree, that charm helpers has become the opposite which it originally
> helped to solve - a concise and tasteful way to bind Python to Juju. I've
> been considering ways to resolve this, providing a clear way for users to
> author Python charms, while not diminishing the large breadth of helpers
> and methods already created.
>
> A new approach I'd like to present is a clean break from the
> "charm-helpers" name and a transition to a new library, `charms.helper`.
> This name follows the same scheme that the reactive framework does,
> `charms.reactive` and is a way we can continue the practice of producing
> helpers around the charm ecosystem without the need of a monolithic code
> base.
>
> 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.
>

I'm +1 on this approach and I think we should just bit the bullet and get
it done.


>
> This clean break will allow us to correct a few naming mistmatches and
> allow us to incubate a transition period where charm authors can use and
> try these but the current charm-helpers library has charms.helper as a
> dependency and map current `charmhelpers.core.hookenv` to the new
> `charms.helper`. I've already started work on a strawman to demonstrate how
> charms.helper could look and will share that later this week.
>
> 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.
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: The future of Charm Helpers

[Stuart Bishop]

On 23 November 2015 at 02:23, Marco Ceppi  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 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju