Re: Please promulgate Mattermost charm

[Cory Johns]

Merlijn,

cs:mattermost (https://jujucharms.com/mattermost/) has been promulgated
from cs:~tengu-team/mattermost

Thanks!

On Sat, Jun 16, 2018 at 7:31 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> I created a Charm for Mattermost based on Casey's initial proof of
> concept. I've been using it for more than a year now to host a Mattermost
> instance for our local hackerspace. I can highly recommend the application,
> it's a worthy Slack alternative!
>
> So, hereby my -better-late-than-never- request to promulgate the charm.
>
> https://jujucharms.com/u/tengu-team/mattermost/
>
> The charm supports both http and https traffic (with a lets encrypt
> certificate that gets automatically renewed) and stores its data (encrypted
> at rest) in PostgreSQL.
>
>
>
> Regards
> Merlijn
> --
> 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

python-libjuju 0.8.0

[Cory Johns]

Greetings,

Today we released version 0.8.0 of the Python bindings for the Juju API.
The full changelog can be found at
https://pythonlibjuju.readthedocs.io/en/latest/changelog.html with the
changes from this release being:

* Add support for adding a manual (ssh) machine (#240)
* Backwards compatibility fixes (#213)
* Implement model.get_action_output (#242)
* Fix JSON serialization error for bundle with lxd to unit placement (#243)
* Fix reference in docs to connect_current (#239)
* Wrap machine agent status workaround in version check (#238)
* Convert seconds to nanoseconds for juju.unit.run (#237)
* Fix spurious intermittent failure in test_machines.py::test_status (#236)
* Define an unused juju-zfs lxd storage pool for Travis (#235)
* Add support for Application get_actions (#234)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

charms.reactive 0.6.3 has been released

[Cory Johns]

This is a bug-fix release with the following changes:


   - Export endpoint_from_name as well (#174)
   - Rename Endpoint.joined to Endpoint.is_joined (#168)
   - Only pass one copy of self to Endpoint method handlers (#172)
   - Make Endpoint.from_flag return None for unset flags (#173)
   - Fix hard-coded version in docs config (#167)
   - Fix documentation of unit_name and application_name on RelatedUnit
   (#165)
   - Fix setdefault on Endpoint data collections (#163)

The full changelog can be found at
https://charmsreactive.readthedocs.io/en/latest/changelog.html

A special call-out of the change from #173 is warranted: the
endpoint_from_flag (previously relation_from_state) helper was incorrectly
returning an Endpoint instance when the flag in question was not set if an
interface layer was implemented using the new Endpoint pattern.  It now
returns None to match the previous behavior with RelationBase
implementations.  If for some reason you need to get an instance of the
Endpoint regardless of the state of the flag, you can use
endpoint_from_name with the name of the endpoint rather than the full flag,
although this is not generally recommended as it does not work with older
RelationBase implementations, since they require the context provided by
the flag.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re:

[Cory Johns]

;   File "/snap/conjure-up/994/lib/python3.6/site-packages/juju/controller.py",
> line 68, in connect
> await self._connector.connect_controller(controller_name)
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connector.py",
> line 90, in connect_controller
> bakery_client=self.bakery_client_for_controller(controller_name),
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connector.py",
> line 59, in connect
> self._connection = await Connection.connect(**kwargs)
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
> line 166, in connect
> await self._connect_with_redirect([(endpoint, cacert)])
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
> line 509, in _connect_with_redirect
> login_result = await self._connect_with_login(endpoints)
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
> line 481, in _connect_with_login
> result = (await self.login())['response']
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
> line 536, in login
> "params": params,
>   File 
> "/snap/conjure-up/994/lib/python3.6/site-packages/juju/client/connection.py",
> line 314, in rpc
> raise errors.JujuAPIError(result)
> juju.errors.JujuAPIError: no credentials provided
> 2018-04-20 18:00:11,696 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:53 - Setting Shutdown at conjureup/events.py:166
> 2018-04-20 18:00:11,700 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:53 - Received Shutdown at conjureup/events.py:176
> 2018-04-20 18:00:11,701 [INFO] conjure-up/canonical-kubernetes -
> events.py:180 - Shutting down
> 2018-04-20 18:00:11,702 [INFO] conjure-up/canonical-kubernetes -
> app_config.py:224 - Storing conjure-up state
> 2018-04-20 18:00:11,886 [INFO] conjure-up/canonical-kubernetes -
> app_config.py:233 - State saved
> 2018-04-20 18:00:11,887 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:200 - Cancelling pending task:  coro=<WebSocketCommonProtocol.close_connection() done, defined at
> /snap/conjure-up/994/lib/python3.6/site-packages/websockets/protocol.py:695>
> result=None>
> 2018-04-20 18:00:11,887 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:200 - Cancelling pending task:  coro=<BootstrapController.wait() running at /snap/conjure-up/994/lib/
> python3.6/site-packages/conjureup/controllers/bootstrap/tui.py:17>
> wait_for= 0x7f4593155078>()]>>
> 2018-04-20 18:00:11,888 [DEBUG] conjure-up/canonical-kubernetes -
> events.py:200 - Cancelling pending task:  coro=<WebSocketCommonProtocol.transfer_data() done, defined at
> /snap/conjure-up/994/lib/python3.6/site-packages/websockets/protocol.py:486>
> result=None>
> 2018-04-20 18:00:12,550 [ERROR] conjure-up/canonical-kubernetes -
> concurrent.futures: _base.py:299 - exception calling callback for  at 0x7f45907ea4a8 state=finished returned NoneType>
> Traceback (most recent call last):
>   File "/snap/conjure-up/994/usr/lib/python3.6/concurrent/futures/_base.py",
> line 297, in _invoke_callbacks
> callback(self)
>   File "/snap/conjure-up/994/usr/lib/python3.6/asyncio/futures.py", line
> 419, in _call_set_state
> dest_loop.call_soon_threadsafe(_set_state, destination, source)
>   File "/snap/conjure-up/994/usr/lib/python3.6/asyncio/base_events.py",
> line 620, in call_soon_threadsafe
> self._check_closed()
>   File "/snap/conjure-up/994/usr/lib/python3.6/asyncio/base_events.py",
> line 357, in _check_closed
> raise RuntimeError('Event loop is closed')
> RuntimeError: Event loop is closed
>
> Thanks.-
>
>
> 2018-04-20 17:57 GMT-03:00 Cory Johns <cory.jo...@canonical.com>:
>
>> Sebastian,
>>
>> Can you provide us with the conjure-up.log file from
>> ~/.cache/conjure-up/conjure-up.log?  Are you selecting a credential name
>> from the list in conjure-up and then getting that error, or is the error
>> coming from later in the process (after starting the deployment)?
>>
>> I don't think that the non-admin user should make any difference, as long
>> as you can authenticate to the controller as that user with Juju, but I
>> haven't actually tested with a non-standard user.  But the error sounds
>> like it's coming from something else anyway, and as I said, I wouldn't
>> expect it to make much difference.
>>
>> - Cory
>>
>> On Fri, Apr 20, 2018 at 2:29 PM, sSeBBaSs <ssebb...@gmail.com> wrote:
>>
>>> Hi guys
>>>
>>> I need some help.
>>> I'm trying to conjure-up canonical-kubernetes, in an already
>>> bootstrapped controller on an custom model, with another user than the
>>> default admin, and I keep receiving a credentials not found error message.
>>>
>>>
>>>
>>>
>>>
>>> --
>>> ---
>>> Sebastian Juárez
>>> Mail: ssebb...@gmail.com
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
>
> --
> ---
> Sebastian Juárez
> Mail: ssebb...@gmail.com
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re:

[Cory Johns]

Sebastian,

Can you provide us with the conjure-up.log file from
~/.cache/conjure-up/conjure-up.log?  Are you selecting a credential name
from the list in conjure-up and then getting that error, or is the error
coming from later in the process (after starting the deployment)?

I don't think that the non-admin user should make any difference, as long
as you can authenticate to the controller as that user with Juju, but I
haven't actually tested with a non-standard user.  But the error sounds
like it's coming from something else anyway, and as I said, I wouldn't
expect it to make much difference.

- Cory

On Fri, Apr 20, 2018 at 2:29 PM, sSeBBaSs  wrote:

> Hi guys
>
> I need some help.
> I'm trying to conjure-up canonical-kubernetes, in an already bootstrapped
> controller on an custom model, with another user than the default admin,
> and I keep receiving a credentials not found error message.
>
>
>
>
>
> --
> ---
> Sebastian Juárez
> Mail: ssebb...@gmail.com
>
>
>
> --
> 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: Should 'juju status' always include a timestamp

[Cory Johns]

I'm also +1 on a timestamp.

On Wed, Apr 18, 2018 at 8:22 AM, Jason Hobbs 
wrote:

> Yes, a timestamp is always appropriate.
>
> On Wed, Apr 18, 2018 at 3:12 AM, Merlijn Sebrechts
>  wrote:
> > +1
> >
> > Op wo 18 apr. 2018 om 09:19 schreef John A Meinel
> > :
> >>
> >> I was just going over a list of pastes from James Beedy on this bug:
> >>   https://bugs.launchpad.net/juju/+bug/1763963
> >>
> >> And I realized that something that would be really nice is to just have
> >> some sort of timestamp so you could see how much time elapsed between
> each
> >> "juju status". And given the use of 'juju status' it seems like
> something
> >> that would generally be useful. (sharing a snapshot with someone else
> would
> >> always be done with the context of *when* you ran that status, so you
> could
> >> correlate it with other information like load metrics, etc.)
> >>
> >> Thoughts? It seems easy enough to add, but do people feel that it
> >> does/doesn't belong?
> >>
> >> John
> >> =:->
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Change to layer:basic: use_venv & include_system_packages on by default

[Cory Johns]

Greetings,

It was brought to my attention last week that one area where this change
will visibly affect charms is with actions.  Your action will need to to be
run from within the venv.  There is an existing activate_venv function
provided by the basic layer, but with the most recent change there is an
even easier way to handle it: simply change the shebang line at the top of
your action file to:

#!/usr/local/sbin/charm-env python3

When your action is run, it will activate the proper venv, and it will also
add $JUJU_CHARM_DIR/lib to your PYTHONPATH to make it easy to use library
files included in your charm or base layers.

On Thu, Mar 8, 2018 at 3:51 PM, Cory Johns <cory.jo...@canonical.com> wrote:

> Greetings,
>
> A change to layer:basic just landed[1] that changes the default value for
> the use_venv and include_system_packages layer options[2] to be enabled by
> default.
>
> This change will prevent a confusing bug that people run into when dealing
> with subordinates or co-located charms on a single machine: if co-located
> charms have different versions of some of their dependencies, especially
> charms.reactive or charmhelpers, they would conflict and sometimes cause
> one of the charms to break.  This fixes the issue by isolating the charm's
> Python dependencies in a virtual environment.  The change to
> include_system_packages is to ensure that charms that rely on Python
> libraries installed via apt will still function.
>
> In general, this should be transparent to almost every charm.  The only
> real concern is if the charm relies on command-line tools provided by any
> of the Python packages; with the packages now in the venv, the venv will
> need to be activated before the CLI tools can be used.  The PR does provide
> shims for the charms.reactive CLI and charmhelpers CLI (chlp), as well as
> the layer_option CLI provided by the basic layer itself.  These can be
> accessed globally and will use Juju context information to activate the
> correct virtual environment.
>
> On the off chance that you do run into an issue with this change, it's
> easy to disable it for your charm.  Just add the following to your
> layer.yaml:
>
> options:
>   basic:
> use_venv: false
>
>
> [1]: https://github.com/juju-solutions/layer-basic/pull/105
> [2]: https://charmsreactive.readthedocs.io/en/latest/
> layer-basic.html#layer-configuration
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Change to layer:basic: use_venv & include_system_packages on by default

[Cory Johns]

Greetings,

A change to layer:basic just landed[1] that changes the default value for
the use_venv and include_system_packages layer options[2] to be enabled by
default.

This change will prevent a confusing bug that people run into when dealing
with subordinates or co-located charms on a single machine: if co-located
charms have different versions of some of their dependencies, especially
charms.reactive or charmhelpers, they would conflict and sometimes cause
one of the charms to break.  This fixes the issue by isolating the charm's
Python dependencies in a virtual environment.  The change to
include_system_packages is to ensure that charms that rely on Python
libraries installed via apt will still function.

In general, this should be transparent to almost every charm.  The only
real concern is if the charm relies on command-line tools provided by any
of the Python packages; with the packages now in the venv, the venv will
need to be activated before the CLI tools can be used.  The PR does provide
shims for the charms.reactive CLI and charmhelpers CLI (chlp), as well as
the layer_option CLI provided by the basic layer itself.  These can be
accessed globally and will use Juju context information to activate the
correct virtual environment.

On the off chance that you do run into an issue with this change, it's easy
to disable it for your charm.  Just add the following to your layer.yaml:

options:
  basic:
use_venv: false


[1]: https://github.com/juju-solutions/layer-basic/pull/105
[2]:
https://charmsreactive.readthedocs.io/en/latest/layer-basic.html#layer-configuration
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgate request

[Cory Johns]

Xav,

The charm has been promulgated and is now available as cs:prometheus2 under
the control of the prometheus-charmers team.

On Tue, Mar 6, 2018 at 10:20 PM, Xav Paice  wrote:

> Hi,
>
> I'd like to request cs:~prometheus-charmers/prometheus2 gets
> promulgated.  This is the charm to deploy/manage Prometheus 2, which has
> a completely different config to Prometheus 1.
>
> Thanks
> Xav Paice
> Cloud Reliability Engineer - BootStack
> Canonical, Ltd
>
>
>
> --
> 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: Promulgate charms

[Cory Johns]

Thomas,

These charms have been promulgated and tengu-team should have access to
update them going forward.  There was an old precise version of opentsdb
owned by ~charmers which I unpromulgated as per our normal process for
charms owned by ~charmers.  It is still accessible as cs:~charmers/opentsdb
if needed.

On Fri, Mar 2, 2018 at 9:45 AM, Thomas Vanhove 
wrote:

> Hi all,
>
> Tengu-team has some new charms ready to be promulgated:
> https://jujucharms.com/u/tengu-team/activemq/
> https://jujucharms.com/u/tengu-team/chronograf/
> https://jujucharms.com/u/tengu-team/arangodb/
> https://jujucharms.com/u/tengu-team/kapacitor/
> https://jujucharms.com/u/tengu-team/neo4j/
> https://jujucharms.com/u/tengu-team/node-red/
> https://jujucharms.com/u/tengu-team/opentsdb/
>
> If you have any questions or remarks, let me know!
>
> Best regards,
>
> Thomas Vanhove
> --
> Thomas Vanhove, PhD
> Founder & CEO
> Tengu
> m: +32 494 84 91 49 <+32%20494%2084%2091%2049>
> w: www.tengu.io/  e: thomas.vanh...@tengu.io
>    
> 
>
> --
> 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

charms.reactive 0.6.2

[Cory Johns]

Greetings,

A small patch release for charms.reactive went out today, with a bug fix
and some doc improvements:

* Hotfix for issue #161 (#162)
* Add diagram showing endpoint workflow and all_departed_units example to
docs (#157)
* Fix doc builds on RTD (#156)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

python-libjuju 0.7.3

[Cory Johns]

Greetings,

Today we released version 0.7.3 of the Python bindings for the Juju API.
The full changelog can be found at
https://pythonlibjuju.readthedocs.io/en/latest/changelog.html with the
changes from this release being:

* Full macaroon bakery support (#206)
* Fix regression with deploying local charm, add test case (#209)
* Expose a machines series (#208)
* Automated test runner fixes (#205)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

charms.reactive 0.6.1

[Cory Johns]

Greetings,

Today we released version 0.6.1 of charms.reactive.  The full changelog can
be found at https://charmsreactive.readthedocs.io/en/latest/changelog.html with
the changes from this release being:

* Separate departed units from joined in Endpoint (#153)
* Add deprecated placeholder for RelationBase.from_state (#148)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [charms] Request to promulgate charms

[Cory Johns]

Alvaro,

The three charms have been promulgated (the first already was) and the
permissions set so that prometheus-charmers can release updates to stable
without reaching out to the list.

As far as I know, the promulgate sub-command will not be added to the charm
command, and new promulgations will continue to need to go through the list.

On Fri, Jan 26, 2018 at 10:51 AM, Alvaro Uria 
wrote:

> Hi,
>
> There are 3 charms in the charmstore that would require to be promulgated:
>
> cs:~prometheus-charmers/grafana
> cs:~prometheus-charmers/prometheus-openstack-exporter
> cs:~prometheus-charmers/prometheus-ceph-exporter
>
> Please let me know if you would need any more detail or if it would be
> required to email this request any time we push updates to the mentioned
> charms.
>
> OTOH, I'm running the charm snap (2.2.3) and I think this bug still
> applies (ERROR unrecognized command: charm promulgate)
> https://github.com/juju/charm-tools/issues/310
>
> Kind regards,
> -Alvaro.
>
> --
> Alvaro Uría
> Cloud Reliability Engineer - BootStack
> Canonical, Ltd
>
> --
> 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: Statistics and metrics about Charm, layer and interface usage

[Cory Johns]

I meant to follow up with this last week but lost track.  In addition to
the raw API for getting charm content, you can also just do `charm pull
$CHARM_ID` to get the archive zip, in case that's easier.

For charm stats, the API docs that Rick linked to includes the "stats"
endpoint. You can see some example usage of that in
https://github.com/juju-solutions/k8s-kpi-scripts/blob/master/src/files/thirdparty/k8s-charm-cs-stats

For layer and interfaces, you can use the GitHub API to query how many
layers and interfaces are available (ex.
https://github.com/juju-solutions/charmbuild-kpi-import/blob/master/scripts/github)
but unfortunately there's no easy way at this time to tell how many charms
a given layer is used in.

On Fri, Jan 26, 2018 at 3:25 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Awesome! Thanks guys!
>
> 2018-01-25 17:38 GMT+01:00 Rick Harding :
>
>> https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the
>> docs for the API to the charmstore itself. As Adam notes, you can pull down
>> any file and there's manifest call that lists out the files in the charm.
>> From there you could probably check if the charm has a layers.yaml and if
>> so fetch that file, parse it, etc.
>>
>> https://github.com/juju/charmstore/blob/v5-unstable/docs/
>> API.md#get-idmetamanifest
>>
>> On Thu, Jan 25, 2018 at 11:22 AM Adam Collard 
>> wrote:
>>
>>> Hi Merlijn,
>>>
>>>
>>> On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
 Hi all


 I'm writing a Juju-related paper and I'd like to get statistics
 on Charm, layer and interface usage. Are these publicly available?

 Related: is there a documented API to get the code of the charms that
 are available in the charm store?

>>>
>>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/
>>> will give you a .zip
>>> and
>>>
>>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/arch
>>> ive/$PATH/$TO/$FILE
>>> will give you the 'raw' contents.
>>>
>>> e.g. curl https://api.jujucharms.com/charmstore/v5/postgresql/archive/
>>> hooks/install
>>>
>>> YMMV,
>>>
>>> Adam
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Statistics and metrics about Charm, layer and interface usage

[Cory Johns]

I meant to follow up with this last week but lost track.  In addition to
the raw API for getting charm content, you can also just do `charm pull
$CHARM_ID` to get the archive zip, in case that's easier.

For charm stats, the API docs that Rick linked to includes the "stats"
endpoint. You can see some example usage of that in
https://github.com/juju-solutions/k8s-kpi-scripts/blob/master/src/files/thirdparty/k8s-charm-cs-stats

For layer and interfaces, you can use the GitHub API to query how many
layers and interfaces are available (ex.
https://github.com/juju-solutions/charmbuild-kpi-import/blob/master/scripts/github)
but unfortunately there's no easy way at this time to tell how many charms
a given layer is used in.

On Fri, Jan 26, 2018 at 3:25 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Awesome! Thanks guys!
>
> 2018-01-25 17:38 GMT+01:00 Rick Harding :
>
>> https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the
>> docs for the API to the charmstore itself. As Adam notes, you can pull down
>> any file and there's manifest call that lists out the files in the charm.
>> From there you could probably check if the charm has a layers.yaml and if
>> so fetch that file, parse it, etc.
>>
>> https://github.com/juju/charmstore/blob/v5-unstable/docs/
>> API.md#get-idmetamanifest
>>
>> On Thu, Jan 25, 2018 at 11:22 AM Adam Collard 
>> wrote:
>>
>>> Hi Merlijn,
>>>
>>>
>>> On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
 Hi all


 I'm writing a Juju-related paper and I'd like to get statistics
 on Charm, layer and interface usage. Are these publicly available?

 Related: is there a documented API to get the code of the charms that
 are available in the charm store?

>>>
>>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/
>>> will give you a .zip
>>> and
>>>
>>> GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/arch
>>> ive/$PATH/$TO/$FILE
>>> will give you the 'raw' contents.
>>>
>>> e.g. curl https://api.jujucharms.com/charmstore/v5/postgresql/archive/
>>> hooks/install
>>>
>>> YMMV,
>>>
>>> Adam
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

charms.reactive 0.6.0

[Cory Johns]

Greetings,

Today we released version 0.6.0 of charms.reactive.  The full changelog can
be found at https://charmsreactive.readthedocs.io/en/latest/changelog.html
with the changes from this release being:

* Endpoint base for easier interface layers (#123)
* Public API is now only documented via the top level charms.reactive
namespace. The internal organization of the library is not part of the
public API.
* Added layer-basic docs (#144)
* Fix test error from juju-wait snap (#143)
* More doc fixes (#140)
* Update help output in charms.reactive.sh (#136)
* Multiple docs fixes (#134)
* Fix import in triggers.rst (#133)
* Update README (#132)
* Fixed test, order doesn’t matter (#131)
* Added FAQ section to docs (#129)
* Deprecations:
  * relation_from_name (renamed to endpoint_from_name)
  * relation_from_flag (renamed to endpoint_from_flag)
  * RelationBase.from_state (use endpoint_from_flag instead)

Information about the Endpoint pattern can be found at
https://charmsreactive.readthedocs.io/en/latest/charms.reactive.relations.html#charms.reactive.endpoints.Endpoint
and a tutorial for writing interface layers using this pattern is
forthcoming.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Submission of sme-1 for charm store

[Cory Johns]

Steven,

Apologies for the difficulties, but we have gotten the permissions all
sorted out.  The charm is now promulgated and can be accessed at
https://jujucharms.com/sme/ or via cs:sme on the command line.

On Thu, Dec 7, 2017 at 3:07 PM, Steven Sweeting <ste...@storagemadeeasy.com>
wrote:

> Hi Cory,
>
>
>
> Could the problem be that I don’t have write permission for
> ~storage-made-easy/xenial/sme-0 to disable the “stable” channel?
>
>
>
> The grant for sme-1 is returning successfully. In addition to
> /snap/bin/charm (v2.2.2) I also tried /usr/bin/charm (v2.1.1-0-ubuntu1)
>
>
>
> $ charm show ~storage-made-easy/xenial/sme-1
>
> Storage Made Easy File Fabric for enterprise file sync and share
>
>
>
> Namesme
>
> Owner  storage-made-easy
>
> Revision   1
>
> Supported Series xenial
>
> Tags   applications
>
> Subordinate   false
>
> Promulgated  false
>
> Home page https://storagemadeeasy.com
>
> Bugs urlhttps://storagemadeeasy.com/
> contacts/
>
> Read  storage-made-easy, everyone
>
> Write storage-made-easy, charmers,
> ssweeting
>
>
>
> CHANNELCURRENT
>
> beta   true
>
>
>
> $ charm release ~storage-made-easy/xenial/sme-1 --channel stable
>
> ERROR cannot release charm or bundle: access denied for user "ssweeting"
>
>
>
> Thanks,
>
> Steven
>
>
>
> [image:
> ttps://ci3.googleusercontent.com/proxy/nSxujEAVw9X420WUHPIBYcRjA22BecHwnLB0qX-2xlC8H9FM3et5uNacTODnhnMDf]
>
> *Steven Sweeting*. Director, Product Management
> Storage Made Easy <https://storagemadeeasy.com/> | Twitter: Storage Made
> Easy <http://twitter.com/smestorage> | +1 510.213.0965 <(510)%20213-0965>
> Email: Steven Sweeting <ste...@storagemadeeasy.com.com> | Blog:
> blog.storagemadeeasy.com | Skype
>
>
> The information in this e-mail and any files transmitted with it are
> confidential and are intended solely for the use of the addressee. Access
> to this e-mail by anyone else is unauthorized. If you are not the intended
> recipient any disclosure, copying and distribution of the information
> contained in this e-mail is prohibited. Although this e-mail has been
> checked for all known viruses, Vehera LTD cannot accept responsibility for
> any loss or damage arising from the use of this e-mail or its attachments.
> We keep personal data to be able to communicate with you. This can  include
> your name, email address, contact number, and may document the nature of
> any interactions we have had. If you wish to, unsubscribe
> <unsubscr...@smestorage.com?subject=%20Unsubscribe%20me> from further
> emails from Storage Made Easy. Please be aware that unsubscribing may
> generate a further email acknowledging your removal. Vehera Limited is a
> company registered in England. Registered Number: 07079346. The Registered
> address is Mulgrave Chambers, 26-28 Mulgrave Road,
> <https://maps.google.com/?q=26-28+Mulgrave+Road,%C2%A0Sutton,+Surrey+SM2+6LE=gmail=g>
>  Sutton, Surrey SM2 6LE
> <https://maps.google.com/?q=26-28+Mulgrave+Road,%C2%A0Sutton,+Surrey+SM2+6LE=gmail=g>
> .
>
>
>
> *From: *Cory Johns <cory.jo...@canonical.com>
> *Date: *Thursday, December 7, 2017 at 7:50 AM
> *To: *Steven Sweeting <ste...@storagemadeeasy.com>
> *Cc: *juju <juju@lists.ubuntu.com>, Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com>
> *Subject: *Re: Submission of sme-1 for charm store
>
>
>
> Steven,
>
>
>
> I can see ~storage-made-easy/xenial/sme-1 but
> not ~storage-made-easy/xenial/sme-0.  Can you try granting perms to the
> charmers admin group:
>
>
>
> charm grant ~storage-made-easy/xenial/sme-1 --acl write charmers
>
>
>
> On Thu, Dec 7, 2017 at 10:39 AM, Steven Sweeting <
> ste...@storagemadeeasy.com> wrote:
>
> Hi Cory,
>
>
>
> Thanks for taking a look.  I’m still getting the same error.
>
>
>
> $ charm release ~storage-made-easy/xenial/sme-0 --channel stable
>
> ERROR cannot release charm or bundle: access denied for user "ssweeting"
>
>
>
> Not sure if it’s related but I had previously done a charm revoke read to
> everyone for sme-0 as I’d already pushed sme-1.  Though now sme-1 is
> showing up as sme-0.
>
>
>
> Thanks,
>
> Steven
>
>
>
> From: Cory Johns <cory.jo...@canonical.com>
>
> To: juju <juju@lists.ubuntu.com>
>
> Subject: Re: Submission of sme-1 for charm store
>
> Message-ID:
>
> 

Re: Submission of sme-1 for charm store

[Cory Johns]

Steven,

I can see ~storage-made-easy/xenial/sme-1 but
not ~storage-made-easy/xenial/sme-0.  Can you try granting perms to the
charmers admin group:

charm grant ~storage-made-easy/xenial/sme-1 --acl write charmers

On Thu, Dec 7, 2017 at 10:39 AM, Steven Sweeting <ste...@storagemadeeasy.com
> wrote:

> Hi Cory,
>
>
>
> Thanks for taking a look.  I’m still getting the same error.
>
>
>
> $ charm release ~storage-made-easy/xenial/sme-0 --channel stable
>
> ERROR cannot release charm or bundle: access denied for user "ssweeting"
>
>
>
> Not sure if it’s related but I had previously done a charm revoke read to
> everyone for sme-0 as I’d already pushed sme-1.  Though now sme-1 is
> showing up as sme-0.
>
>
>
> Thanks,
>
> Steven
>
>
>
> From: Cory Johns <cory.jo...@canonical.com>
>
> To: juju <juju@lists.ubuntu.com>
>
> Subject: Re: Submission of sme-1 for charm store
>
> Message-ID:
>
> 

Re: Submission of sme-1 for charm store

[Cory Johns]

Steven,

I've unpromulgated the charm which I think may give you access to release
it to stable within the ~storage-made-easy namespace.  Can you please try
that again and let me know if it works?  If so, I should be able to
re-promulgate afterward and grant you access again.

On Tue, Dec 5, 2017 at 12:33 PM, Steven Sweeting  wrote:

> Hi Tim,
>
>
>
> I can publish to the edge channel but not to stable - I’m getting
> permission denied.
>
> $ charm release ~storage-made-easy/xenial/sme-0 --channel edge
>
> url: cs:~storage-made-easy/xenial/sme-0
>
> channel: edge
>
> $ charm release ~storage-made-easy/xenial/sme-0 --channel stable
>
> ERROR cannot release charm or bundle: access denied for user "ssweeting"
>
>
>
> $ charm version
>
> charm 2.2.2
>
> charm-tools 2.2.3
>
>
>
> Thanks,
>
> Steven
>
>
>
> [image:
> ttps://ci3.googleusercontent.com/proxy/nSxujEAVw9X420WUHPIBYcRjA22BecHwnLB0qX-2xlC8H9FM3et5uNacTODnhnMDf]
>
> *Steven Sweeting*. Director, Product Management
> Storage Made Easy  | Twitter: Storage Made
> Easy  | +1 510.213.0965 <(510)%20213-0965>
> Email: Steven Sweeting  | Blog:
> blog.storagemadeeasy.com | Skype
>
>
> The information in this e-mail and any files transmitted with it are
> confidential and are intended solely for the use of the addressee. Access
> to this e-mail by anyone else is unauthorized. If you are not the intended
> recipient any disclosure, copying and distribution of the information
> contained in this e-mail is prohibited. Although this e-mail has been
> checked for all known viruses, Vehera LTD cannot accept responsibility for
> any loss or damage arising from the use of this e-mail or its attachments.
> We keep personal data to be able to communicate with you. This can  include
> your name, email address, contact number, and may document the nature of
> any interactions we have had. If you wish to, unsubscribe
>  from further
> emails from Storage Made Easy. Please be aware that unsubscribing may
> generate a further email acknowledging your removal. Vehera Limited is a
> company registered in England. Registered Number: 07079346. The Registered
> address is Mulgrave Chambers, 26-28 Mulgrave Road, Sutton, Surrey SM2 6LE.
>
>
>
> *From: *Tim Van Steenburgh 
> *Date: *Tuesday, December 5, 2017 at 7:16 AM
> *To: *Steven Sweeting 
> *Cc: *juju 
> *Subject: *Re: Submission of sme-1 for charm store
>
>
>
> Hi Steven,
>
>
>
> Sure, can you `charm publish` your charm please (it's not currently in the
> the stable channel). See `charm publish -h` for more info.
>
>
>
> Thanks,
>
> Tim
>
>
>
> On Mon, Dec 4, 2017 at 6:59 PM, Steven Sweeting <
> ste...@storagemadeeasy.com> wrote:
>
> Hi,
>
>
>
> I’d like to respectively request that our new charm sme be considered for
> promulgation to the charm store.
>
>
>
> https://jujucharms.com/u/storage-made-easy/sme/xenial/1
>
>
>
> Thanks,
>
> Steven
>
>
>
> [image: Image removed by sender.
> ttps://ci3.googleusercontent.com/proxy/nSxujEAVw9X420WUHPIBYcRjA22BecHwnLB0qX-2xlC8H9FM3et5uNacTODnhnMDf]
>
> *Steven Sweeting*. Director, Product Management
> Storage Made Easy  | Twitter: Storage Made
> Easy  | +1 510.213.0965 <(510)%20213-0965>
> Email: Steven Sweeting  | Blog:
> blog.storagemadeeasy.com | Skype
>
>
> The information in this e-mail and any files transmitted with it are
> confidential and are intended solely for the use of the addressee. Access
> to this e-mail by anyone else is unauthorized. If you are not the intended
> recipient any disclosure, copying and distribution of the information
> contained in this e-mail is prohibited. Although this e-mail has been
> checked for all known viruses, Vehera LTD cannot accept responsibility for
> any loss or damage arising from the use of this e-mail or its attachments.
> We keep personal data to be able to communicate with you. This can  include
> your name, email address, contact number, and may document the nature of
> any interactions we have had. If you wish to, unsubscribe
>  from further
> emails from Storage Made Easy. Please be aware that unsubscribing may
> generate a further email acknowledging your removal. Vehera Limited is a
> company registered in England. Registered Number: 07079346. The Registered
> address is Mulgrave Chambers, 26-28 Mulgrave Road, Sutton, Surrey SM2 6LE.
>
>
>
>
> --
> 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 

Re: Debug logs

[Cory Johns]

It seems that the default logging level for models was reduced some time
back.  This makes the logs much less noisy and saves quite a bit of space,
but it has the unfortunate side effect of making debugging charm failures
from logs more difficult, as most failure messages only show up as stderr
output.  It would probably be worth adding explicit logging of uncaught
exceptions to the reactive framework so that they are clearly visible in
the logs.

I've opened this as an issue against reactive here:
https://github.com/juju-solutions/charms.reactive/issues/147

On Sun, Nov 26, 2017 at 2:47 PM, Tim Penhey 
wrote:

> What is the logging level for the model?
>
> The output from the hooks are logged at debug level.
>
> Tim
>
> On 26/11/17 13:25, Tom Barber wrote:
> > Maybe its just me, I dunno.
> >
> > Has the amount of detail in debug-logs decreased?
> >
> > I'm  not seeing failure causes for example:
> >
> > 2017-11-26 00:11:18 INFO juju.worker.uniter resolver.go:104 found queued
> > "install" hook
> > 2017-11-26 00:12:26 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> > 2017-11-26 00:12:26 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:12:31 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:12:32 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> > 2017-11-26 00:12:32 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:12:42 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:12:43 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> > 2017-11-26 00:12:43 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:13:03 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:13:05 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> > 2017-11-26 00:13:05 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:13:43 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:13:44 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> > 2017-11-26 00:13:44 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:15:01 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:15:02 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> > 2017-11-26 00:15:02 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:17:39 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:17:40 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> > 2017-11-26 00:17:40 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:21:42 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:22:40 INFO juju.worker.uniter resolver.go:100 awaiting
> > error resolution for "install" hook
> > 2017-11-26 00:22:41 ERROR juju.worker.uniter.operation runhook.go:107
> > hook "install" failed: exit status 1
> >
> >
> >
> >
> > Spicule Limited is registered in England & Wales. Company Number:
> > 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
> > Road, Brighton, England, BN1 6AF. VAT No. 251478891.
> >
> >
> > All engagements are subject to Spicule Terms and Conditions of Business.
> > This email and its contents are intended solely for the individual to
> > whom it is addressed and may contain information that is confidential,
> > privileged or otherwise protected from disclosure, distributing or
> > copying. Any views or opinions presented in this email are solely those
> > of the author and do not necessarily represent those of Spicule Limited.
> > The company accepts no liability for any damage caused by any virus
> > transmitted by this email. If you have received this message in error,
> > please notify us immediately by reply email before deleting it from your
> > system. Service of legal notice cannot be effected on Spicule Limited by
> > email.
> >
> >
> >
>
> --
> 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: Is there a universal interface I can use?

[Cory Johns]

You can use the "juju-info" interface type for subordinates, but I'm not
sure that this is the correct thing for your case.

You're trying to attach the non-subordinate "database" endpoint (of
interface protocol "juju-info") on your charm to the "database" endpoint
(of interface protocol "cassandra") on the cassandra charm.  Because the
interface protocols don't match, Juju will not establish the relation.
Additionally, because you're not connecting to the subordinate endpoint
(scope: container) and instead to the standard endpoint, even if the
relation was established, you would never see an instance of your charm
created because it has no host application.

All charms have an implicit relation endpoint called "juju-info" of
interface protocol "juju-info" that you can connect to, and as long as the
interface protocol match and are unambiguous, you can omit them.  To
connect your charm using the "juju-info" interface protocol, you would need
to only define the "host-system" endpoint in your charm (as you currently
have it), leave off the "database" endpoint, and omit the endpoint portion
when adding the relation (or, if you want to be explicit about that, you
can use "juju add-relation cassandra-backup:host-system
cassandra:juju-info").  Then, for the reactive portion, you would use
"@when('host-system.available')" as the decorator.

However, I see that you also want to retrieve relation data that the
cassandra charm provides using the "cassandra" interface protocol.  Here it
becomes important to note that whether a relation is subordinate or not is
independent of the interface protocol the relation uses.  Thus, you could
mark the endpoint as "scope: container" and still use the "cassandra"
interface protocol.  You would then want to drop the "host-system" endpoint
from your charm, mark the "database" endpoint as "interface: cassandra",
and connect as you were trying to do.  However, I seem to recall that
Stuart (the maintainer of the cassandra charm) raised a possible issue with
subordinates using relations that the other end doesn't expect to be
subordinate, so there might be some concerns there.  I can't recall exactly
what the issue was, and I can't seem to find the bug report now.  Perhaps
Stuart can chime in.

A final concern is that I don't see an interface layer for the "cassandra"
interface protocol in the layer index (
https://github.com/juju/layer-index#list-of-interface-layers), meaning it
will be more difficult to use in a reactive charm.  Without the interface
layer, you wouldn't get the flags set to react to and would need to
manually inspect the relation data using charmhelpers.core.hookenv.  It
looks like your use case is fairly simple, though, so we can probably get a
very basic interface layer for it put together pretty quickly that Stuart
could then expand upon.  I'm happy to help with that, but with the holidays
in the US, I might be a few days before I can do so.

On Wed, Nov 22, 2017 at 10:02 AM, Tilman Baumann <
tilman.baum...@canonical.com> wrote:

> I'm writing a reactive subordinate charm for cassandra.
> I can not find a interface for cassandra. But that's ok, since I don't
> really need a full blown database connection client.
>
> Easy I thought and just re-used the juju-info interface for fun and profit.
> requires:
>   host-system:
> interface: juju-info
> scope: container
>   database:
> interface: juju-info
>
> And in the code
> @when('database.available')
> def db_changed(cassandra):
> for conv in cassandra.conversations():
> username = conv.get_remote('username')
> password = conv.get_remote('password')
> ...
>
> However, that doesn't seem to work. Juju complains the relation doesn't
> exist.
> $ juju add-relation cassandra-backup:database cassandra:database
> ERROR no relations found
>
> So, is there a interface that I can (ab-)use in a similar way?
>
> I don't  want to build a full blown cassandra interface and at it to the
> list.
>
> Cheers and thanks
>  Tilman
>
> --
> 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: Charm Tools distribution channels and versions

[Cory Johns]

I was also confused by this, as there seems to have been a shift away from
maintaining the version since we moved to the snap.

Marco, I believe you were in charge of managing the versioning of
charm-tools prior to the snap being the preferred deployment.  Any
clarification here?  We should get this back in line.  Also, the snap's
"charm version" command should probably report the snap's revision in
addition to the charm-tools version like the "snap info" output shows.

On Tue, Oct 3, 2017 at 3:04 PM, Sandor Zeestraten 
wrote:

> Hey folks,
>
> I'm having a bit of a hard time figuring out which distribution of
> charm-tools I can/should use and how they are versioned in order to keep
> track of bugfixes.
>
> As far as I understand, the snaps are preferred over the packages in the
> Juju PPA and PyPI falls somewhere in between?
>
> The snap channels all refer to 2.2 which makes it a bit difficult to tell
> which are which (see below), yet they all display charm 2.2.2 and
> charm-tools 2.1.2 when running "charm version". I'm sure I'm missing
> something obvious but how do I keep track of what is in each snap build?
>
> Finally, we're using bundletester for running tests which pulls inn
> charm-tools from PyPI which seems to have 2.2.0 as the latest version. Does
> PyPI still get new charm-tools releases? If not, what's the recommended
> workflow for those running bundletester?
>
> P.S. The page on PyPI still refers to installing charm-tools from the Juju
> PPA which probably should be fixed.
>
>
> $ snap info charm
> name:  charm
> summary:   "charm and charm-tools"
> publisher: charms
> contact:   juju@lists.ubuntu.com
> description: |
>   charmstore-client and charm-tools
> snap-id: 2Rryoc2ylScfbFl4eQtpntHD9iuZuMvt
> commands:
>   - charm
> tracking:stable
> installed:   2.2 (17) 102MB -
> refreshed:   2017-07-31 18:40:23 + UTC
> channels:
>   stable:2.2 (17) 102MB -
>   candidate: 2.2 (23) 102MB -
>   beta:  ↑
>   edge:  2.2 (37) 102MB -
>
>
> Regards
> --
> Sandor Zeestraten
>
>
> --
> 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

charms.reactive 0.5.0

[Cory Johns]

Greetings,

Today we released version 0.5.0 of charms.reactive.  The full changelog can
be found at https://charmsreactive.readthedocs.io/en/latest/changelog.html
with the changes from this release being:

  * Add flag triggers (#121)
  * Add integration test to Travis to build and deploy a reactive charm
(#120)
  * Only execute matching hooks in restricted context. (#119)
  * Rename "state" to "flag" and deprecate "state" name (#112)
  * Allow pluggable alternatives to RelationBase (#111)

We will be exclusively using the "flags" terminology going forward in place
of "states" as the former is more accurate to what they represent and how
they behave and is less confusing.  For the time being, all of the existing
"state" functions are still available, but they are deprecated.  See
https://charmsreactive.readthedocs.io/en/latest/charms.reactive.flags.html
for more info.

The "pluggable alternatives to RelationBase" is groundwork for the upcoming
Endpoints replacement, which should make writing interface layers
significantly less confusing.  Feedback welcome on
https://github.com/juju-solutions/charms.reactive/pull/123 and
https://github.com/juju/docs/pull/2207
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Bug-fix release for python-libjuju

[Cory Johns]

The 0.6.1 update of the Python bindings for the Juju API has been released
to PyPI.  You can see the full changelog at
https://pythonlibjuju.readthedocs.io/en/latest/#change-log

This release contains the following updates:

0.6.1
---
Fri Sept 29 2017

* Fix failure when controller supports newer facade version (#145)
* Fix test failures (#163)
* Fix SSH key handling when adding a new model (#161)
* Make Application.upgrade_charm upgrade resources (#158)
* Expand integration tests to use stable/edge versions of juju (#155)
* Move docs to ReadTheDocs (https://pythonlibjuju.readthedocs.io/en/latest/)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layer index now on GitHub

[Cory Johns]

Keep in mind that the charm-build update is really more housekeeping to
allow us to retire the old interfaces.juju.solutions domain entirely.  All
charm builds should now be using the new repo.  But of course testing of
that change is more than welcome.

On Fri, Sep 8, 2017 at 3:00 PM, Marco Ceppi <marco.ce...@canonical.com>
wrote:

> This seems to have landed in candidate already, for those wanting to test
> on something other than edge.
>
> sudo snap refresh charm --channel candidate
>
> On Fri, Sep 8, 2017 at 2:59 PM Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> Fantastic, this is a great change - well done!
>>
>> On Fri, Sep 8, 2017 at 2:39 PM, Cory Johns <cory.jo...@canonical.com>
>> wrote:
>>
>>> Greetings,
>>>
>>> Today we migrated the index of base and interface layers used to build
>>> charms over to the GitHub repository https://github.com/juju/layer-index.
>>> Hosting the index in GitHub provides better discoverability for layers, a
>>> better workflow for contributing layers, including more accountability for
>>> changes, and both more flexibility and more visibility with community
>>> contributions.  It also reduces our maintenance overhead and removes a
>>> point of failure.
>>>
>>> The change should be seamless to the build process, and the existing
>>> http://interfaces.juju.solutions/ site now redirects to the new repo.
>>> An updated charm-build command is now in the edge channel which points
>>> directly to the new index, and the old site will eventually be taken down
>>> once that reaches the stable channel and some time has passed.
>>>
>>> I’m now happy to say, PRs welcome!
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>> mailman/listinfo/juju-dev
>>>
>>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layer index now on GitHub

[Cory Johns]

Keep in mind that the charm-build update is really more housekeeping to
allow us to retire the old interfaces.juju.solutions domain entirely.  All
charm builds should now be using the new repo.  But of course testing of
that change is more than welcome.

On Fri, Sep 8, 2017 at 3:00 PM, Marco Ceppi <marco.ce...@canonical.com>
wrote:

> This seems to have landed in candidate already, for those wanting to test
> on something other than edge.
>
> sudo snap refresh charm --channel candidate
>
> On Fri, Sep 8, 2017 at 2:59 PM Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> Fantastic, this is a great change - well done!
>>
>> On Fri, Sep 8, 2017 at 2:39 PM, Cory Johns <cory.jo...@canonical.com>
>> wrote:
>>
>>> Greetings,
>>>
>>> Today we migrated the index of base and interface layers used to build
>>> charms over to the GitHub repository https://github.com/juju/layer-index.
>>> Hosting the index in GitHub provides better discoverability for layers, a
>>> better workflow for contributing layers, including more accountability for
>>> changes, and both more flexibility and more visibility with community
>>> contributions.  It also reduces our maintenance overhead and removes a
>>> point of failure.
>>>
>>> The change should be seamless to the build process, and the existing
>>> http://interfaces.juju.solutions/ site now redirects to the new repo.
>>> An updated charm-build command is now in the edge channel which points
>>> directly to the new index, and the old site will eventually be taken down
>>> once that reaches the stable channel and some time has passed.
>>>
>>> I’m now happy to say, PRs welcome!
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>> mailman/listinfo/juju-dev
>>>
>>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Charm snap is now strictly confined

[Cory Johns]

Greetings,

I just wanted to make a quick announcement that the charm snap is now
strictly confined on the stable channel (rev 17).  This fixes issues like
https://github.com/juju/charm-tools/issues/339 and
https://github.com/juju/charm-tools/issues/319 and prevents similar issues
from cropping up in the future.

In general, this change should be pretty much transparent, with the one
caveat being that you can only build charms from under your HOME directory.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Charm snap is now strictly confined

[Cory Johns]

Greetings,

I just wanted to make a quick announcement that the charm snap is now
strictly confined on the stable channel (rev 17).  This fixes issues like
https://github.com/juju/charm-tools/issues/339 and
https://github.com/juju/charm-tools/issues/319 and prevents similar issues
from cropping up in the future.

In general, this change should be pretty much transparent, with the one
caveat being that you can only build charms from under your HOME directory.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Charm layer index now on GitHub

[Cory Johns]

Greetings,

Today we migrated the index of base and interface layers used to build
charms over to the GitHub repository https://github.com/juju/layer-index.
Hosting the index in GitHub provides better discoverability for layers, a
better workflow for contributing layers, including more accountability for
changes, and both more flexibility and more visibility with community
contributions.  It also reduces our maintenance overhead and removes a
point of failure.

The change should be seamless to the build process, and the existing
http://interfaces.juju.solutions/ site now redirects to the new repo.  An
updated charm-build command is now in the edge channel which points
directly to the new index, and the old site will eventually be taken down
once that reaches the stable channel and some time has passed.

I’m now happy to say, PRs welcome!
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Charm layer index now on GitHub

[Cory Johns]

Greetings,

Today we migrated the index of base and interface layers used to build
charms over to the GitHub repository https://github.com/juju/layer-index.
Hosting the index in GitHub provides better discoverability for layers, a
better workflow for contributing layers, including more accountability for
changes, and both more flexibility and more visibility with community
contributions.  It also reduces our maintenance overhead and removes a
point of failure.

The change should be seamless to the build process, and the existing
http://interfaces.juju.solutions/ site now redirects to the new repo.  An
updated charm-build command is now in the edge channel which points
directly to the new index, and the old site will eventually be taken down
once that reaches the stable channel and some time has passed.

I’m now happy to say, PRs welcome!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How do upgrades handle resources?

[Cory Johns]

Merlijn,

I agree that the documentation around that could be clearer.  The way that
it works is that, just like charms, resources have revisions, and both are
specified when releasing a charm to a channel.  Then, `juju upgrade-charm`
will update both to the current version for the channel you're using, and
the charm's upgrade-charm hook will get fired if either had changed.

So, in more detail, let's say you push a charm to the store that specifies
resources in its metadata.yaml.  You then cannot release that charm
revision to any channel without specifying which resource revision to use
for every resource specified in the charm's metadata.yaml.

To get a resource revision, you have to upload the resource file to the
store using `charm attach`.  The messages you get from charm-attach can be
a bit confusing, though, because you have to specify a revision or channel
of the charm when attaching a resource, but that channel or revision are
ignored as far as I can tell.  You can also specify a resource file when
pushing a new charm revision using the --resource option for `charm push`.

Note that, because you can't release a charm rev to a channel without
providing a resource rev, all charms are required to have *some* file in
the store for the resource, even if it's an empty file.  This decision was
made to ensure that charms using resources could always be deployed from
the store and that using a placeholder resource would have to be a
conscious decision and not an accidental one.

Once you have a resource revision as well as a charm revision, you can
release both to a channel with, e.g., `charm release --channel=edge
cs:~johnsca/test-1 --resource foo-0`.  Then, anyone who deploys or upgrades
to that charm rev will also get the foo-0 resource.  If you decide that you
need to update the resource without updating the charm code, you can use
`charm attach` again to get a foo-1 resource, and then release to edge with
the same charm rev but the new resource rev (`charm release --channel=edge
cs:~johnsca/test-1 --resource foo-1`), or vice-versa to update just the
charm code and keep the same resource.

If the juju admin uses `juju attach` (or `juju deploy --resource`) to
provide a local file to use as the resource, it will of course bypass
whatever's specified in the store and will always trigger the upgrade-charm
hook with the new resource.


On Fri, Jul 28, 2017 at 10:34 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> I'm not sure how resources and upgrades work together. I see that the
> kubernetes layers use resources, but you upgrade kubernetes using `juju
> upgrade-charm`. How does that work? Does each charm version have a "default
> resource" attached?
>
> The resources docs don't really explain this either.. https://jujucharms.
> com/docs/2.1/developer-resources
>
>
>
> Kind regards
> Merlijn
>
> --
> 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: Is a set state called multiple times?

[Cory Johns]

fengxia,

It's probably more enlightening to think of them as "flags" rather than
states.  (Indeed, the next release of charms.reactive will deprecate
calling them states and will provide set_flag, remove_flag, etc. functions
instead.)

On Thu, Jul 27, 2017 at 3:29 PM, fengxia  wrote:

> Alex,
>
> Thank you for the detailed explanations and examples.
>
> After reading Tilman's and Cory's replies, I think the confusion is at
> continuous evaluation (thus execution) of a True state. So a pair of @when
> and @when_not will result in one of them being executed over and over
> despite adding a remove_state("myself") in the @when block.
>
> I'm still trying to grasp the idea of this "state" instead of treating it
> as an event handler.
>
> So for states, I usually draw a state machine diagram. In this case, it
> feels rather unnatural that all True states will inherently loop to
> themselves.
>
> But I don't what alternative is in charm's context.
>
> On 07/27/2017 04:13 AM, Alex Kavanagh wrote:
>
> Hi
>
> On Thu, Jul 27, 2017 at 2:37 AM, fengxia  wrote:
>
>> Hi Juju,
>>
>> Once I set a state, set_state("here"), I want to make sure its @when will
>> only be executed ONCE (when "here" from False->True).
>>
>> So my thought is to remove_state("here") in its @when("here") code block.
>> If I don't, will this @when be called multiple times if I don't reset this
>> state? What's the good practice here?
>
>
> You have a couple of options here depending on the nature of the handler.
>
>
>1. If, in the lifetime of the unit's existence, the handler only has
>to execute ONCE.  (and I mean EVER), then there is a @only_once decorator
>that can be used.  It can be used in combination with other decorators to
>set up a condition, but it guarantees that the handler will only be called
>once.  However, what you probably want is ...
>2. Use a @when_not('flag') and then set it the 'flag' in the body of
>the handler.
>
> The first would look something like:
>
> @when('some-condition-flag')
> @only_once
> def do_something_only_once_when_some_condition_flag_is_set_
> for_the_first_time():
>  ... do something once ...
>
> The second treats a flag as a 'have I done this yet' condition, and allows
> you to reset the flag at some other point in the charm's life cycle so that
> you can do it again.  'installed' is a good example of this:
>
> @when_not('installed-something')
> def do_install_of_something():
> ... do the installation ...
> # when it is fully successful, set the installed-something flag.
> Don't set it early as
> # if it errors, a future handler invocation may be able to continue
> the installation.
> set_state('installed-something')
>
>
> @when(some other conditions indicating do an upgrade)
> def do_upgrade():
>  ... set upgrade sources, or other pre upgrade actions
>  remove_state('installed-something')
>
> In this situation, hopefully you can see that we can re-use
> 'do_install_of_something()' when we do upgrades.
>
> I think it's useful to think about states (flags) as being a 'memory' that
> something has happened, and use them to either gate on not doing things
> again, or to trigger the next action is a graph of actions that need to
> take place to get the charm's payload to the desired operational state.  I
> tend to name them, and use them, to indicate when something has happened,
> rather than when it hasn't, and so tend to use @when_not('some-flag') on
> the handler that eventually sets that flag.
>
> Hope that this helps.
> Alex.
>
>>
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794
>> fx...@lenovo.com
>>
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>fx...@lenovo.com
>   
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> 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: Is a set state called multiple times?

[Cory Johns]

On Thu, Jul 27, 2017 at 12:29 PM, Tilman Baumann <
tilman.baum...@canonical.com> wrote:

> Problems with interfaces:
> - *.connected state gets dropped when one  unit leaves. Not when the
> last one leaves.
>

If this is happening, then it's because the particular interface layer is
doing something wrong in how it's setting or removing the state with the
Conversation API.  However, this is made easy to get wrong by the confusing
nature of the Conversations API, which we are working on addressing.


> - self.* only works when code runs in the right hook context
>

The purpose of the Conversations API (self.conversations()) was to address
this so that the handlers wouldn't need to keep track of the specific
relation IDs and unit names that the hook context supplies.  So, if the
interface layer is written correctly within that metaphor, the actual hook
context is irrelevant.  However, we're working on an improved API that
solves the same issue while being more explicit about what it's doing to
reduce the confusion.


> - interface class reference is only passed in decorated functions if the
> hook inside the interface code ran
>

The class reference is passed to any handler decorated with a @when
decorator with a state that was set by an interface layer class using
Conversation.set_state() (or the self.set_state() helper on the interface
class, which is essentially self.conversations()[0].set_state()).  This
will happen regardless of what hook context the charm is currently
executing in.

Part of the API improvements will remove the instances from handler params
and make them available via a global context which will always provide a
consistent way to access them.


> - Only the first occurrence of a unit joining a relation can be caught
> with handler
>

All joining units can be handled by interface layers.  The joined hook will
run for all joining units, and those units will be added to the interface
instance's conversations if the joined state is applied within the the
@hook decorated handler.  Those units can then all be accessed by iterating
over self.conversations() in a interface instance method called from a
@when decorated handler (but not from the @hook decorated handlers in the
interface class; those will only see the one unit :/).

Part of the API improvements for this will be to have some of the flags
(states), such as joined, managed automatically by the framework (which
should remove the need for @hook handlers entirely and also reduce
boilerplate), and then to provide explicit methods for associating specific
units with flags as well as seeing what units are associated with a given
flag.

If you are interested in learning more about how we're looking to improve
charms.reactive and contributing to the discussion, I invite you to take a
look at https://github.com/juju-solutions/charms.reactive/pull/101  That PR
contains documentation for the proposed API changes, and a lot of
discussion hashing out how best those API should look to the user.  In
fact, it might even be a bit too much discussion for a GitHub PR comment
stream to organize well.  :)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Is a set state called multiple times?

[Cory Johns]

It does seem that the current behavior of re-evaluating handlers despite
none of their flags (states) having changed is confusing, particularly for
new users, and we are planning on changing this behavior.  Unfortunately,
there are some charms that have come to rely on the current behavior, so we
will need to provide some mechanism for getting that behavior, at least for
a transition period.  We will also need to provide a mechanism to "force" a
flag to be considered "re-activated" even if that's as basic as requiring
it be removed and then re-added.

On Thu, Jul 27, 2017 at 4:13 AM, Alex Kavanagh 
wrote:

> Hi
>
> On Thu, Jul 27, 2017 at 2:37 AM, fengxia  wrote:
>
>> Hi Juju,
>>
>> Once I set a state, set_state("here"), I want to make sure its @when will
>> only be executed ONCE (when "here" from False->True).
>>
>> So my thought is to remove_state("here") in its @when("here") code block.
>> If I don't, will this @when be called multiple times if I don't reset this
>> state? What's the good practice here?
>
>
> You have a couple of options here depending on the nature of the handler.
>
>
>1. If, in the lifetime of the unit's existence, the handler only has
>to execute ONCE.  (and I mean EVER), then there is a @only_once decorator
>that can be used.  It can be used in combination with other decorators to
>set up a condition, but it guarantees that the handler will only be called
>once.  However, what you probably want is ...
>2. Use a @when_not('flag') and then set it the 'flag' in the body of
>the handler.
>
> The first would look something like:
>
> @when('some-condition-flag')
> @only_once
> def do_something_only_once_when_some_condition_flag_is_set_
> for_the_first_time():
>  ... do something once ...
>
> The second treats a flag as a 'have I done this yet' condition, and allows
> you to reset the flag at some other point in the charm's life cycle so that
> you can do it again.  'installed' is a good example of this:
>
> @when_not('installed-something')
> def do_install_of_something():
> ... do the installation ...
> # when it is fully successful, set the installed-something flag.
> Don't set it early as
> # if it errors, a future handler invocation may be able to continue
> the installation.
> set_state('installed-something')
>
>
> @when(some other conditions indicating do an upgrade)
> def do_upgrade():
>  ... set upgrade sources, or other pre upgrade actions
>  remove_state('installed-something')
>
> In this situation, hopefully you can see that we can re-use
> 'do_install_of_something()' when we do upgrades.
>
> I think it's useful to think about states (flags) as being a 'memory' that
> something has happened, and use them to either gate on not doing things
> again, or to trigger the next action is a graph of actions that need to
> take place to get the charm's payload to the desired operational state.  I
> tend to name them, and use them, to indicate when something has happened,
> rather than when it hasn't, and so tend to use @when_not('some-flag') on
> the handler that eventually sets that flag.
>
> Hope that this helps.
> Alex.
>
>>
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794
>> fx...@lenovo.com
>>
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
> --
> 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

New release of python-libjuju

[Cory Johns]

The 0.6.0 release of the Python bindings for the Juju API is now available
on PyPI.  The docs have moved to ReadTheDocs, due to PythonHosted being
deprecated, and the change log can be found at:
https://pythonlibjuju.readthedocs.io/en/latest/changelog.html

Here is a synopsis of the recent releases:

0.6.0
---
Thu June 29 2017

* Implement scp functionality (#149)
* Add Unit.public_address property (#153)
* Adds support for getting/setting config on a model (#152)

0.5.3
---
Thu June 22 2017

* Improve handling of closed connections (#148)
* Configurable and larger max message size (#146)

0.5.2
---
Wed June 14 2017

* Fix deploying non-stable channels and explicit revs (#144)
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Maximum AllWatcher frame size?

[Cory Johns]

So, I'm not sure if this resolves the issue.  The python websockets library
supports fragmented messages but I think that is separate from the maximum
message size that it's enforcing.  I think that maximum is for the final
payload, which would be the entire AllWatcher JSON response.  If the
controller doesn't break that in to multiple AllWatcher updates, then I
think we'll still hit the maximum message size.

I can increase the max size pretty easily, or even remove it entirely, as
mentioned in the issue, but I'm a little bit leery of having no upper bound
at all.  Do we know if there's a reasonable upper bound that even large
models would fall within for the initial AllWatcher response?

On Wed, Jun 14, 2017 at 12:08 PM, Tim Penhey <tim.pen...@canonical.com>
wrote:

> It is configured in juju
>
>
> // Use a 64k frame size for the websockets while we need to deal
> // with x/net/websocket connections that don't deal with recieving
> // fragmented messages.
> const websocketFrameSize = 65536
>
>
> On 14/06/17 12:00, Cory Johns wrote:
> > Do we know what size the gorilla/websocket library uses for automatic
> > chunking?
> >
> > On Wed, Jun 14, 2017 at 11:35 AM, John Meinel <j...@arbash-meinel.com
> > <mailto:j...@arbash-meinel.com>> wrote:
> >
> > In 2.1 we did not chunk, in 2.2 we switch to gorilla/websocket which
> > does support chunking into frames. I don't think we do any internal
> > "well that would be too much information so we wont send it all".
> >
> > John
> > =:->
> >
> >
> > On Wed, Jun 14, 2017 at 7:11 PM, Cory Johns
> > <cory.jo...@canonical.com <mailto:cory.jo...@canonical.com>> wrote:
> >
> > https://github.com/juju/python-libjuju/issues/136
> > <https://github.com/juju/python-libjuju/issues/136> raises the
> > issue that, for large models, the initial AllWatcher response
> > frame can be large enough that it overruns the default maximum
> > frame size of the websocket library (1MB).  We can increase this
> > limit fairly easily, but I wanted to find out whether there is
> > any maximum size from the Juju size and if large enough frames
> > could get chunked into multiple frames?
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com>
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> > <https://lists.ubuntu.com/mailman/listinfo/juju-dev>
> >
> >
> >
> >
> >
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Maximum AllWatcher frame size?

[Cory Johns]

Do we know what size the gorilla/websocket library uses for automatic
chunking?

On Wed, Jun 14, 2017 at 11:35 AM, John Meinel <j...@arbash-meinel.com>
wrote:

> In 2.1 we did not chunk, in 2.2 we switch to gorilla/websocket which does
> support chunking into frames. I don't think we do any internal "well that
> would be too much information so we wont send it all".
>
> John
> =:->
>
>
> On Wed, Jun 14, 2017 at 7:11 PM, Cory Johns <cory.jo...@canonical.com>
> wrote:
>
>> https://github.com/juju/python-libjuju/issues/136 raises the issue that,
>> for large models, the initial AllWatcher response frame can be large enough
>> that it overruns the default maximum frame size of the websocket library
>> (1MB).  We can increase this limit fairly easily, but I wanted to find out
>> whether there is any maximum size from the Juju size and if large enough
>> frames could get chunked into multiple frames?
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju-dev
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Maximum AllWatcher frame size?

[Cory Johns]

https://github.com/juju/python-libjuju/issues/136 raises the issue that,
for large models, the initial AllWatcher response frame can be large enough
that it overruns the default maximum frame size of the websocket library
(1MB).  We can increase this limit fairly easily, but I wanted to find out
whether there is any maximum size from the Juju size and if large enough
frames could get chunked into multiple frames?
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 2.2-rc2 has been released

[Cory Johns]

Simon,

That was my mistake, I forgot to click release on that.
 conjure-up-rc2-20170612 is now available on the candidate channel.

On Fri, Jun 9, 2017 at 8:06 PM, Simon Kollberg  wrote:

> conjure-up still seem to be on rc1
>
> % sudo snap install conjure-up --classic --candidate
> conjure-up (candidate) 2.2-rc1-20170606.0106 from 'canonical' installed
> % juju --version
> 2.2-rc1-xenial-amd64
> % conjure-up --version
> conjure-up 2.2-rc1
> % sudo snap remove conjure-up
> conjure-up removed
> % sudo snap install juju --classic --candidate
> juju (candidate) 2.2-rc2 from 'canonical' installed
> % juju --version
> 2.2-rc2-xenial-amd64
>
> On 9 June 2017 at 13:25, Chris Lee  wrote:
>
>> # Juju 2.2-rc2 Release Notes
>>
>>
>>
>> We are delighted to announce the release of Juju and conjure-up 2.2-rc2!
>> In this release, Juju greatly improves memory and storage consumption,
>> works on KVM containers, and improves network modelling. conjure-up now
>> supports Juju as a Service (JAAS), provides a MacOS client, and adds
>> support for repeatable spell deployments.
>>
>>
>>
>> The best way to get your hands on this release of Juju and conjure-up is
>> to install them via snap packages (see https://snapcraft.io/ for more
>> info on snaps).
>>
>>
>>
>> snap install juju --classic --candidate
>>
>> snap install conjure-up --classic --candidate
>>
>>
>>
>> Other packages are available for a variety of platforms. Please see the
>> online documentation at https://jujucharms.com/docs/de
>> vel/reference-releases#development
>>
>>
>>
>> Please note that if you are upgrading an existing controller, please make
>> sure there is at least 6G of free disk space. The upgrade step for the logs
>> can take a while, in the vicinity of 10 or more minutes if the current logs
>> collection is at its maximum size.
>>
>>
>>
>> Since 2.2-rc1
>>
>>
>> ## New and Improved
>>
>> --
>>
>>
>>
>> Better support credential management in the Azure provider
>>
>> * support autoload-credentials and juju add-credential in the azure
>> provider when Azure CLI is installed.
>>
>> (this removes the requirement that the user discover their subscription
>> ID before creating credentials)
>>
>>
>>
>> Rate limit login and connection requests to the controller(s) on busy
>> systems.
>>
>>
>>
>> ## Fixes
>>
>> --
>>
>>
>>
>> Fix issue where status history logs were not pruned:
>>
>>   https://bugs.launchpad.net/juju/+bug/1696491
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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: Does relation scopes need to match?

[Cory Johns]

The original intention of conversations and scopes was to simply certain
interface interaction patterns where it may not be relevant or useful on
your end of the relation to deal with each remote unit individually.  An
example might be if the remote service is expected to have a leader which
speaks for all the units (SERVICE scope), or subordinates where you are
guaranteed to only ever have a single remote unit (GLOBAL scope).  When in
doubt, you can always use UNIT scope (which is the default) and treat the
list of conversations as a list of all of the remote units on the relation.

The effect of SERVICE scope is to merge the received data from remote units
on a per-remote-service basis, and the effect of GLOBAL scope is to both
merge received data from all remote units and to send the same data to all
connected relations.  The scope that one end of a relation uses has no
effect on the other end of the relation.

The error that you got seems like you performed an upgrade-charm after
changing the scope of the interface layer.  There is persisted context used
to associate states with individual remote units based on the scope which
does not deal well with such a change.  You will need to redeploy if you
change the scope of a interface layer.

On Wed, Jun 7, 2017 at 9:27 PM, fengxia  wrote:

> Just to clarify my question. I know the official doc of these scopes, that
> data are broadcasted in GLOBAL and UNIT is maintained as 1-to-1. What I'd
> like to know is when we should use GLOBAL, and when to use UNIT? When I
> deploy multiple units of a charm, does it mean its end of relation must use
> UNIT? if so, what about the provide end, should it be UNIT? GLOBAL? SERVICE?
>
>
>
> On 06/07/2017 09:22 PM, fengxia wrote:
>
>> Hi Juju,
>>
>> I'm learning to write a relation. One thing that's puzzling to me is the
>> scope. The question is, must provide and require use the same scope?
>>
>> For experiment, I have a scope.GLOBAL provide and scope.UNIT require. In
>> deployment, there is one provide unit and three require units. In this
>> setup, I was able to call set_remote() from provide side to pass a dict to
>> require side (get_remote()).
>>
>> However, if I change provide to be scope.UNIT also, it generated an error:
>>
>> unit-A-52: 21:15:44 INFO unit.A/52.b-relation-joined ValueError:
>> Conversation with scope 'b/120' not found
>>
>> Could you elaborate what the behavior should be when these scopes
>> selected on either side?
>>
>> | provides | requires |
>> | GLOBAL   | GLOBAL   |
>> | UNIT | UNIT |
>> | GLOBAL   | UNIT |
>>
>>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794
> fx...@lenovo.com
>
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to count relations?

[Cory Johns]

Alex,

I should clarify, conv.scope should only be None if the class's scope is
GLOBAL.  Otherwise, it should be the name of the service or unit.  If the
scope is defined as SERVICE or UNIT and the conv.scope is None, it was a
bug, yes (but let's work to get rid of the confusing idea of scopes and
conversations anyway, instead).

On Wed, Jun 7, 2017 at 12:30 PM, Alex Kavanagh <alex.kavan...@canonical.com>
wrote:

>
>
> On Wed, Jun 7, 2017 at 4:44 PM, Cory Johns <cory.jo...@canonical.com>
> wrote:
>
>> Alex beat me to it, but here's a marginally more complete example:
>> https://gist.github.com/johnsca/a91cb5897d92dfb6741ee1a09d82b39b
>>
>> The key points are:
>>
>> * The interface needs to be UNIT scoped (because you care about
>> individual units)
>> * The joined handler sets a state for each unit that joins
>> * The @when('rel.connected') predicate in the charm layer matches all
>> units that have had that state set, so the set of conversations in the
>> interface layer includes those units, and only those units.  This is
>> trivially all of the units in my example, but you could also set a
>> different state in a -changed handler based on data sent by each remote
>> unit, and the conversations would only include the units that had that
>> specific state set when you matched that state using @when
>>
>> Alex: A conversation will always have a scope, so that list comprehension
>> isn't necessary.
>>
>
> Ah, interesting Cory.  It must have been a bug then; I ran into a
> situation where scope was None and had to filter it out; maybe I can remove
> that check from the interface I wrote (manila-plugin).
>
> Thanks!
> Alex.
>
>
>> On Wed, Jun 7, 2017 at 11:38 AM, Alex Kavanagh <
>> alex.kavan...@canonical.com> wrote:
>>
>>> Hi
>>>
>>> I'm assuming you are using charms.reactive; if not then look into
>>> relation_ids command.
>>>
>>> In your interface, count the number of conversations that have a scope
>>> set to something other than None.  scope shouldn't be None, but I've had
>>> cases where it has been (it may have been a bug):
>>>
>>> So in the provider.py RelationBase derived class, something along the
>>> lines of:
>>>
>>> num = len([c for c in self.conversations() if c.scope])
>>>
>>> in a method would be a relatively simple way of doing it.
>>>
>>> (There may be better ways of doing this!)
>>>
>>> Cheers
>>> Alex.
>>>
>>> On Wed, Jun 7, 2017 at 4:22 PM, fengxia <fx...@lenovo.com> wrote:
>>>
>>>> Hi Juju,
>>>>
>>>> I'm building two charms and linking them with one relation, one charm
>>>> ("A") will provide and the other ("B") will require.
>>>>
>>>> The deployment will have one "A" and three "B"s. How do I know all
>>>> three Bs have joined? I'm thinking to use a counter in A's relation, then
>>>> at relation-joined hook by B to add this counter. But set_remote() and
>>>> set_local() didn't work. Not sure what's the right way to achieve this?
>>>>
>>>>
>>>> --
>>>> Feng xia
>>>> Engineer
>>>> Lenovo USA
>>>>
>>>> Phone: 5088011794
>>>> fx...@lenovo.com
>>>>
>>>> Lenovo.com
>>>> Twitter | Facebook | Instagram | Blogs | Forums
>>>> 9
>>>>
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju@lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju
>>>>
>>>
>>>
>>>
>>> --
>>> Alex Kavanagh - Software Engineer
>>> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to count relations?

[Cory Johns]

Alex beat me to it, but here's a marginally more complete example:
https://gist.github.com/johnsca/a91cb5897d92dfb6741ee1a09d82b39b

The key points are:

* The interface needs to be UNIT scoped (because you care about individual
units)
* The joined handler sets a state for each unit that joins
* The @when('rel.connected') predicate in the charm layer matches all units
that have had that state set, so the set of conversations in the interface
layer includes those units, and only those units.  This is trivially all of
the units in my example, but you could also set a different state in a
-changed handler based on data sent by each remote unit, and the
conversations would only include the units that had that specific state set
when you matched that state using @when

Alex: A conversation will always have a scope, so that list comprehension
isn't necessary.

On Wed, Jun 7, 2017 at 11:38 AM, Alex Kavanagh 
wrote:

> Hi
>
> I'm assuming you are using charms.reactive; if not then look into
> relation_ids command.
>
> In your interface, count the number of conversations that have a scope set
> to something other than None.  scope shouldn't be None, but I've had cases
> where it has been (it may have been a bug):
>
> So in the provider.py RelationBase derived class, something along the
> lines of:
>
> num = len([c for c in self.conversations() if c.scope])
>
> in a method would be a relatively simple way of doing it.
>
> (There may be better ways of doing this!)
>
> Cheers
> Alex.
>
> On Wed, Jun 7, 2017 at 4:22 PM, fengxia  wrote:
>
>> Hi Juju,
>>
>> I'm building two charms and linking them with one relation, one charm
>> ("A") will provide and the other ("B") will require.
>>
>> The deployment will have one "A" and three "B"s. How do I know all three
>> Bs have joined? I'm thinking to use a counter in A's relation, then at
>> relation-joined hook by B to add this counter. But set_remote() and
>> set_local() didn't work. Not sure what's the right way to achieve this?
>>
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794
>> fx...@lenovo.com
>>
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>> 9
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
> --
> 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: Normalizing output dir for charm build

[Cory Johns]

Adam,

I think the name "charms" is up to the user, it's just whatever they have
set $JUJU_REPOSITORY to.  It just so happens that Merlijn sets his to
JUJU_REPOSITORY=~/charms (or similar).

Previously, the build charm would end up in
{$JUJU_REPOSITORY,$PWD}/{builds,trusty,xenial,...}/$charm_name.  The
proposal is to always have it go to $JUJU_REPOSITORY/$charm_name instead.

Additionally, it was the case previously that the layers, interfaces, and
deps directories would default to living under $JUJU_REPOSITORY.  The
proposal is to move deps to always be under ~/.cache/charm-build/deps and
to not have any default for layers or interfaces, such that if $LAYER_PATH
or $INTERFACE_PATH are not set, they will simply be ignored.

All of this with the caveat that $JUJU_REPOSITORY, $LAYER_PATH, and
$INTERFACE_PATH can be provided / overridden on the CLI.

On Thu, May 11, 2017 at 9:34 AM, Adam Israel <adam.isr...@canonical.com>
wrote:

> To confirm: Builds will be replaced by a charms directory, and deps moved
> to ~/.cache/charm-build. If so, I'm +1 to that.
>
> On Thu, May 11, 2017 at 9:28 AM, Cory Johns <cory.jo...@canonical.com>
> wrote:
>
>> Yes, that's what I'm proposing.
>>
>> On Thu, May 11, 2017 at 4:47 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> It seems like deps should go under ~/.cache/charm-build/
>>>
>>>
>>> +1
>>>
>>> Now, to be clear, the structure you propose is something like the
>>> following?
>>>
>>>
>>> ├── charms# $JUJU_REPOSITORY
>>> │   ├── my-charm
>>> │   ├── ...
>>> ├── interfaces# $INTERFACE_PATH
>>> │   ├── ...
>>> ├── layers# $LAYER_PATH
>>> │   ├── ...
>>>
>>>
>>>
>>> 2017-05-10 23:39 GMT+02:00 Cory Johns <cory.jo...@canonical.com>:
>>>
>>>> There are separate env vars for layers and interfaces, and there should
>>>> probably be CLI args as well.  Perhaps instead of being required like the
>>>> output dir, if they're not provided they just aren't used.
>>>>
>>>> It seems like deps should go under ~/.cache/charm-build/
>>>>
>>>> On Wed, May 10, 2017 at 3:36 PM, Merlijn Sebrechts <
>>>> merlijn.sebrec...@gmail.com> wrote:
>>>>
>>>>> * Drop the "builds" portion of the output directory (that was mainly
>>>>>> to distinguish it from the series portion).
>>>>>>
>>>>>
>>>>> We still need to distinguish the charms from `deps` and possibly from
>>>>> `layers` and `interfaces`.
>>>>>
>>>>> This is my $JUJU_REPOSITORY:
>>>>>
>>>>> ├── charms
>>>>> │   ├── builds
>>>>> │   ├── deps
>>>>> │   ├── interfaces
>>>>> │   ├── layers
>>>>>
>>>>>
>>>>> 2017-05-10 20:03 GMT+02:00 Cory Johns <cory.jo...@canonical.com>:
>>>>>
>>>>>> Started on https://github.com/juju/charm-tools/pull/320, I'd like to
>>>>>> bring this discussion to the list.
>>>>>>
>>>>>> The output directory for charm build can vary in seemingly
>>>>>> unpredictable ways depending on how it is called, the environment, and 
>>>>>> the
>>>>>> charm's metadata.yaml contents.  This is due to historical reasons,
>>>>>> primarily with how Juju 1.x worked and how charm paths worked prior to 
>>>>>> the
>>>>>> advent of multi-series charms.  However, now that 2.x and multi-series
>>>>>> support are standard, I would like to push for simplifying the output
>>>>>> directory, based on Merlijn's PR.
>>>>>>
>>>>>> Specifically, I'd like to push for the following changes:
>>>>>>
>>>>>> * Drop the series portion of the output directory (we recommend
>>>>>> providing the series in the charm's metadata, making it redundant in the
>>>>>> path).
>>>>>> * Drop the "builds" portion of the output directory (that was mainly
>>>>>> to distinguish it from the series portion).
>>>>>> * Drop the current directory as a fallback option for the output
>>>>>> directory (it causes more confusion than it saves).
>>>>>>
>>>>>> Thus, charm build would always require an output directory to be
>>>>>> given either via --output-dir (-o) or via the $JUJU_REPOSITORY 
>>>>>> environment
>>>>>> variable, and would always put the built charm in $output_dir/$charm_name
>>>>>>
>>>>>> Obviously, this is not backwards compatible, and may affect automated
>>>>>> build systems, but I think it would be easy to adjust for and simplify
>>>>>> things for everyone concerned.
>>>>>>
>>>>>> Thoughts?  Objections?
>>>>>>
>>>>>> --
>>>>>> Juju mailing list
>>>>>> Juju@lists.ubuntu.com
>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>>>> an/listinfo/juju
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

[Cory Johns]

Yes, that's what I'm proposing.

On Thu, May 11, 2017 at 4:47 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> It seems like deps should go under ~/.cache/charm-build/
>
>
> +1
>
> Now, to be clear, the structure you propose is something like the
> following?
>
>
> ├── charms# $JUJU_REPOSITORY
> │   ├── my-charm
> │   ├── ...
> ├── interfaces# $INTERFACE_PATH
> │   ├── ...
> ├── layers# $LAYER_PATH
> │   ├── ...
>
>
>
> 2017-05-10 23:39 GMT+02:00 Cory Johns <cory.jo...@canonical.com>:
>
>> There are separate env vars for layers and interfaces, and there should
>> probably be CLI args as well.  Perhaps instead of being required like the
>> output dir, if they're not provided they just aren't used.
>>
>> It seems like deps should go under ~/.cache/charm-build/
>>
>> On Wed, May 10, 2017 at 3:36 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> * Drop the "builds" portion of the output directory (that was mainly to
>>>> distinguish it from the series portion).
>>>>
>>>
>>> We still need to distinguish the charms from `deps` and possibly from
>>> `layers` and `interfaces`.
>>>
>>> This is my $JUJU_REPOSITORY:
>>>
>>> ├── charms
>>> │   ├── builds
>>> │   ├── deps
>>> │   ├── interfaces
>>> │   ├── layers
>>>
>>>
>>> 2017-05-10 20:03 GMT+02:00 Cory Johns <cory.jo...@canonical.com>:
>>>
>>>> Started on https://github.com/juju/charm-tools/pull/320, I'd like to
>>>> bring this discussion to the list.
>>>>
>>>> The output directory for charm build can vary in seemingly
>>>> unpredictable ways depending on how it is called, the environment, and the
>>>> charm's metadata.yaml contents.  This is due to historical reasons,
>>>> primarily with how Juju 1.x worked and how charm paths worked prior to the
>>>> advent of multi-series charms.  However, now that 2.x and multi-series
>>>> support are standard, I would like to push for simplifying the output
>>>> directory, based on Merlijn's PR.
>>>>
>>>> Specifically, I'd like to push for the following changes:
>>>>
>>>> * Drop the series portion of the output directory (we recommend
>>>> providing the series in the charm's metadata, making it redundant in the
>>>> path).
>>>> * Drop the "builds" portion of the output directory (that was mainly to
>>>> distinguish it from the series portion).
>>>> * Drop the current directory as a fallback option for the output
>>>> directory (it causes more confusion than it saves).
>>>>
>>>> Thus, charm build would always require an output directory to be given
>>>> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
>>>> variable, and would always put the built charm in $output_dir/$charm_name
>>>>
>>>> Obviously, this is not backwards compatible, and may affect automated
>>>> build systems, but I think it would be easy to adjust for and simplify
>>>> things for everyone concerned.
>>>>
>>>> Thoughts?  Objections?
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju@lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>>> an/listinfo/juju
>>>>
>>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Normalizing output dir for charm build

[Cory Johns]

Started on https://github.com/juju/charm-tools/pull/320, I'd like to bring
this discussion to the list.

The output directory for charm build can vary in seemingly unpredictable
ways depending on how it is called, the environment, and the charm's
metadata.yaml contents.  This is due to historical reasons, primarily with
how Juju 1.x worked and how charm paths worked prior to the advent of
multi-series charms.  However, now that 2.x and multi-series support are
standard, I would like to push for simplifying the output directory, based
on Merlijn's PR.

Specifically, I'd like to push for the following changes:

* Drop the series portion of the output directory (we recommend providing
the series in the charm's metadata, making it redundant in the path).
* Drop the "builds" portion of the output directory (that was mainly to
distinguish it from the series portion).
* Drop the current directory as a fallback option for the output directory
(it causes more confusion than it saves).

Thus, charm build would always require an output directory to be given
either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
variable, and would always put the built charm in $output_dir/$charm_name

Obviously, this is not backwards compatible, and may affect automated build
systems, but I think it would be easy to adjust for and simplify things for
everyone concerned.

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

charms.reactive bi-weekly catch-up

[Cory Johns]

Greeting,

Alex Kavanagh, Merlijn Sebrechts, Tim Van Steenburgh, and myself met for
the regular charms.reactive development discussions.

We discussed Merlijn's addition to the 2.0 discussion PR [1], "The case for
triggers; the apt layer" [2].  We had discussed this idea some before, but
I think we are coming around to an agreement on the need for this and what
the API should look like.

This transitioned into discussing the idea that certain flags should be
managed by the framework and "reserved," such that they are never modified
directly by any given layer, and that triggers should be used to create
per-layer "copies" of these flags that the layer would then be safe in
using as needed.  Reserved flags would include things like the current
config.changed flags, as well as interface / relation flags so that we
could do away with @hook usage in interface layers (which would have the
nice benefit of enabling an upgrade path from non-reactive to reactive
charms).

Another aspect of that idea is that we should formalize the notion that
handlers react to *changes* in flags, rather than the flags themselves, and
the "changed" state of flags should not be tied to hook invocations and
persist until an actual, meaningful change happens to that flag.  This
would remove the surprising current behavior that handlers are reinvoked
repeatedly as long as their conditions match, simply because a hook
triggered even if it didn't represent anything meaningful to the particular
handler.

Finally, we started outlining the creation of a Juju plugin which would aid
debugging of reactive charms, providing functionality such as an easy way
to inspect the flags that are set and when they were last changed, what the
history of handler invocation was, etc.

Given the recent shake-ups at Canonical, there is some uncertainty about
specific timelines, but we set ourselves a deadline of two months hence for
the trigger feature, with some other work being done in parallel.


[1]: https://github.com/juju-solutions/charms.reactive/pull/101
[2]:
https://github.com/juju-solutions/charms.reactive/blob/2.0/2.0-proposal/the-case-for-triggers.md
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] landscape-scalable, landscape-dense, ibm-was-base, ibm-was-nd, kubernetes, mongodb, ibm-spectrum-scale-manager

[Cory Johns]

Greetings,

Kevin, Pete, and I took a stab at the review queue today.

March 30, 2017:  Kevin, Pete, Cory

   -

   Landscape-scalable
   -

  https://review.jujucharms.com/reviews/112
  -

  Looks good, promulgated to:
  -

 https://jujucharms.com/landscape-scalable
 -

   Landscape-dense
   -

  https://review.jujucharms.com/reviews/113
  -

  Deploy was successful, but unusable. Machine 0 (which hosts multiple
  containers) does not have any memory constraints. On GCE, this led to an
  OOM as mem on a default instance size is a mere 1.7G.  Opened a bug for
  ~landscape to take a look:
  -

 https://bugs.launchpad.net/landscape-bundles/+bug/1677663
 -

  -1 for now
  -

   Ibm-was-base
   -

  https://review.jujucharms.com/reviews/59
  -

  There are still a few blocking issues with the charm -- left comments
  on the review.
  -

   Ibm-was-nd
   -

  https://review.jujucharms.com/reviews/40
  -

  We received word from the author that this is indeed a base layer
  (this was a point of confusion for us last week).
  -

  Seems to function as designed, but as this is not a top-layer charm,
  there is nothing to push/promulgate.
  -

  Closed
  -

   Kubernetes charms
   -

  Attempted to take a look at them, but it looks like there’s a
  permissions issue with the repo at present. Neither review queue nor
  reviewer were able to pull the charms.
  -

   mongodb
   -

  https://review.jujucharms.com/reviews/97
  -

  The mongodb charm is now available for xenial and has been
  repromulgated from ~mongodb-charmers
  -

   Ibm-spectrum-scale-manager
   -

  https://review.jujucharms.com/reviews/79
  -

  Found an issue with Python Exceptions that appeared to be
  unintentionally repressed.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

charms.reactive bi-weekly sync recap

[Cory Johns]

Merlijn, Stuart, Alex, Tim, and I had our bi-weekly charms.reactive sync
today.

We have had some good exploration of ideas for the future of reactive over
the last two weeks in the form of Issues on the repo.  This seems to be
working well for us so far, and allows for anyone to join in the discussion
(go to https://github.com/juju-solutions/charms.reactive/issues to join
in), so we will continue with discussions there and in PRs on that repo.
One change that we will make is to create a PR with a consolidated "2.0 use
cases" documentation.  This will serve as both a more consolidated and
concrete set of examples of the ideas discussed in the "[discussion]"
issues, as well as becoming the documentation for reactive once those
features are implemented.

The sync also allowed us to clean up some outstanding PRs and, thanks to
Stuart and Tim, we resolved an upstream issue that was causing our Travis
builds to fail.  We now have passing CI on our PRs again.  :)

Our next sync will be two weeks hence, but collaboration will continue on
the repo, IRC, and here on this mailing list.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Create Juju Charms from your browser!

[Cory Johns]

This is really cool!

On Mon, Feb 6, 2017 at 6:34 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Answers in-line.
>
> 2017-02-06 6:36 GMT+01:00 Andrew Wilkins :
>>
>>
>> Very cool, thanks for sharing.
>>
>> A few things which I think would make this even better:
>>  - integration with Ubuntu SSO (or GitHub OAuth, etc.)
>>
>
> This will probably be the most difficult task. Eclipse Che doesn't have
> any authentication mechanism builtin. Each user has to have their own
> Eclipse Che instance. Codenvy is a commercial product based on Eclipse Che
> that has authentication builtin, but it is closed-source.
>
>
>>  - with above: inject macaroon/token into the charmbox container, so that
>> the juju CLI would be automatically logged in (would only work with
>> external identity management)
>>
>
> Yes, that would be awesome! Even without the above, we might be able to do
> it by supplying a token to the Che Charm.
>
>
>>  - with above: Right-click "Deploy to Juju", with detection of changes to
>> deployed code and an option to update.
>>
>>
> YES! The Che team is working on a feature called "smart commands
> ". This will allow us to
> create stuff like a `build charm` action that appears in the right-click
> menu of a layer, a `build charm` command that build the currently selected
> layer, a `deploy charm` command that deploys/updates the charm.
>
> Che's speed of development is really fast, and they seem to be going in a
> direction that will allow us to create deep integration between Juju and
> Che.
>
>
>> ... in case anyone has spare time ;)
>>
>> Cheers,
>> Andrew
>>
>
>
> --
> 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-crashdump tool integration & its own repo

[Cory Johns]

A few months ago, Gregory announced the crashdump plugin to the list. [1]
 It's a great tool for debugging charm failures, so we decided to integrate
it into Matrix [2] and the bundle for doing charm & bundle CI, cwr-ci [3].
We also plan to integrate it into bundletester, so that all of our testing
tools can provide a rich set of data to diagnose any test failures.  This
gives us a standard mechanism for collecting debugging information from a
Juju deployment.

Because it is now being depended on by several other tools, it made sense
to break it out from the juju-plugins experimental repo [4] and give it a
repo of its own.  So, you can now find juju-crashdump at:

https://github.com/juju/juju-crashdump

We're continuing to improve it, and feedback, bugs, contributions, etc. are
all welcome.


[1]: https://lists.ubuntu.com/archives/juju/2016-November/008115.html
[2]: https://lists.ubuntu.com/archives/juju/2016-November/008108.html
[3]: https://lists.ubuntu.com/archives/juju/2016-December/008312.html
[4]: https://github.com/juju/plugins
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue]: websphere liberty, canonical-livepatch, ganglia-node, gluster, openvpn

[Cory Johns]

Greetings!

Kevin, Konstantinos, Pete, and I worked on the queue yesterday.  Got a new
promulgation, and some feedback.  Thanks to the charming community!

Feb 2, 2017:  Cory, Kevin, Kostas, Pete

   -

   Websphere Liberty
   -

  https://review.jujucharms.com/reviews/48
  -

  Deployment looks good; tests pass.
  -

  +1, promulgated:
  -

 https://jujucharms.com/websphere-liberty/
 -

   Canonical-Livepatch
   -

  https://review.jujucharms.com/reviews/46
  -

  Good, modulo linter errors.
  -

   ganglia-node
   -

  https://review.jujucharms.com/reviews/51
  -

  The test.yaml appears to be missing a python-packages declaration,
  which means that the amulet tests are missing required python packages.
  -

   gluster
   -

  https://review.jujucharms.com/reviews/43
  -

  There were a couple of issues we found during review.
  -

 No tests
 -

 Readme needs updates
 -

  We will have to wait for the author’s input for this.
  -

   openvpn
   -

  https://review.jujucharms.com/reviews/58
  -

  Charm itself looks great, but has install hook and test timeout
  failures
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Request to join ~charmers

[Cory Johns]

+1 from me as well

On Jan 28, 2017 6:14 AM, "Merlijn Sebrechts" 
wrote:

An unofficial +1 from me, great work on the community!


Op zaterdag 28 januari 2017 heeft Adam Israel 
het volgende geschreven:
> I am also a +1 for Pete joining ~charmers. He's put in consistent,
thoughtful work towards making our community better.
> On Sat, Jan 28, 2017 at 9:54 AM Marco Ceppi 
wrote:
>>
>> I am a +1, I've reviewed a lot of Pete's work and he understands the
core principals of charming and will make a fine addition.
>> On Thu, Jan 26, 2017 at 11:01 AM Pete Vander Giessen <
pete.vandergies...@canonical.com> wrote:
>>>
>>> Hi All,
>>> I've been working with the Big Data team since May 2016, and have
written or contributed to our charms (see https://github.com/juju-
solutions/bigtop), and layers (e.g. https://github.com/juju-
solutions/layer-apache-bigtop-base), as well as to the matrix testing tool
and cloud weather report. I also take a trip through the review queue with
the team once a week, and would like to be able to finish up my positive
reviews with a push to the charm store, when appropriate.
>>> Thank you for considering me,
>>> ~ PeteVG
>>>
>>> --
>>> 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
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem

--
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: Leadership Election Tools

[Cory Johns]

I think that's another nail in the coffin for @hook.  You could work around
it by having your @hook('upgrade-charm') handler unconditionally set a
state (e.g., 'upgrade-charm'), and then have the state handler do the
gating on leadership.  This would also allow you to use the decorators for
gating on leadership.is_leader, rather than using the is_leader() function.

I definitely want to move toward having the reactive framework itself
manage states like upgrade-charm, and {relation_name}.joined so that we can
remove all uses of @hook.

On Wed, Dec 14, 2016 at 6:00 AM, Stuart Bishop 
wrote:

>
>
> On 14 December 2016 at 00:39, Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
>> Hey Folks,
>>
>> Let's say I'm a charm author that wants to test leadership election in my
>> charm. Are there any tools available that will let me force leadership
>> election in juju so that I can test how my charm handles it? I was looking
>> at the docs here: https://jujucharms.com/docs/stable/developer-leadership
>> but couldn't see anything
>>
>
> I don't think there is any supported way of doing this.
>
> If you don't mind an unsupported hack though, use 'juju ssh' to shut down
> the unit's jujud, wait 30 seconds for the lease to expire, and you should
> have a new leader. 'juju ssh' again to restart the jujud, 'juju wait' for
> the hooks to clear, and failover is done. 'juju run' will hang if you use
> it to shutdown jujud, so don't do that.
>
> juju ssh ubuntu/0 'sudo systemctl stop jujud-unit-ubuntu-0.service'
> sleep 30
> juju ssh ubuntu/0 'sudo systemctl stop jujud-unit-ubuntu-0.service'
> juju wait
>
> Ideally, you may be able to structure things so that it doesn't matter
> which unit is leader. If all state relating to leadership decisions is
> stored in the leadership settings, and if you avoid using @hook, then it
> doesn't matter which unit makes the decisions. Worst case is that *no* unit
> is leader when hooks are run, and decisions get deferred until
> leader-elected runs.
>
> (Interesting race condition for the day: It is possible for all units in a
> service to run their upgrade-charm hook and for none of them to be leader
> at the time, so @hook('upgrade-charm') code guarded by is-leader may never
> run. And reactive handlers have no concept of priority and might kick in
> rather late for upgrade steps, requiring more creative use of reactive
> states to guard 'new' code from running too soon. Not specific to
> upgrade-charm hooks either, so avoid using @hook and leadership together)
>
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Hooking into `charm build` to download Puppet dependencies

[Cory Johns]

To put the Puppetfile contents in layers.yaml would mean that your tactic
would need to process layer.yaml and would need to be a subclass of the
existing LayerYAML tactic and ensure that all of the existing functionality
would be invoked.  Additionally, I suspect that the custom tactic would
still get overridden by the default LayerYAML tactic on the higher layers,
since the custom tactics are not carried forward.  I think this is going to
require fixes to charm-tools regardless, unfortunately.

In addition to enabling custom tactics to handle files in higher layers,
perhaps we should consider an official API for handling layer options at
build time rather than just run time?  It seems like it might be useful in
other aspects as well, and custom tactics might be a bit heavy for that
specific use-case.

On Fri, Dec 9, 2016 at 9:28 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> This is the Puppetfile:
> https://github.com/IBCNServices/tengu-charms/blob/openvpn/charms/layers/
> openvpn/files/puppet/Puppetfile
>
> I use the Puppetfile since that's the way that most modules define their
> dependencies. I'd like to have a puppet layer that requires the least
> amount of porting/adapting of existing puppet scripts. Users that have
> existing puppet scripts just drop in their Puppetfile and that's it.
> Puppetfiles can become a lot more complex than this; also defining
> dependencies from github etc.
>
> That said using options has the advantage that multiple layers can provide
> multiple puppetfiles since arrays are merged instead of not overwritten.
> The best way to go might be to have a 'puppetfile' layer option that's an
> array of all the lines in the puppetfile. The order of lines in the
> puppetfile is important. Is the order of elements in an array retained?
>
> To be clear, will switching to options allow me to put the tactic in
> layer:puppet?
>
> The openvpn puppet module already takes care of generating certificates,
> that's why I'm not using the easy-rsa charm. The charm is mostly done, I
> just need finish the tests before I can submit it to the (new) review
> queue. If you're interested you can test-drive it yourself:
> cs:~tengu-bot/openvpn.
>
>
> Op vrijdag 9 december 2016 heeft Marco Ceppi 
> het volgende geschreven:
> > There's a couple of things to unpack here.
> >
> > On Thu, Dec 8, 2016 at 10:18 PM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
> >>
> >> Hi
> >>
> >> So, I've managed to get this working. However, not exactly the way I
> want it. My charm is made like this:
> >>
> >> layer:openvpn
> >> layer:puppet
> >> layer:basic
> >>
> >> layer:openvpn provides a Puppetfile that says which dependencies need
> to be downloaded by the tactic., This works if I put the tactic in
> layer:openvpn. This doesn't work if I put the tactic in layer:puppet
> because then the tactic will run before the Puppetfile (from layer:openvpn)
> is added to the destination charm.
> >
> > This is problematic, as i think tactics only run on the given layer (if
> I recall correctly). I'd stray from having a separate Puppetfile and
> instead including it in the layer.yaml under
> > options:
> >   puppet:
> > modules:
> >   - Entry
> >   - Entry
> > We're going to be deprecating wheelhouse.txt in the same fashion.
> Looking at your OpenVPN layer, I don't really see where the Puppetfile
> lies? (I was curious it's format).
> > Also, we have an EasyRSA charm, from the OpenVPN project, if you were
> looking to charm that, we've got you covered.
> >>
> >> Downloading puppet dependencies seems to be the responsibility of the
> puppet layer. I'd like to be able to put the tactic in there so that layers
> using layer:puppet only need to provide the puppetfile and layer:puppet
> will take care of the rest. Is there a way for me to specify that a tactic
> needs to be run after all other files have been added to the destination
> charm?, or is there another way I can solve this issue?
> >
> > I'm not entirely sure, I'll prod Ben or Cory to weigh in as they know a
> lot more about tactics. If there truly isn't a way, I'll work to get a
> patch where tactics are processed continually. I think a puppet "base"
> layer is actually a pretty good approach to this, and you seem to be on the
> right path.
> >
> >>
> >> Current implementation: https://github.com/IBCNServices/tengu-
> charms/tree/openvpn/charms/layers/openvpn/tactics
> >>
> >>
> >> Kind regards
> >> Merlijn
> >> 2016-11-25 6:56 GMT-05:00 Marco Ceppi :
> >>>
> >>> That we don't have. Best to check then raise an exception if an
> external dependency does not exist (with a nice error message)
> >>>
> >>> On Fri, Nov 25, 2016, 4:42 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
> 
>  Wow, that looks really cool!
>  Any best-practices of how the dependencies of a tactic should be
> installed?
>  2016-11-25 1:19 GMT+01:00 Marco Ceppi 

Matrix: An Update

[Cory Johns]

Greetings,

We wanted to give an update on the progress and direction of the Matrix
project, which Ben announced previously[1].  To recap, Matrix is a new
bundle testing tool that augments the existing testing tools, such as
bundletester and mojo, by differing in the following core philosophies:


   -

   Juju provides a set of operational primitives that are generally
   expected to apply to any bundle and charms.  Given that, if we test those
   primitives against a bundle, we can gain a level of confidence in the
   fitness of that bundle, and provide feedback to the bundle and charm
   authors, while both shifting the burden of testing away from the charm
   author and toward the stewards of the testing tool as well as ensuring that
   the tests cover cases which might not be considered by the charm author.



   -

   Unpredictability and failure are inherent properties of running big
   software, especially in the cloud; thus, the testing should include
   somewhat chaotic and potentially destructive mutations to the deployment.
   This will both uncover bugs (in Juju, charms, and the software the charms
   manage) as well as provide insight into areas for improving reliability of
   the bundle in production.


Ben, Pete, and I have been working to get the first version finished and
polished up, and have begun working with the Juju QA team to transfer
ownership over to Torsten, Seman, and Aaron for maintainership of the
default set of test suite.  Our goal to finish this transition is December
16th.

The current default test suite can be run against a bundle and verify that
it deploys and stabilizes (within the somewhat limited ability currently
available for charms to report health, i.e., the agent and workload status
at the unit and application level), and then runs a random set of mutations
(a.k.a. “glitch”) to the deployment and watches the health as that
progresses.  (This is similar to Netflix’s idea of a “chaos monkey.”)  The
glitch plan that is generated is saved and can be replayed to reproduce a
failure.

The bundle under test can additionally provide a custom set of suites in a
tests/matrix.yaml file, as well as custom tasks to test things that are
non-generic and specific to the bundle being tested or in more depth than
can be tested by the generic framework.  The custom suites can also
override the tests built into the Matrix, if for some reason they need to
be tweaked, or to test new functionality before it is moved into the
generic test suites.

We will continue to work with the QA team to support them improving the
built-in suites, and to add features to improve the tests that are done. We
are confident that the QA team will provide great insights moving forward
as they take ownership of the Matrix project.

Once again, the code for Matrix lives at
https://github.com/juju-solutions/matrix and reviews, comments, issues, and
contributions are welcome.

[1] https://lists.ubuntu.com/archives/juju/2016-November/008108.html
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: A (Very) Minimal Charm

[Cory Johns]

Marco,

What is the issue you mentioned with using snaps where you mentioned
needing an "unconfined classic snap"?

On Thu, Dec 1, 2016 at 1:13 PM, Marco Ceppi 
wrote:

> On Thu, Dec 1, 2016 at 12:56 PM Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
> On Thu, Dec 1, 2016 at 6:53 AM, Marco Ceppi 
> wrote:
>
> On Thu, Dec 1, 2016 at 5:00 AM Adam Collard 
> wrote:
>
> On Thu, 1 Dec 2016 at 04:02 Nate Finch  wrote:
>
> On IRC, someone was lamenting the fact that the Ubuntu charm takes longer
> to deploy now, because it has been updated to exercise more of Juju's
> features.  My response was - just make a minimal charm, it's easy.  And
> then of course, I had to figure out how minimal you can get.  Here it is:
>
> It's just a directory with a metadata.yaml in it with these contents:
>
> name: min
> summary: nope
> description: nope
> series:
>   - xenial
>
> (obviously you can set the series to whatever you want)
> No other files or directories are needed.
>
>
> This is neat, but doesn't detract from the bloat in the ubuntu charm.
>
>
> I'm happy to work though changes to the Ubuntu charm to decrease "bloat".
>
>
> IMHO the bloat in the ubuntu charm isn't from support for Juju features,
> but the switch to reactive plus conflicts in layer-base wanting to a)
> support lots of toolchains to allow layers above it to be slimmer and b) be
> a suitable base for "just deploy me" ubuntu.
>
>
> But it is to support the reactive framework, where we utilize newer Juju
> features, like status and application-version to make the charm rich
> despite it's minimal goal set. Honestly, a handful of cached wheelhouses
> and some apt packages don't strike me as bloat, but I do want to make sure
> the Ubuntu charm works for those using it. So,
>
>
> I think a minimal wheelhouse to provide a consistent charm hook runtime is
> very reasonable and definitely not the problem here.
>
> There are too many packages that get installed by default with the
> reactive framework that most charms don't need. When I deploy the ubuntu
> charm (but this applies to any charm built with reactive and layer:basic),
> I also get:
>
> 2016-12-01 17:45:47 INFO install The following NEW packages will be
> installed:
> 2016-12-01 17:45:47 INFO install   binutils build-essential cpp cpp-5
> dpkg-dev fakeroot g++ g++-5 gc
> c gcc-5
> 2016-12-01 17:45:47 INFO install   libalgorithm-diff-perl
> libalgorithm-diff-xs-perl libalgorithm-mer
> ge-perl
> 2016-12-01 17:45:47 INFO install   libasan2 libatomic1 libc-dev-bin
> libc6-dev libcc1-0 libcilkrts5 l
> ibdpkg-perl
> 2016-12-01 17:45:47 INFO install   libexpat1-dev libfakeroot
> libfile-fcntllock-perl libgcc-5-dev libgomp1
> 2016-12-01 17:45:47 INFO install   libisl15 libitm1 liblsan0 libmpc3
> libmpx0 libpython3-dev libpython3.5-dev
> 2016-12-01 17:45:47 INFO install   libquadmath0 libstdc++-5-dev libtsan0
> libubsan0 linux-libc-dev make
> 2016-12-01 17:45:47 INFO install   manpages-dev python-pip-whl python3-dev
> python3-pip python3-setuptools
> 2016-12-01 17:45:47 INFO install   python3-wheel python3.5-dev
>
> None of my charms need build-essential or a g++ compiler, that's a lot of
> unnecessary dependencies! Can we get rid of most of these? Would installing
> the bare minimum with --no-install-recommends help?
>
>
> This comes up a bit, and I'm really eager to figure this out. Allow me to
> explain the catch-22. It's name is pyyaml.
>
> So the wheelhouse, by default, is 3.8M in size, this is the stock
> wheelhouse we vendor in:
>
> 312K charmhelpers-0.10.0.tar.gz
> 21K  charms.reactive-0.4.5.tar.gz
> 349K Jinja2-2.8.tar.gz
> 14K  MarkupSafe-0.23.tar.gz
> 1.7M netaddr-0.7.18.tar.gz
> 1.1M pip-8.1.2.tar.gz
> 19K  pyaml-16.11.4.tar.gz
> 248K PyYAML-3.12.tar.gz
> 29K  six-1.10.0.tar.gz
> 13K  Tempita-0.5.2.tar.gz
>
> The problem child is PyYAML, which is a compiled cpyhton module, which
> requires build-essential. The latest version is 3.12, trusty is 3.10,
> xenial 3.11, and zesty (finally) 3.12 http://packages.ubuntu.
> com/search?keywords=python-yaml, CentOS 6 & 7 are 3.10
>
> So, the easy path here is to just make sure charms.reactive works with
> PyYAML 3.10 and do a `--no-install-recommends` but that's half the problem.
> There will inevitably be python modules that require build-essential to
> compile on install.
>
> We can't cache the compiled wheelhouse because of architectures (same way
> resources complicate this) so we must compile at deploy time.
>
> One path forward, after dropping PyYAML 3.12 (if feasible), would be to
> see if we can detect when a python module needs to be compiled and setting
> a flag in the rendered charm to install the build-essentials, etc.
>
> I'll file issues and spend some time seeing if we can actually detect when
> you need to compile a wheelhouse vs a straight python module that and
> lowering the requirement for PyYAML (using packaged version 

Re: A (Very) Minimal Charm

[Cory Johns]

Marco,

What is the issue you mentioned with using snaps where you mentioned
needing an "unconfined classic snap"?

On Thu, Dec 1, 2016 at 1:13 PM, Marco Ceppi 
wrote:

> On Thu, Dec 1, 2016 at 12:56 PM Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
> On Thu, Dec 1, 2016 at 6:53 AM, Marco Ceppi 
> wrote:
>
> On Thu, Dec 1, 2016 at 5:00 AM Adam Collard 
> wrote:
>
> On Thu, 1 Dec 2016 at 04:02 Nate Finch  wrote:
>
> On IRC, someone was lamenting the fact that the Ubuntu charm takes longer
> to deploy now, because it has been updated to exercise more of Juju's
> features.  My response was - just make a minimal charm, it's easy.  And
> then of course, I had to figure out how minimal you can get.  Here it is:
>
> It's just a directory with a metadata.yaml in it with these contents:
>
> name: min
> summary: nope
> description: nope
> series:
>   - xenial
>
> (obviously you can set the series to whatever you want)
> No other files or directories are needed.
>
>
> This is neat, but doesn't detract from the bloat in the ubuntu charm.
>
>
> I'm happy to work though changes to the Ubuntu charm to decrease "bloat".
>
>
> IMHO the bloat in the ubuntu charm isn't from support for Juju features,
> but the switch to reactive plus conflicts in layer-base wanting to a)
> support lots of toolchains to allow layers above it to be slimmer and b) be
> a suitable base for "just deploy me" ubuntu.
>
>
> But it is to support the reactive framework, where we utilize newer Juju
> features, like status and application-version to make the charm rich
> despite it's minimal goal set. Honestly, a handful of cached wheelhouses
> and some apt packages don't strike me as bloat, but I do want to make sure
> the Ubuntu charm works for those using it. So,
>
>
> I think a minimal wheelhouse to provide a consistent charm hook runtime is
> very reasonable and definitely not the problem here.
>
> There are too many packages that get installed by default with the
> reactive framework that most charms don't need. When I deploy the ubuntu
> charm (but this applies to any charm built with reactive and layer:basic),
> I also get:
>
> 2016-12-01 17:45:47 INFO install The following NEW packages will be
> installed:
> 2016-12-01 17:45:47 INFO install   binutils build-essential cpp cpp-5
> dpkg-dev fakeroot g++ g++-5 gc
> c gcc-5
> 2016-12-01 17:45:47 INFO install   libalgorithm-diff-perl
> libalgorithm-diff-xs-perl libalgorithm-mer
> ge-perl
> 2016-12-01 17:45:47 INFO install   libasan2 libatomic1 libc-dev-bin
> libc6-dev libcc1-0 libcilkrts5 l
> ibdpkg-perl
> 2016-12-01 17:45:47 INFO install   libexpat1-dev libfakeroot
> libfile-fcntllock-perl libgcc-5-dev libgomp1
> 2016-12-01 17:45:47 INFO install   libisl15 libitm1 liblsan0 libmpc3
> libmpx0 libpython3-dev libpython3.5-dev
> 2016-12-01 17:45:47 INFO install   libquadmath0 libstdc++-5-dev libtsan0
> libubsan0 linux-libc-dev make
> 2016-12-01 17:45:47 INFO install   manpages-dev python-pip-whl python3-dev
> python3-pip python3-setuptools
> 2016-12-01 17:45:47 INFO install   python3-wheel python3.5-dev
>
> None of my charms need build-essential or a g++ compiler, that's a lot of
> unnecessary dependencies! Can we get rid of most of these? Would installing
> the bare minimum with --no-install-recommends help?
>
>
> This comes up a bit, and I'm really eager to figure this out. Allow me to
> explain the catch-22. It's name is pyyaml.
>
> So the wheelhouse, by default, is 3.8M in size, this is the stock
> wheelhouse we vendor in:
>
> 312K charmhelpers-0.10.0.tar.gz
> 21K  charms.reactive-0.4.5.tar.gz
> 349K Jinja2-2.8.tar.gz
> 14K  MarkupSafe-0.23.tar.gz
> 1.7M netaddr-0.7.18.tar.gz
> 1.1M pip-8.1.2.tar.gz
> 19K  pyaml-16.11.4.tar.gz
> 248K PyYAML-3.12.tar.gz
> 29K  six-1.10.0.tar.gz
> 13K  Tempita-0.5.2.tar.gz
>
> The problem child is PyYAML, which is a compiled cpyhton module, which
> requires build-essential. The latest version is 3.12, trusty is 3.10,
> xenial 3.11, and zesty (finally) 3.12 http://packages.ubuntu.
> com/search?keywords=python-yaml, CentOS 6 & 7 are 3.10
>
> So, the easy path here is to just make sure charms.reactive works with
> PyYAML 3.10 and do a `--no-install-recommends` but that's half the problem.
> There will inevitably be python modules that require build-essential to
> compile on install.
>
> We can't cache the compiled wheelhouse because of architectures (same way
> resources complicate this) so we must compile at deploy time.
>
> One path forward, after dropping PyYAML 3.12 (if feasible), would be to
> see if we can detect when a python module needs to be compiled and setting
> a flag in the rendered charm to install the build-essentials, etc.
>
> I'll file issues and spend some time seeing if we can actually detect when
> you need to compile a wheelhouse vs a straight python module that and
> lowering the requirement for PyYAML (using packaged version 

[Review Queue] ntp, ntpmaster, nagios, ibm-http, ghost, ibm-spectrum-symphony-master

[Cory Johns]

Greetings, all.  Kevin, Konstantinos, Pete, and I reviewed some charms in
the new review queue this week and last week, which I forgot to send out an
email for.

Nov 17, 2016:  Cory, Konstantinos, Kevin

   -

   IBM HTTP Server
   -

  https://bugs.launchpad.net/charms/+bug/1612535
  -

  Use of sys.exit() in a reactive charm needs to be addressed
  -

   ~nagios-charmers/nagios
   -

  https://review.jujucharms.com/reviews/13
  -

  Test fixes work
  -

  Promulgated and closed
  -

   ~ntp-team/ntpmaster
   -

  https://review.jujucharms.com/reviews/10
  
  -

  This charm was already reviewed twice plus it was in the promulgated
  space
  -

  Tested the charm on lxd and went through the review items
  -

  Promulgated and closed. Thank you for your work.
  -

   ~ntp-team/ntp
   -

  https://review.jujucharms.com/reviews/11
  
  -

  Closing this review item, since it is already promulgated.


Nov 10, 2016:  Cory, Pete, Kevin

   -

   Ghost
   -

  https://review.jujucharms.com/reviews/21
  -

  New conjure-up-based test fails
  -

   IBM Spectrum Symphony
   -

  https://review.jujucharms.com/reviews/15
  -

  Charm winds up in “maintenance” rather than “active” mode.
  -

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

Re: New helper library for unit-testing charms

[Cory Johns]

Free,

This looks fantastic!  Can I request that you cross-post this over to the
main Juju mailing list, as it would be very helpful for the community as a
whole?

On Tue, Oct 11, 2016 at 4:57 AM, Free Ekanayaka <
free.ekanay...@canonical.com> wrote:

> Hello,
>
> I published a couple of new Python packages aimed at making unit tests for
> charms easier and nicer:
>
> https://github.com/freeekanayaka/charm-test
> https://github.com/freeekanayaka/systemfixtures
>
> They implement the classic approach [0] of replacing the "boundaries" of a
> charm (hook tools, processes, filesystem, network, etc) with realistic
> fakes, so your unit tests run actual code as much as possible and you don't
> have to mock internal APIs that directly or indirectly interact with the
> boundaries (often leading to mocking explosion).
>
> Besides the package documentation, you might want to have a look to the
> jenkins charm reactive rewrite branch [1] to see some real-world use.
>
> If there's interest around this, we could move the code under the juju
> GitHub tree, or even merge it to the charm.unit package [2].
>
> Cheers,
>
> Free
>
> [0] http://martinfowler.com/articles/mocksArentStubs.html
> [1] https://github.com/freeekanayaka/layer-jenkins
> [2] https://github.com/juju-solutions/charms.unit
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Feedback wanted: Changes to the Ubuntu Charm

[Cory Johns]

On Thu, Sep 22, 2016 at 10:40 AM, Ryan Beisner <ryan.beis...@canonical.com>
wrote:

> On Thu, Sep 22, 2016 at 8:47 AM, Cory Johns <cory.jo...@canonical.com>
> wrote:
>
>> For clarity, I'd just like to note that https://jujucharms.com/ubuntu/8
>> is the candidate revision, and you can deploy this on 1.25.6 (without
>> --channel support) by being specific about the revision number:
>>
>
> Great.  How can I determine that rev is the current candidate?
>

charm show ubuntu --channel=candidate id
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Feedback wanted: Changes to the Ubuntu Charm

[Cory Johns]

For clarity, I'd just like to note that https://jujucharms.com/ubuntu/8 is
the candidate revision, and you can deploy this on 1.25.6 (without
--channel support) by being specific about the revision number:

juju deploy cs:ubuntu-8

On Fri, Sep 16, 2016 at 2:56 PM, Rick Harding 
wrote:

> Typically you'd be able to tell the source for charms set via
>
> charm show ubuntu homepage
> charm show ubuntu bugs-url
>
> In this case they're both set to https://ubuntu.com so not helpful in
> getting to the source.
>

I feel like this highlights the fact that there is some ambiguity in these
fields.  Many charms set these (or at least homepage) to point to the
upstream project.  Of course, ideally, the charm would be a part of its
respective upstream project, but that may not be the case for various
reasons and in those cases it would be helpful to differentiate the
upstream project URL, and possibly upstream bug tracker, from the charm
repo URL and bug tracker.

On a related note, though, the homepage field is no longer displayed
anywhere that I can find on jujucharms.com.  Why is it not included in the
Contribute sidebar?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] nagios, pubphoto, apache2, nrpe-external-master, couchbase, kibana, big data conjure-up spells

[Cory Johns]

Greetings.

Konstantinos, Pete, and I reviewed some items from the RQ today.  We also
forgot to send out notification of some reviews we did the week before last.

Aug 4, 2016: Cory/Konstantinos/Pete

   -

   Nagios - cross platform support (centos)
   -


  
https://code.launchpad.net/~dbuliga/charms/trusty/nagios/nagios/+merge/288614
  -

  Use the platform parameter sent from NRPE in the 'monitors' relation
  to set the host icon and text.
  -

  The code review of the patch was fine. Running the amulet tests gave
  out some errors that are probably not caused by the patch at
hand. Yet they
  need to be addressed.
  -

   Pubphoto
   -

  https://bugs.launchpad.net/charms/+bug/1574772
  -

  This is a pubphoto revision for trusty.
  -

  This was the second round of review of this charm. The authors
  addressed the minor comments that we had.
  -

  +1 for promulgation (https://jujucharms.com/u/jose/pubphoto/trusty/1)
  -

   Apache2 -- add juju storage support
   -


  
https://code.launchpad.net/~canonical-sysadmins/charms/trusty/apache2/apache2-storage/+merge/298617
  -

  “make test” fails, as new code breaks a mock in the existing tests.
  -

  Code looks good, other tests pass, and manual deploy works. +1 after
  make test is fixed.
  -

   nrpe-external-master
   -


  
https://code.launchpad.net/~aluria/charms/precise/nrpe-external-master/donotremove-hostdefs/+merge/290957
  -

  Has been +1’d but it might be deprecated in favor of nrpe, or might
  need the repo / charm store namespace updated to reflect new policies.


July 21, 2016: Cory/Kevin/Pete

   -

   couchbase (trusty)
   -

  https://bugs.launchpad.net/charms/+bug/1603300
  -

  A few tests are failing. Made notes and set status as incomplete’
  -

   Kibana
   -

  https://bugs.launchpad.net/charms/+bug/1603181
  -

  Linter fails, and one depoy test fails. Made notes and set status as
  ‘incomplete’
  -

   Conjure-up spells
   -

  This is a bit self-serving, but we really wanted to kick the tires
  with bigdata spells
  -


  
https://github.com/juju-solutions/bundle-apache-processing-mapreduce/pull/8
  -


  https://github.com/juju-solutions/bundle-realtime-syslog-analytics/pull/7
  -

  Minor comments are being addressed, but in general, these are working
  great!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Updating relation info during charm upgrades

[Cory Johns]

If I'm understanding you correctly, the ideal implementation for this would
be something like:

@hook('upgrade-charm')
@when('nrpe.available')
def update_checks(nrpe):
nrpe.remove_check(name='to-be-removed')
nrpe.add_check(...)

However, because of a bug / implementation detail (
https://github.com/juju-solutions/charms.reactive/issues/12), you will
currently have to inline the state lookup instead of using the @when
decorator:

from charms.reactive.relations import RelationBase

@hook('upgrade-charm')
def update_checks():
nrpe = RelationBase.from_state('nrpe.available')
if nrpe:
nrpe.remove_check(name='to-be-removed')
nrpe.add_check(...)

There was some discussion recently where Stuart gave me some insight which
I think will allow a fix for that bug (finally!) but I haven't yet had a
chance to dive in to it.


On Fri, Jul 8, 2016 at 1:11 PM, Casey Marshall  wrote:

> I need some help with understanding the best way to manage relation info
> across an application's lifecycle with the reactive framework.
>
> I'll start with the situation that brings me here:
>
> I have a reactive charm that provides some fairly static relation info:
> nagios checks over the nrpe-external-master interface. This charm is
> deployed and related to the nrpe subordinate.
>
> My charm adds the nagios checks it supports when joining the relation, and
> removes them when it departs.
>
> Now, in a new version of my charm, I want to add or remove these nagios
> checks, which means I need to change the relation data. What is the best
> way to do this with the reactive framework? It would be ideal to trigger a
> "conversation" to happen, that would use the same relation state handlers I
> already have in my charm, but I'm not sure how to do this.
>
> I could see a similar situation for other interfaces. http, for example,
> where you have to set extra info in YAML strings for load-balancing with
> apache2 and haproxy. It's easy to imagine needing to change those
> parameters across charm upgrades over time.
>
> I'm trying to avoid the brute-force option, which is to destroy and re-add
> the relation. That works, but seems heavy-handed and wrong.
>
> -Casey
>
> --
> 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

Apache Bigtop Juju Charming Effort

[Cory Johns]

[NB: cross posted to Juju and Bigtop lists]

I wanted to introduce the wiki page that we, the Juju Big Software team,
created to coordinate the community effort to create Juju charms for the
various Apache Bigtop components:
https://github.com/juju-solutions/bigdata-community/wiki/Apache-Bigtop

We want to continue with the community the effort that was started when the
first set of charms, for Apache Hadoop, was accepted into the Apache Bigtop
project.  Bigtop comprises over 30 different components.  We have an idea
of which ones we think should be prioritized, but we want to get the
community involved in both setting those priorities as well as getting
these components charmed so that they can be easily deployed, scaled,
tested, and benchmarked across clouds, bare metal, and local dev
environments.

Please join us by choosing a component that you care about to start
creating a charm for.  We are more than happy to help you get started!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charmers membership request!

[Cory Johns]

And my axe!  Er, I mean, +1!

On Wed, Jun 1, 2016 at 3:32 AM, Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:

> Thank you both for the vote of confidence. Lets go charming!
>
> On Tue, May 31, 2016 at 11:32 PM, Kevin Monroe  > wrote:
>
>> Since last December, I've been on 18 tours through the Review Queue with
>> Kostas.  We've seen the good, the bad, and a little bit of ugly together.
>> We're in such a harmony now that his 'ack' is really just busy work for a
>> ~charmer to come behind and mash the buttons.
>>
>> Couple his dedication to the rev queue with his Big Data charm
>> contributions, and this is an easy +1 for me.  Thanks for the application
>> Kostas; you'll be a great addition to ~charmers.
>> --
>> Kevin Monroe
>>
>> On Tue, May 31, 2016 at 12:21 PM, Charles Butler <
>> charles.but...@canonical.com> wrote:
>>
>>> A big +1 to this application. You keep me honest, and always make me
>>> contribute higher quality submissions. Even if you have to lend a hand
>>> where my python-fu falls over. I look forward to having you join the ranks
>>> as a Charmer Konstantinos!
>>>
>>> On Mon, May 30, 2016 at 11:33 AM Konstantinos Tsakalozos <
>>> kos.tsakalo...@canonical.com> wrote:
>>>
 Hi,

 This is to request membership to ~charmers.

 I have been working with the Bigdata team for some time now. You can
 find my contributions in the respective charms & bundles on https://
 github.com/juju-solutions. Also, I've been taking part in the regular (
 normally weekly) review sessions of the team so I am very familiar
 with the process.

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

>>> --
>>> Juju Charmer
>>> Canonical Group Ltd.
>>> Ubuntu - Linux for human beings | www.ubuntu.com
>>> Juju - The fastest way to model your service | www.jujucharms.com
>>>
>>> --
>>> 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

[Review Queue] autotest, ibm-java, interface:ibm-db2, ibm-db2, rsyslog, rsyslog-forwarder-ha

[Cory Johns]

Last week, the big data team, myself, Kevin, Konstantios, and Andrew,
reviewed several charms, and an interface layer:


   -

   Autotest
   -

  https://bugs.launchpad.net/charms/+bug/1516654
  -

  The propose of this Charm is to provide the autotest framework to
  execute client tests.
  -

  This is the second review round of this charm.
  -

  The author has addressed the comments we had from the first round.
  -

  Tests passed. +1 for promulgation.
  -

   ibm-java
   -

  https://bugs.launchpad.net/charms/+bug/1477067
  -

  Proposals from previous reviews have been merged
  -

  Verified this charm deploys on x86 and ppc64le (with appropriate
  access to installable packages)
  -

  +1, promulgated http://jujucharms.com/ibm-java
  -

   interface:ibm-db2
   -

  https://bugs.launchpad.net/charms/+bug/1578167
  -

  Minor improvement to one of the API method signatures suggested, but
  otherwise good.  Added to interfaces.juju.solutions
  -

   ibm-db2
   -


  
https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-db2/trunk/+merge/294153
  -

  Converted to layered charm:
  https://code.launchpad.net/~ibmcharmers/charms/trusty/layer-ibm-db2/trunk
  -

  Possible issue with how ssh keys are handled
  -

   rsyslog
   -

  https://code.launchpad.net/~timkuhlman/charms/trusty/rsyslog/nrpe
  -

  Basic lint errors and some charm-proof but main tests passing
  -

   rsyslog-forwarder-ha
   -


  
https://code.launchpad.net/~timkuhlman/charms/trusty/rsyslog-forwarder-ha/nrpe/+merge/292987
  -

  All tests passing, +1 approve
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[Cory Johns]

I think this is a strong argument for creating an interface:nrpe layer to
make supporting this as easy as possible.  There was also discussion a long
time ago about creating a translation layer of sorts for supporting
multiple different monitoring solutions (like in the Puppet example).  I
think with layers and layer APIs that's now more possible than ever.

Once we have a simplified interface, I do think that the review process
should strongly recommend that monitoring support be included, though I
don't think we'll be able to make it a hard requirement.

On Mon, May 16, 2016 at 10:06 AM, Tom Barber 
wrote:

> NRPE can be related as well, this is true. Maybe I misstated it a bit,
> I'll blame the jetlag ;)
>
> Put it this way, if a user is implementing a to-be promulgated charm, as a
> minimum (for those who expose such a thing) why not ensure the port is up
> and listening, not just the host ping, for those who have capability
> already in Nagios for a more in depth NPRE make sure its available for
> those who want to monitor it, procrunning as well for alarms.
>
> My point being, I guess, is considering how much Juju tries to do at an
> application level for sys admins, why shouldn't monitors.yaml be required
> OOTB?
>
> Don't get me wrong this was just a brief convo we had and I'm sure there
> are plenty of reasons against it, but monitoring, which is more than just
> "is my box alive" type monitoring, would seem pretty important and having
> people tack stuff on manually to a NPRE setup seems to get away from the
> Juju ethos somewhat.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 16 May 2016 at 14:52, Charles Butler 
> wrote:
>
>> I love it when you support my arguments and I'm too dense to pick up on
>> it Tim :D
>>
>>
>
> --
> 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: Backwards incompatible change to config.changed states

[Cory Johns]

Merlijn,

Apologies for the delayed reply.  I realized that I had typed this up but
forgotten to actually send it.

You're right that there are still cases where the hook-persistent nature of
the config.changed states continue to cause problems.  However, after some
discussion with Ben, I actually think that *any* sort of automatic state
removal is the wrong approach, whether it happens at the end of a hook or
at the end of an dispatch loop (essentially what you're proposing with
events).  Instead, Ben convinced me that the right thing to do is to always
have states be explicitly acknowledged and removed by the handlers.  This
doesn't work as expected currently because of an implementation detail of
how the handler queue is managed on state removals, but I think it's more
appropriate to fix that rather than add a new type of state.

In that approach, the config.changed state would be set when the change is
detected, all applicable handlers that are watching for it would execute,
each one explicitly acknowledging that it's been handled by removing it,
and then, after all handlers are done, the removals would be applied.  Note
that the initial handler (e.g., install or start_service) would also need
to clear the changed state if present to prevent the secondary handler
(reinstall or restart_service) from acting on it.  Alternatively, the
approach I took for the ibm-base layer was to remove the gating state and
separate reinstall handlers entirely, and always just drive off the
config.changed states:
https://code.launchpad.net/~johnsca/layer-ibm-base/fix-multi-call/+merge/292845

Note that there is still some potential semantic value to having "new" and
"changed" be distinguishable, but perhaps it's not as valuable enough to
worry about.

On Fri, Apr 22, 2016 at 6:57 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Cory
>
>
>
> I think this is another symptom of the deeper issue that the reactive
> framework treats events like states. 'config.changed' is an event. The
> following code is something that intuitively seems correct. We want to
> reinstall when the config has changed while the service is installed.
> However, it will still have the unwanted side effect you stated earlier.
>
> @when('installed', 'config.changed.install_source')def reinstall():
> install()
>
>
> Please note that *your fix will only work when the service is installed
> during the first config-changed hook*. If a service is installed during a
> subsequent config-changed hook, you will again have the same issue. This
> can happen when you have config options such as "(bool)install_plugin-x"
> and "(string)plugin-x-source".
>
> Anticipating these kind of conflicts requires a thorough understanding of
> both the reactive framework and hooks. You are correct in thinking that
> these conflicts should not happen. If we require every Charmer to have full
> understanding of these things, we might miss out on valuable contributions.
>
>
> I would urge you to seriously consider making the differentiation between
> events and states. For people who have used hooks it might seem logical
> that config.changed is active during an entire hook. Newcomers might have
> more difficulty understanding this.
>
> So my suggestion is:
>
>  - An event is only active right after the event happens.
>  - A handler can only be added to the queue when his events + his states
> are active
>  - A handler will be removed from the queue only when one of his states
> becomes inactive. Events of handlers that are in the queue are not
> 'rechecked'.
>
>
> Another use-case for this:
>
> @when('service.running', 'configfile.changed')
> def restart_service()
>
>  1. When the config file changes, and the service is running, restart the
> service.
>  2. When the config file changes and the service is not running, don't
> restart the service.
>  3. When the config file changed before the service was running, and now
> we start the service, don't restart the service.
>  4. When the config file changes, the service restarts, and the config
> file changes again, we want to restart the service again.
>
> 1 and 2 are currently possible. 3 and 4 would be if 'file.changed' would
> be an event.
>
>
>
>
>
> Kind regards
> Merlijn Sebrechts
>
> 2016-04-22 23:02 GMT+02:00 Cory Johns <cory.jo...@canonical.com>:
>
>> I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as
>> a slight change to how the config.changed states from the basic layer
>> work.  Currently, the changed states are set during the first hook
>> invocation, under the assumption that the values were "changed" from
>> "nothing" (not being set at all).  However, this is slightly proble

Re: Backwards incompatible change to config.changed states

[Cory Johns]

We can skip the new state if no one is depending on or finds the existing
behavior useful (I suspect that may be true).

On Fri, Apr 22, 2016 at 5:37 PM, Mark Shuttleworth <m...@ubuntu.com> wrote:

>
> I would strongly prefer not to add states lightly. Can we take some time
> to see if this is avoidable?
>
> Mark
>
> On 22/04/16 16:02, Cory Johns wrote:
>
> I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as a
> slight change to how the config.changed states from the basic layer work.
> Currently, the changed states are set during the first hook invocation,
> under the assumption that the values were "changed" from "nothing" (not
> being set at all).  However, this is slightly problematic in a case like
> the following, where we expect install() to  only be called once, unless
> the value has changed after the fact:
>
> @when_not('installed')def install():
> # do install
> set_state('installed')
> @when('config.changed.install_source')def reinstall():
> install()
>
>
> The proposal adds new states, config.new, and changes config.changed to not
> be set the first time.  You could get the old behavior by saying
> @when_any('config.new.foo', 'config.changed.foo').
>
> Is anyone depending on the current behavior?  Are there any objections to
> this change?
>
>
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Backwards incompatible change to config.changed states

[Cory Johns]

I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as a
slight change to how the config.changed states from the basic layer work.
Currently, the changed states are set during the first hook invocation,
under the assumption that the values were "changed" from "nothing" (not
being set at all).  However, this is slightly problematic in a case like
the following, where we expect install() to  only be called once, unless
the value has changed after the fact:

@when_not('installed')def install():
# do install
set_state('installed')
@when('config.changed.install_source')def reinstall():
install()


The proposal adds new states, config.new, and changes config.changed to not
be set the first time.  You could get the old behavior by saying
@when_any('config.new.foo', 'config.changed.foo').

Is anyone depending on the current behavior?  Are there any objections to
this change?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Big Data charm & bundle updates!

[Cory Johns]

Yesterday afternoon, we released a big update of the big data charms and
bundles!

This update converts all of the main big data charms to use layers, and
brings the version of the services, such as Hadoop and Spark, up to much
more recent releases.  We also changed the name of a couple of the charms
to bring them more in line with the naming convention used by the community.

The conversion to layers makes the charm code much easier to follow,
maintain, and contribute to.

Because of the conversion to layers and topology change, there is
unfortunately not a way to upgrade a bundle from the old charms to the
new.  Instead, it will require a side-by-side migration, or redeployment.

If you deploy using any of the bundles listed on
https://jujucharms.com/big-data you should not run in to any issues.
However, if you have any manual deployment scripts, you will need to update
them to account for the following name changes:

  * apache-hadoop-hdfs-master -> apache-hadoop-namenode
  * apache-hadoop-yarn-master -> apache-hadoop-resourcemanager
  * apache-hadoop-compute-slave -> apache-hadoop-slave
  * apache-hadoop-client -> hadoop-client

The change to the name of the client charm better reflects that, by using
the plugin model, the client is not tied to any specific set of core Hadoop
charms.  It is also used as the base layer for charms such as apache-spark,
making it even easier than before to connect your charm to the Hadoop
cluster.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Testing Leader Election reconfiguration

[Cory Johns]

On Tue, Mar 15, 2016 at 4:36 PM, Tom Barber  wrote:

> If I want to wait for a message is it something from the right side of
> status_set for example:
> https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py#L83 
> 'Configuration
> has changed, restarting Carte.'?
>

That's correct.  And note that if you just give a plain string to
wait_for_messages for a given service, it will be an exact, full string
match.  But you can also give regular expressions, as shown in the example.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Testing Leader Election reconfiguration

[Cory Johns]

Tom,

It's also important to note that sentry.wait() waits for *all* units in the
deployment to settle for at least 30 seconds, so it might be possible that
another unit that wasn't included in the status gist you provided is
churning and causing it to time out.  That's particularly possible if
you're reusing the deployer instance and all 34+ of those machines (going
by the machine numbers in your gist) are still extant; with that many
machines, even the periodic update-status hooks could be overlapping enough
to prevent the 30 second idle window from registering.

I'd recommend using the wait_for_mesages [1] alternative which relies on
the charm to report its status explicitly and thus doesn't need to use
heuristics like the 30 second idle window.  It could also make your test
case code a bit cleaner.

And, of course, reusing units when possible and cleaning up between test
cases can help, as well.

[1]:
https://pythonhosted.org/amulet/amulet.html#amulet.sentry.Talisman.wait_for_messages

On Tue, Mar 15, 2016 at 1:02 PM, Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

>
>
> On Tue, Mar 15, 2016 at 12:30 PM, Tom Barber 
> wrote:
>
>> Hi Tim,
>>
>> Why would I need to increase the timeout when the status says all the
>> unit are operational?
>>
>
> The default wait time is 300s, with an "idle threshold" of 30s. Which
> means, it waits for everything to be idle for 30s before returning from the
> wait. This means that with the default timeout, if the env doesn't settle
> within 4m30s, it'll time out. This may not be what's happening in your
> case, but it's worth trying a longer timeout value to make sure.
>
>
>> The status dump came out of bundletester which said that it failed on the
>> first wait(), I assume the status dump arrived at the same time?
>> Bugs are allowed, the test was hacked up from a previous one, it doesn't
>> do anything yet, I'm trying to make sure the logic works first.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 15 March 2016 at 16:27, Tim Van Steenburgh <
>> tim.van.steenbu...@canonical.com> wrote:
>>
>>> Hey Tom,
>>>
>>> 1. You can increase the wait time until it doesn't time out:
>>> self.d.sentry.wait(timeout=1200)
>>> 2. At what point in this sequence of commands was the status dump
>>> captured?
>>> 3. There is a bug here. You take a reference to the pdi/0 info dict on
>>> line 1. It's the same object you use to get message2 and message3 later.
>>> So, you'll get the same message that you got on line 1. You need `message3
>>> = self.d.sentry['pdi'][0].info['workload-status'].get('message')`
>>> instead.
>>>
>>> Hope this helps.
>>>
>>> On Tue, Mar 15, 2016 at 11:41 AM, Tom Barber 
>>> wrote:
>>>
 Okay back here again, so my nice leader election function looks like:

def test_leader_election_failover(self):
 unit = self.d.sentry['pdi'][0].info
 message = unit['workload-status'].get('message')
 ip = message.split(':', 1)[-1]
 self.d.add_unit('pdi', 2)
 self.d.sentry.wait()
 message2 = unit['workload-status'].get('message')
 ip2 = message2.split(':', 1)[-1]
 self.assertEqual(ip, ip2)
 self.d.remove_unit('pdi/0')
 self.d.sentry.wait()
 message3 = unit['workload-status'].get('message')
 ip3 = message3.split(':', 1)[-1]

 self.assertNotEqual(ip3, ip2)

 I know there's no logic in there, but I need to make sure the stuff
 actually functions.

 So Tim says wait() should work, but when I tested this last night,

 I get a timeout error o the wait right after add_unit.

 https://gist.github.com/buggtb/c271dd79d782af57dea6

 Yet in the status dump you can see all 3 units sat there seemingly
 happy.

 Tom

 --

 Director Meteorite.bi - Saiku Analytics Founder
 Tel: +44(0)5603641316

 (Thanks to the Saiku community we reached our Kickstart
 
 goal, but you can always help by sponsoring the project
 )

 On 9 March 2016 at 18:31, Tom Barber  wrote:

> Oh really?
>
> /me stokes his invisible beard.
>
>
> Okay I'll go back and try again.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we 

Re: Reactive roadmap

[Cory Johns]

On Tue, Mar 8, 2016 at 9:19 AM, Simon Davy  wrote:

> 1) Is there a roadmap for reactive? A target for a stable 1.0 release,
> or similar? We'd ideally like a stable base to build from before
> committing to use a new framework, having been (re)writing/maintaining
> charms for 4+ years now :)
>

The layered & reactive approach saw adoption more quickly than I expected,
which is both great and unfortunate for working out the kinks.  That said,
the core concepts of both aspects of this approach have been fairly stable,
with additions rather than breakages.  There is a 2.0 release of
charm-tools coming, to coincide with Juju 2.0, but again, the build process
should be backwards compatible.  There are some issues with charms.reactive
that may require incompatible changes to fix, but that would be for 2.0 and
the semantic version range that the base layer uses gives us flexibility
there, though that leads in to your next point.


> 2) Layer pinning. Right now, layers are evolving fast, and the lack of
> pinning to layer versions has caused charm builds to break from day to
> day. Is this a planned feature?
>

There has been quite a bit of discussion about this and I don't think
either side has swayed the other.  On the one hand, as you note, there is a
valid argument for needing to avoid breakage and in these early days,
layers are evolving quickly.

On the other hand, we want to strongly encourage charm authors to always
sync the layers and interfaces they use to take advantage of the
improvements and fixes from upstream, lest charms end up stagnating.  And
that means encouraging backward-compatibility in the layers.  To that end,
it has been suggested that layers be handled like interface protocols in
that, if you need to make an incompatible change, you can fork the layer
with a different name and both can coexist until one supplants the other.

Additionally, as Stuart pointed out with tongue-in-cheek, the local repo
can serve that purpose, and with charm-tools 2.0 that will become easier
with the pull-source command (https://github.com/juju/charm-tools/pull/125).


> 3) Downloading from the internet. This issue has been common in
> charmstore charms, and is discouraged, AIUI. But the same issue
> applies for layers, and possibly with more effect, due to a layer's
> composibility.  We simply can not utilise any layer that downloads
> things from github or similar, and I'm sure others are in a similar
> situation.


Again, as Stuart mentioned, this is actually *better* with layers than it
has been in the past, because layers encourage charm dependencies to be
bundled in the charm's wheelhouse, and layers can provide more consistent
adoption of best practices (it only needs to be done right once, instead of
every time).

(Note, though, that's there's an open issue with regards to some few Python
modules and network-restricted deployments:
https://github.com/juju/charm-tools/issues/117)


> We're aware of resources, but not convinced this is a
> scalable solution for layers, as it makes using a charm that has
> layers that require resources much more complex. So, some clarity in
> this area would be helpful.
>

I can't say that I understand why you think resources and layers would make
things more complicated.  They seem like they will work well together and
would solve the other half of charms in network-restricted environments
quite nicely.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Issues with missing positional arguments....

[Cory Johns]

As long as the state is only set by the interface layer, the handler will
always get the relation instance passed in for that state, no matter what
Juju hook it's currently running.  As before, I don't see anything obvious
that would cause that error, so it will require some debugging.

On Thu, Mar 3, 2016 at 5:28 PM, Tom Barber  wrote:

> Evening all here's one that someone with more brains than me can answer:
>
> https://github.com/OSBI/layer-pdi/blob/master/reactive/pdi.py
>
> I'm having issues with this with the config-change and upgrade-charm hooks
>
> Both have a nasty habit of returning:
>
> 2016-03-03 22:25:44 INFO config-changed TypeError: check_running() missing
> 1 required positional argument: 'java'
> 2016-03-03 22:25:44 ERROR juju.worker.uniter.operation runhook.go:107 hook
> "config-changed" failed: exit status 1
>
> Me and Cory mulled it over without any great resolution last night, but
> can someone explain why check_runnnig baulks. Is it because the Java layer
> passes the java object but the config-changed and upgrade-hook don't and so
> I need to split them out? or is there a nicer solution?
>
> Thanks
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> --
> 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

charms.reactive 0.4.0 release

[Cory Johns]

A new version of charms.reactive (0.4.0) has been released
.  As it is backwards
compatible, it will automatically be updated whenever you rebuild a layered
charm.

It includes the following changes:

  * New @when_any

and @when_not_all

decorators
  * Fix for some files in interface layers being mistakenly treated as
reactive handlers

The @when_any decorator works particularly well with the
config.changed.{varname}
 and
leadership.changed.{varname}
 states
provided by the base and leadership layers, respectively.  Note that, like
@when_none, it never passes in an argument.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Issue with (some) layered charms in network-restricted envs

[Cory Johns]

I'd like to raise awareness of the following issue open against
charm-tools: https://github.com/juju/charm-tools/issues/117

It affects deploying charms in network-restricted environments, depending
on whether any of the Python libraries they depend on in their wheelhouse
use a feature called "setup_requires."  Most don't, but some, like path.py,
do.

The issue has links with more information and a potential partial
work-around, but it would still require some manual work by the charm
author, so I also wanted to start a discussion about other possible
solutions.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] apache2, cassandra, haproxy, ibm-java-sdk, midonet-gateway

[Cory Johns]

Hello all.  The Big Data Team (myself, Kevin, Andrew, and Kostas) spent
some time last week on the review queue:

Feb 25, 2016: Andrew/Cory/Kevin/Kostas

   -

   apache2 (add apt config options)
   -


  
https://code.launchpad.net/~evarlast/charms/trusty/apache2/trunk/+merge/278220
  -

  This feature has been plagued with unrelated apache test failures for
  a while now.  These have all been resolved!
  -

  The latest updates merged cleanly, tests passed, and we verified apt
  config settings are working as expected.
  -

  +1, merged.
  -

   cassandra (thrift)
   -


  
https://code.launchpad.net/~stub/charms/trusty/cassandra/ensure-thrift/+merge/279869
  -

  This merged, but the change in how the config option is handled
  created issues with other charms depending on this one, which also had to
  be reviewed and merged as well:
  -


 
https://code.launchpad.net/~celebdor/charms/trusty/midonet-api/cassandra/+merge/287334
 -


 
https://code.launchpad.net/~celebdor/charms/trusty/neutron-agents-midonet/cassandra/+merge/287336
 -


 
https://code.launchpad.net/~celebdor/charms/trusty/midonet-agent/cassandra/+merge/287338
 -

   haproxy-updates
   -


  
https://code.launchpad.net/~jacekn/charms/precise/haproxy/haproxy-updates/+merge/272559
  -

  The previous comments refer to broken tests which now all pass first
  run, Approved.
  -

   ibm-java-sdk
   -

  https://bugs.launchpad.net/charms/+bug/1477067
  -

  Provided some small suggested improvements via a MR
  -

   midonet-gateway
   -

  https://bugs.launchpad.net/charms/+bug/1541735
  -

  The charm did not include any tests. There was no clear way to deploy
  the charm using only information from the readme file. There was no
  description on how to see the effects of the charm after deployment.
  - We asked the author to address the above points. We cannot move on
  with this charm at the moment.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Fwd: Charm build doesn't update interface layers

[Cory Johns]

Dropped the list accidentally on my reply.  Also, meant to note that you
only need to use charm-build (hyphenated) until the new top-level charm
command is available.

-- Forwarded message --
From: Cory Johns <cory.jo...@canonical.com>
Date: Fri, Feb 26, 2016 at 4:27 PM
Subject: Re: Charm build doesn't update interface layers
To: Merlijn Sebrechts <merlijn.sebrec...@gmail.com>


Merlijn,

There is an existing issue (https://github.com/juju/charm-tools/issues/92)
for this, which has already been resolved but the new version of
charm-tools hasn't been released yet since it includes some changes to work
with the new charm command (that will include `charm publish`).

If you're comfortable running charm-tools from master, it works, but you
have to use `charm-build` instead of `charm build`.

Also, charm-helpers is not the right repo to file the bug against.  ;)

On Fri, Feb 26, 2016 at 9:29 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi
>
>
> I'm seeing a weird bug. Charm build doesn't seem to be updating local
> interface layers. I filed a bug here:
> https://bugs.launchpad.net/charm-helpers/+bug/1550370
>
> I have the same behavior using the vagrant box.
>
>
> Kind regards
> Merlijn
>
> --
> 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: Hooks and interfaces!

[Cory Johns]

I'd just like to note that the "relation: interface" headers in the
"Connects to:" box on charm pages on jujucharms.com are links that will
take you to a search of all the charms that can be connected to that
relation.  For example, all charms that you could conceivably connect the
Gitlab charm to using the http interface can be found at:
https://jujucharms.com/requires/http

Note that these charms are not all (or even most, at this point) using the
interface layer, but that shouldn't matter.  Of course, http is a very bad
example because, as you've discovered, the protocol is fragmented with
apache2 being the worst offender.  And this is, as Marco pointed out, is
the exact reason we're pushing for new charms to use interface layers.  But
for any other interface, if the interface layer is implemented correctly,
it should have no trouble talking to a charm that doesn't use the interface
layer, as long as it follows the protocol.

On Fri, Feb 26, 2016 at 6:26 AM, Tom Barber  wrote:

> Hey Marco
>
> Its not a problem, its also me trying to wrap my head around this stuff
> better. But if they go offpiste there should be a big fat warning somewhere
> in the readme etc that indicates that its not compatible, that way I
> wouldn't spend an afternoon trying to stand up Gitlab against Apache2 then
> find an interface layer and HA proxy and do it in 5 minutes ;)
>
> Going back up to the top of this thread. I think, and its clearly
> something you guys are working on and important internally, implementation
> feedback, what variables the interfaces require etc and visibility for
> people outside of Canonical is key to getting all this layers stuff
> accepted and used properly outside. This will certainly come with time, I
> appreciate what we're doing now is smack bang in the middle of a big cross
> over from old to new!
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 26 February 2016 at 11:17, Marco Ceppi 
> wrote:
>
>> Hey Tom, sorry you've hit something that was one of the driving forces
>> behind interface layers - the http interface. It's been a heavily contested
>> and unique interface because it was originally defined as just hostname and
>> port. However, other charms don't agree on this simple implementation and
>> we have a fractured interface implementation as a result. Thankfully, only
>> the http interface suffers from this - unfortunately it's the most
>> consumed/provided interface we have.
>>
>> The apache2 charm, in particular, requires additional setup to work as a
>> reverse proxy. Something we should be able to manage better in charms now
>> that we have resources on the horizon. https://jujucharms.com/apache2/
>>
>> Simply put, the stance we've taken is - if an interface, as it's
>> designed, doesn't work for your implementation then you need to make a new
>> interface. These are contracts, albeit loosely typed, and we can't be
>> violating these contracts.
>>
>> I'll work with the maintainer of the charm to get this cleared up quicker
>>
>> On Fri, Feb 26, 2016 at 5:39 AM Tom Barber 
>> wrote:
>>
>>> Hey Merlijn
>>>
>>> Thanks for the response(great presentation in Gent by the way).
>>>
>>> Having slept on it a bit, and poked around a bit more this morning I see
>>> that the http interface does implement the hooks, so I guess I'm just
>>> getting confused with hook execution in the new reactive layer. Currently
>>> its quite hard to find concrete examples, which is understandable given the
>>> fact its blazing a new train in charm development, not a complaint, merely
>>> a fact of life! :)
>>>
>>> So expanding upon that that a little, take haproxy and apache2, they
>>> both implement the reverseproxy interface, now in my charm I can use the
>>> http interface layer and provide the http interface so that haproxy and
>>> apache2 can consume it.
>>>
>>> And that is cool as hell because then all I do in my charm is:
>>>
>>> @when('website.available')
>>> def configure_website(website):
>>> log("starting hook")
>>> website.configure(port=8181)
>>>
>>> and haproxy knows what to do, and even I can see why in:
>>> https://github.com/juju-solutions/interface-http/blob/master/provides.py#L18
>>>
>>> But, then say as a developer I want my charm to support haproxy and
>>> apache2, both just serve as reverseproxy. So, now technically speaking,
>>> from what I understand I should be able to:
>>>
>>> juju remove-relation haproxy gitlab
>>>
>>> juju add-relation apache2:reverseproxy gitlab
>>>
>>> and at which point apache2 does some funky stuff and allows my service
>>> to proxy through it, yet it 

Layered Hadoop Core

[Cory Johns]

The big data team just updated the apache-core-batch-processing bundle in
~bigdata-dev (
https://jujucharms.com/u/bigdata-dev/apache-core-batch-processing) to use
the new layered charms.  This makes the charms much easier to understand,
maintain, and extend.  We're asking for more testing by the community,
before we move the recommended core bundle over to these charms as well.

If you are interested in seeing the source layers for these charms, they
can be found in GitHub in the following repos:

https://github.com/juju-solutions/layer-apache-hadoop-namenode
https://github.com/juju-solutions/layer-apache-hadoop-resourcemanager
https://github.com/juju-solutions/layer-apache-hadoop-slave
https://github.com/juju-solutions/layer-apache-hadoop-plugin

Creating a charm that connects to the cluster is now even easier, by
extending the hadoop-client layer:

https://github.com/juju-solutions/layer-hadoop-client

One caveat with this update is that, due to some aspects of how reactive
charms maintain state internally, in-place upgrades from the existing
charms are not recommended at this point.  You will also note that there
are some differences in the services deployed, which we made to bring them
more in line with commonly understood terminology and to prepare for fully
utilizing the HA support built-in to Hadoop 2.7.1.

We are continuing to develop these charms, as well as converting the other
big data charms, such as Spark, Zeppelin, Flume, Kafka, etc., to use layers
and reactive.  We look forward to your feedback.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

@when('config.changed')

[Cory Johns]

Just wanted to give a heads-up about a feature that landed in the reactive
base layer yesterday.

If a charm config option has changed, the state "config.changed" will be
set for the duration of the hook.  Additionally, specific states will be
set for each config option that changed; that is, if option "foo" has
changed, the state "config.changed.foo" will be set.  An example of code
using this would be:

@when('myservice.started', 'config.changed')
def update_config():
update_config_files()
restart_myservice()

This provides a much cleaner way of detecting changes to config, and it is
recommended that this be used in favor of @hook('config-changed') going
forward, as the latter can actually run in to some situations, albeit
rather rarely, where the charm sees new config option values before the
config-changed hook has fired.  Using the reactive states avoids that
completely as well as working more naturally with existing @when decorators.

Please note that, while we are not aware of any charms currently using
"config.changed" as a state, there is some risk of the state set by the
base layer conflicting with it if set by the charm layer.  The
recommendation is to always prefix your states by the name of the layer
setting them,  or the relation name for interface layers.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Creating an action with a loosely defined parameter

[Cory Johns]

You can do this, with full validation, using patternProperties.  An example
using this can be found at: http://json-schema.org/example2.html

On Thu, Feb 4, 2016 at 11:10 PM, Marco Ceppi 
wrote:

> I haven't tried, but I suppose if you set it to just a `type: object`
> without params it might accept any arbitrary key. There are downsides to
> this, as you won't get validation. It also might just flat out not work.
> I'll see if I can test this a bit more
>
> On Thu, Feb 4, 2016 at 5:05 PM Tom Barber  wrote:
>
>> Yeah that wont work, because I don't know what the parameters would be
>> called, they are basically runtime variables for ETL designers.
>>
>> On the command line I need to build a string that looks something like:
>>
>> ./kitchen -file=charmerroundup.kjb
>> -param:marco=thinksallquestionareawesome -param:kevin=likestodrinklachoufe
>> -param:notetoself=nevereatbluecheeseandicecream
>>
>> so, I can have a user pass in all those params as one long string, but it
>> would nice to be able to model is as a KV object and just iterate over them.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 4 February 2016 at 21:59, Marco Ceppi 
>> wrote:
>>
>>> I'm inclined to say "yes" but I'd need a bit more of an example to
>>> confirm. Since actions are defined as jsonschema you can define nested
>>> parameters and such so I believe your usecase will work. However, the
>>> parameters you pass must be in the schema. Juju uses it to validate that
>>> the data passed is correct.
>>>
>>> EG:
>>>
>>> http://paste.ubuntu.com/14882820/
>>>
>>> I could do
>>>
>>> juju action do network-qos device=eth1 delay.time=2000
>>>
>>> but not
>>>
>>> juju action do network-qos delay.non-existant-option=True
>>>
>>> Marco
>>>
>>> On Thu, Feb 4, 2016 at 3:34 PM Tom Barber 
>>> wrote:
>>>
 Alright then chaps.

 I want to create an action with a parameter that may or may not exist
 plus you might define it more than once.

 I see in the actions doc some stuff about aditional properties which
 may or maynot be relevant. Can i pass in an array of objects of the same
 type so my bash script can iterate over them and build my required string?

 Thanks

 Tom
 --

 Director Meteorite.bi - Saiku Analytics Founder
 Tel: +44(0)5603641316

 (Thanks to the Saiku community we reached our Kickstart
 
 goal, but you can always help by sponsoring the project
 )
 --
 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: Reactive when_file_changed decorator question

[Cory Johns]

Merlijn,

You are correct, the order of handlers is undetermined, so it is entirely
possible for the execution order to be: handler1, handler2, handler3,
handler2.

The predicates, including the @when_changed test, will be checked again
after each round of dispatch, so handler2 should definitely be called again
after handler3.  If you're not careful, this can lead to inefficiencies in
your charm, which has been discussed previously here, and on issues on the
charms.reactive repo (
https://github.com/juju-solutions/charms.reactive/issues).  Stuart Bishop,
in particular, has raised several very good concerns about ensuring
intelligent handling of expensive operations such as apt-get calls or
service restarts, when dealing with constructs such as these.

While checking the code to verify my answers here, I realized that the
logic for managing re-invocation of state handlers (so that, e.g.,
@when('A') doesn't just keep matching and executing over and over in a
given hook invocation, while still allowing it to run again if the A state
changes) will override non-state predicates such as @when_file_changed.
That means that if you combine @when and @when_file_changed, handler2 might
*not* get reinvoked the second time (at least not until the next hook).  I
opened https://github.com/juju-solutions/charms.reactive/issues/49 to track
this.

There are also a couple of other open issues regarding @when_file_changed
that you should be aware of:
https://github.com/juju-solutions/charms.reactive/issues/25
https://github.com/juju-solutions/charms.reactive/issues/44

I'm still not sure what the right solution for these issues is, so input on
those is welcome.

On Thu, Jan 28, 2016 at 9:55 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Cory
>
>
> I have a question about the reactive handlers. How exactly do
> when_file_changed handlers get dispatched? Consider the following:
>
>
> @when('init')
> def handler1():
> change_file('file1')
> set_state('A')
>
> @when_changed('file1')
> def handler2():
> restart_service()
>
> @when('A')
> def handler3():
> change_file('file1')
>
>
> The order in which handlers are dispatched is random afaik, so there is
> the possibility that handler2 is executed before handler3. This would mean
> file1 is changed again after executing handler2. Will handler2 be executed
> again?
>
>
>
> Kind regards
> Merlijn Sebrechts
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

FYI: Rename of "basic" layer repo

[Cory Johns]

The repository for the base layer for reactive charms, "basic", has been
renamed from "reactive-base-layer" to "layer-basic" to bring it in line
with the convention discussed earlier on this list.  The
interfaces.juju.solutions API has been updated to reflect this, and GitHub
handles the rename transparently, so this should have no impact on anyone's
usage whatsoever.

The repository is now found at https://github.com/juju-solutions/layer-basic
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Leadership layer released

[Cory Johns]

This is awesome.  A very clean interface for dealing with leadership in
layered charms.

I also very much like the pattern of having states that notify of changes
to the leadership settings and think this pattern could apply well to
config settings.  One addition I would suggest to that pattern would be to
also have a blanket `leadership.changed` state that would be set when *any*
value was changed.  This is mostly to handle the case where you need to
react to any of a set of multiple values changing.  Thoughts?

Thanks for creating this!

On Wed, Jan 27, 2016 at 11:35 PM, Stuart Bishop  wrote:

> Hi.
>
> I've put up my Leadership layer on http://interfaces.juju.solutions/.
> This work was broken out from my PostgreSQL charm refactorings and
> will also be used by the Cassandra charm when I get onto that. It is
> obviously small and focused on leadership; I had been considering
> consolidating a number of similar parts into a swiss army knife
> 'hookenv' layer, but decided that smaller bricks are more in the
> spirit of layered charms and avoids most feature creep.
>
> # Leadership Layer for Juju Charms
>
> The Leadership layer is for charm-tools and 'charm build', making it
> easier for layered charms to deal with Juju leadership.
>
> This layer will initialize charms.reactive states, allowing you to
> write handlers that will be activated by these states. It allows you
> to completely avoid writing leader-elected and leader-settings-changed
> hooks. As a simple example, these two handlers are all that is required
> to make the leader unit generate a password if it is not already set,
> and have the shared password stored in a file on all units:
>
> ```python
> from reactive.leadership import leader_get, leader_set
> from charmhelpers.core.host import pwgen
>
>
> @when('leadership.is_leader')
> @when_not('leadership.set.admin_password')
> def generate_secret():
> leader_set(admin_password=pwgen())
>
>
> @when('leadership.changed.admin_password')
> def store_secret():
> write_file('/etc/foopass', leader_get('admin_password'))
> ```
>
>
> ## States
>
> The following states are set appropriately on startup, before any @hook
> decorated methods are invoked:
>
> * `leadership.is_leader`
>
>   This state is set when the unit is the leader. The unit will remain
>   the leader for the remainder of the hook, but may not be leader in
>   future hooks.
>
> * `leadership.set.{varname}`
>
>   This state is set for each leadership setting (ie. the
>   `leadership.set.foo` state will be set if the leader has set
>   the foo leadership setting to any value). It will remain
>   set for the remainder of the hook, unless the unit is the leader
>   and calls `reactive.leadership.leader_set()` and resets the value
>   to None.
>
> * `leadership.changed.{varname}`
>
>   This state is set for each leadership setting that has changed
>   since the last hook. It will remain set for the remainder of the
>   hook. It will not be set in the next hook, unless the leader has
>   changed the leadership setting yet again.
>
>
> ## Methods
>
> The `reactive.leadership` module exposes the `leader_set()` and
> `leader_get()` methods, which match the methods found in the
> `charmhelpers.core.hookenv` module. `reactive.leadership.leader_set()`
> should be used instead of the charmhelpers function to ensure that
> the reactive state is updated when the leadership settings are. If you
> do not do this, then you risk handlers waiting on these states to not
> be run on the leader (because when the leader changes settings, it
> triggers leader-settings-changed hooks on the follower units but
> no hooks on itself).
>
>
> ## Support
>
> This layer is maintained on Launchpad by
> Stuart Bishop (stuart.bis...@canonical.com).
>
> Code is available using git at git+ssh://
> git.launchpad.net/leadership-layer.
>
> Bug reports can be made at https://bugs.launchpad.net/leadership-layer.
>
> Queries and comments can be made on the Juju mailing list, Juju IRC
> channels, or at https://answers.launchpad.net/leadership-layer.
>
>
> --
> 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

[Review Queue] bird, neutron-calico, openbook, plumgrid-gateway

[Cory Johns]

Greetings,

This past Friday, Andrew, Konstantinos, and I spent some time on the review
queue.

We'd like to thank the fine folks at MetaSwitch for their work on the bird
and neutron-calico charms, which add Project Calico and its virtual
networking support to OpenStack.


   -

   bird
   -

  https://bugs.launchpad.net/charms/+bug/1431445
  -

  Suggested changes were accepted.  Re-tested, passed, and the charm
  was promulgated.
  -

   neutron-calico
   -

  https://bugs.launchpad.net/charms/+bug/1421230
  -

  Suggested changes were accepted.  Re-tested, passed, and the charm
  was promulgated.
  -

   openbook
   -


  
https://code.launchpad.net/~talligent/charms/trusty/openbook/trunk/+merge/280525
  -

  Tests all pass - this was held back due to long dashes in the README
  and non-recommended tags in the metadata, neither of which will affect
  charm functionality. Suggesting this be merged as the value of the charm
  outweighs potential README issues.
  -

   plumgrid-gateway
   -


  
https://code.launchpad.net/~bbaqar/charms/trusty/plumgrid-gateway/charmers-next
  -

  Reviewing the fix for restarting the service in a timely fashion
  yields some more questions.
  -

  The bundletester spotted some code style errors.
  -

  We will have to wait for a response from the author, before we
  proceed with this merge.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[Cory Johns]

This use-case lines up almost exactly with how we deal with the Hadoop
client libraries in the Hadoop core charms.

We handle this using the apache-hadoop-plugin subordinate charm.  The
subordinate charm provides the Hadoop libraries to the client, with the
versions supported being locked in the plugin charm, and it does version
matching when the plugin is connected to the Hadoop cluster to ensure that
it is compatible with the cluster.

Thus, the client doesn't need to worry about the Hadoop library version,
and it isn't version-locked to a specific Hadoop library version.  As long
as the client supports the plugin relation and the plugin charm is
connected to a compatible Hadoop cluster, the client knows that the
provided libraries will work.

The plugin charm also gives us a single charm to update with new library
versions, while retaining the ability to test those libraries to ensure
they work before updating the charm.

There is one case of potential incompatibility that wasn't addressed in
your original proposal nor in the plugin charm design as described: the
case where the client itself has trouble using certain versions of the
libraries.  Luckily, this is relatively uncommon, and if it arises, we can
address it using the same or similar "spec matching" logic that the plugin
(and other Hadoop component charms) use to ensure version compatibility, as
long as the plugin charm passes through the Hadoop version on the relation.

On Thu, Jan 21, 2016 at 12:15 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> I'm sorry, I wasn't clear about this. I wasn't consistent enough with my
> usage of Charm VS Service. The library is not for the connection between
> two charms. The library is for the connection between two services (the two
> services that the two Charms deploy).
>
> I've seen it common for Java services to use a library to connect to
> another java service. The actual network protocol is unstable between
> versions, but the API of the supplied library is stable.
>
> 2016-01-21 17:24 GMT+01:00 Nate Finch :
>
>> I actually don't see why you would ever need to distribute a specific
>> library for connecting to an API on another charm.  The charm using the
>> dynamically determined client would still require a static (i.e. backward
>> compatible) API on the client library (otherwise the client charm would
>> have no way to know how to use the client library)... so why not just put
>> that static API on the server? and then you don't need a different client.
>> Obviously, you can distribute new clients with new functionality, but by
>> definition, you'd need new code in the client charm to understand how to
>> use that functionality.
>>
>> On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi Mark
>>>
>>>
>>> I understand your concern. Leaking operational details is something that
>>> should not be done in Juju. Apache proxy relationship cannot be implemented
>>> by Nginx because the relation leaks operational details (apache specific
>>> config files). This is not 'the Juju way'.
>>>
>>> The reason for sharing resources actually is interoperability. Say a
>>> client wants to connect to a server, then the client may need libraries to
>>> do that. What libraries will be used is dependent on both the client and
>>> the server. If you ship the libraries with the client, you are essentially
>>> hard-coding the server version. This is also not the Juju way; information
>>> like this should be passed over relations. The problem here is that both
>>> Charms have to make a joint decision about what libraries, if any, to use
>>> and where to get them. No Charm has full knowledge to make that decision.
>>>
>>> I've seen two common patterns in the wild for these kind of libraries:
>>>
>>> 1. The client uses its own libraries compiled for that specific version
>>> of the server.
>>> 2. The client uses libraries bundled with the server.
>>>
>>> The first case is easy: The client has full knowledge about where to get
>>> the libraries. It only needs to know the server version. The server tells
>>> the client his version and it's done. The second case is a little bit
>>> tougher. The client has knowledge about what libraries it needs, but the
>>> server has knowledge about where to get those libraries. In this case, the
>>> client should request the libraries from the server, and the server should
>>> have a way to send them to the client.
>>>
>>> If both cases are supported by the server, you can swap any client in
>>> and out. This also translates nicely to the idea that a Charm gets created
>>> by the person who is an expert in that service. The server experts know
>>> where to get the libraries if the server has to provide them. The client
>>> expert knows how to compile the libraries if the client has to compile them.
>>>
>>> What do you think?
>>>
>>>
>>>
>>>
>>> *PS: I don't think this should be done on stack level, since 

Re: Does sftp eliminate the need to check sha1sum?

[Cory Johns]

My preference over hard-coding a checksum into the charm would be hosting a
GPG signature alongside the file and including the public key in the
charm.  This allows the charm author to update a file if necessary without
having to also update the charm, but also allows the charm to confirm that
it got the file as intended by the author.

Hopefully, though, this will become moot with the advent of resources
support in Juju 2.0.

On Thu, Jan 14, 2016 at 1:48 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Thu, Jan 14, 2016 at 3:23 AM José Antonio Rey  wrote:
>
>> I think this is more of a discusion on if you got 'what' you wanted or
>> if you got it from 'where' you wanted. Even if you used SFTP, the file
>> could've changed, and if it doesn't have a SHA1SUM it could result in
>> unexpected charm breakage.
>>
>> If it were me, I would always implement SHA1SUMS, just to make sure that
>> the file is, in fact, what I wanted. It would make it easier to debug
>> and fix later down the road.
>>
>
> +1
>
> SFTP/SSH will (can?) ensure the integrity during transit, but can't tell
> you that the data wasn't tampered with outside of the SFTP transfer
> process. Someone could have replaced the file on the file server. The
> client needs to know ahead of time what to expect.
>
> On 01/13/2016 02:18 PM, Adam Israel wrote:
>> > Matt,
>> >
>> > For the charm in question, I would think adding the sha1sum check to the
>> > process would be sufficient, especially in the scenario that the binary
>> > is being self-hosted for the purposes of installing it via the charm.
>> >
>> > Adam Israel - Software Engineer
>> > Canonical Ltd.
>> > http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>> >
>> >> On Jan 13, 2016, at 2:14 PM, Tom Barber > >> > wrote:
>> >>
>> >> Yeah but as pointed out earlier,  it verifies where you got it from,
>> >> but not what you got.  :)
>> >>
>> >> On 13 Jan 2016 19:11, "Jay Wren" > >> > wrote:
>> >>
>> >> StrictHostKeyChecking and shipping the public key of the ssh host
>> with
>> >> the charm does seem to meet the criteria of verifying the intended
>> >> source.
>> >>
>> >>
>> >> On Wed, Jan 13, 2016 at 1:46 PM, Matt Bruzek
>> >> > >> > wrote:
>> >> > I recently reviewed a charm that is using sftp to download the
>> >> binary files
>> >> > with a username and password.  The charm does not check the
>> >> sha1sum of these
>> >> > files.
>> >> >
>> >> > The Charm Store Policy states:  Must verify that any software
>> >> installed or
>> >> > utilized is verified as coming from the intended source
>> >> >
>> >> > https://jujucharms.com/docs/stable/authors-charm-policy
>> >> >
>> >> > Does using sftp eliminate the need to check the sha1sum of the
>> files
>> >> > downloaded?
>> >> >
>> >> > What does the Juju community say to this question?
>> >> >
>> >> >- Matt Bruzek > >> >
>> >> >
>> >> > --
>> >> > 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
>> >
>> >
>> >
>>
>>
>> --
>> José Antonio Rey
>>
>>
>> --
>> 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: Does sftp eliminate the need to check sha1sum?

[Cory Johns]

Merlijn,

I completely agree with you, that charm deps should be tied to the charm
version.  For the big data charms, we're working on refactoring them to use
layers (and hope to have that available in ~bigdata-dev very, very soon),
which will create a wheelhouse of deps in the charm at build time, which
should address the issue you ran into.

I should clarify that when I suggested GPG signing, I actually had in mind
charm payloads, and was thinking of making new payload versions available
(selected via a config option, as Chuck mentioned) in a secure way, without
needing a new version of the charm.  But again, with the advent of
resources, especially combined with the wheelhouse generation during charm
build, the problem will go away entirely.

On Thu, Jan 14, 2016 at 2:29 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> hi all, Sorry to barge in like this, but this is very important for my
> use-case.
>
>
> Binaries that are downloaded always need to be checked using a checksum 
> *included
> in the charm*.
>
> One Charm version should always deploy the *exact same version of that
> service*. If you want Juju to be used in production, *Charm deployment
> has to be reproducible*. Please do not force people who use Juju in
> production to fork all the Charms they use. Store Charms should be good
> enough so they can be used in production.
>
> Consider the use-case of a platform that automatically scales a service up
> and down depending on usage. This will break if we allow Charms to be
> changed between versions. This has bitten me once already. The Hadoop
> Charms downloads the jujubigdata pip dependency and uses code in this
> dependency for communication between units. Because of an oversight, two
> versions of this pip dependency were not compatible with each other. This
> meant that running `juju add-unit` on an existing Hadoop installation was
> successful one day and failed the next.
>
> I understand why the Hadoop Charms were build this way, it is a lot easier
> to maintain. However layers fix the maintenance issue.
>
> We do not know who uses our Charms and for what, so *there is no way we
> can reliably determine if a change would break a use case*. Yes, this
> change could fix a bug but there could be some service relying on this bug
> to be present. Because of this, one version of a Charm must always deploy
> the exact same thing. Let the users handle the upgrade process themselves.
>
> There are examples enough of cases where even minor version changes of
> binaries break relationships, so one version of a charm must always deploy
> the same binary.
>
>
>
> Kind regards
> Merlijn Sebrechts
>
> 2016-01-14 12:42 GMT+01:00 Cory Johns <cory.jo...@canonical.com>:
>
>> My preference over hard-coding a checksum into the charm would be hosting
>> a GPG signature alongside the file and including the public key in the
>> charm.  This allows the charm author to update a file if necessary without
>> having to also update the charm, but also allows the charm to confirm that
>> it got the file as intended by the author.
>>
>> Hopefully, though, this will become moot with the advent of resources
>> support in Juju 2.0.
>>
>> On Thu, Jan 14, 2016 at 1:48 AM, Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> On Thu, Jan 14, 2016 at 3:23 AM José Antonio Rey <j...@ubuntu.com>
>>> wrote:
>>>
>>>> I think this is more of a discusion on if you got 'what' you wanted or
>>>> if you got it from 'where' you wanted. Even if you used SFTP, the file
>>>> could've changed, and if it doesn't have a SHA1SUM it could result in
>>>> unexpected charm breakage.
>>>>
>>>> If it were me, I would always implement SHA1SUMS, just to make sure that
>>>> the file is, in fact, what I wanted. It would make it easier to debug
>>>> and fix later down the road.
>>>>
>>>
>>> +1
>>>
>>> SFTP/SSH will (can?) ensure the integrity during transit, but can't tell
>>> you that the data wasn't tampered with outside of the SFTP transfer
>>> process. Someone could have replaced the file on the file server. The
>>> client needs to know ahead of time what to expect.
>>>
>>> On 01/13/2016 02:18 PM, Adam Israel wrote:
>>>> > Matt,
>>>> >
>>>> > For the charm in question, I would think adding the sha1sum check to
>>>> the
>>>> > process would be sufficient, especially in the scenario that the
>>>> binary
>>>> > is being self-hosted for the purposes of installing it via the charm.
>>

Re: Can u supply an environment that joid had been deployed well

[Cory Johns]

Yuanyou,

If I'm understanding your question, you want to access a Juju environment
that another person bootstrapped and deployed?  You can get access to the
environment by being provided a copy of the .jenv file created when the
environment was bootstrapped.  See
https://askubuntu.com/questions/365807/whats-the-correct-way-to-share-a-juju-environment
for more information.

Note that the .jenv file will enable full control of the environment via
the Juju API (though not ssh access, as mentioned in the above link), and
it may contain cloud access credentials, so care should be taken when
sharing that file.

The next release of Juju will have a more formal system for sharing
environments, information about which can be found at
https://jujucharms.com/docs/devel/wip-systems  This can be enabled in the
current version of Juju as an experimental feature, but I believe that must
be done before the system is bootstrapped, and no assurances are made that
it will work without issue.


On Mon, Dec 21, 2015 at 2:25 AM, zhangyuanyou 
wrote:

> Hi Narinder Gupta, Artur Tyloch,
>
>I’m working on joid with the integration of onos.
>
> And I want to know can u supply an environment that joid had been deployed
> well to me?
>
> Then I can connect to the environment to do the work of integration so
> that I can avoid
>
> many install error or network-config problem.
>
>
>
> Thanks and Best wishes,
>
> Yuanyou
>
>
>
>
>
> --
> 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: Hook -relation-broken is broken with charms.reactive

[Cory Johns]

Thank you for that explanation.  I was completely misunderstanding the
-broken hook, thinking it would run for each unit like -departed and just
indicated that the unit was finally gone.  I didn't realize that it didn't
fire until there were no remaining units and the relation was torn down in
its entirety.

I think that you're right that we should do some automatic cleanup, because
if the charm author forgets to do so, it can lead to subtle and confusing
bugs.  I know, because I ran up against that already.  :)

On Sat, Dec 19, 2015 at 5:31 PM, Stuart Bishop <stuart.bis...@canonical.com>
wrote:

> On 20 December 2015 at 02:13, Cory Johns <cory.jo...@canonical.com> wrote:
> > On Sat, Dec 19, 2015 at 3:45 AM, Stuart Bishop <
> stuart.bis...@canonical.com>
> > wrote:
> >>
> >> Which unit name would you use? -relation-departed gets run multiple
> >> times, once for each unit. -relation-broken gets run once, after all
> >> the -departed hooks have been run.
> >
> >
> > That can't be right.  Surely it must run at least once on each unit still
> > remaining in the relation.  Every relation consists of two end-points,
> and
>
> A relation consists of several end-points. A relation is between two
> services, which means it is between several units (several on the
> 'local' side, and several on the 'remote' side). It is not a
> conversation between two units, where two units are passing messages
> between each other, but a conference involving several units, where
> each unit is yelling at every other unit. I find the
> relations-are-conversations metaphor breaks down as soon as you have
> two or more units to a service.
>
> From the Juju docs:
>
> ""
> [name]-relation-broken indicates that the current relation is no
> longer valid, and that the charm's software must be configured as
> though the relation had never existed. It will only be called after
> every necessary -departed hook has been run; if it's being executed,
> you can be sure that no remote units are currently known locally. It
> is important to note that the -broken hook might run even if no other
> units have ever joined the relation. This is not a bug: even if no
> remote units have ever joined, the fact of the unit's participation
> can be detected in other hooks via the relation-ids tool, and the
> -broken hook needs to execute to give the charm an opportunity to
> clean up any optimistically-generated configuration.
> """
>
> A unit appears in the relation. For every unit in the remote service,
> the relation-joined and relation-changed hooks are triggered. If a new
> unit is added to the remote service, the relation-joined and
> relation-changed hooks are triggered. If a unit in the remote service
> departs, the relation-departed hook is triggered. If the relation is
> destroyed, the relation-departed hook is triggered once for each unit
> in the remote service and the relation-broken hook triggered a single
> time, after all the relation-departed hooks have been triggered.
>
>
> > even if the implementation of Juju means that it's difficult or
> impossible
> > for the agent to populate that variable, there's still an objectively
> > correct value to put there.  And it doesn't seem unreasonable to have
> > expected Juju to do so, like it does for every relation hook.
>
> > Also, as I referenced previously, I'm pretty sure that I could
> reconstruct
> > the expected value by saving the list of departing unit(s) in the charm
> and
> > comparing that to the list during the -broken hook.  But my point was
> that
>
> I don't think there is a correct value to put there. In the -broken
> hook, the there will be zero units in the remote service. At this
> point, there is no longer a remote service at all. The only thing you
> would be doing is setting $REMOTE_UNIT to the last unit to depart,
> which is arbitrary.
>
>
> > I'm not sure it's worth doing that because I'm not sure I see a use-case
> for
> > this hook that couldn't just as easily be done with the -departed hook
> > alone.
>
> relation-departed is when a remote *unit* has gone.
> relation-broken is when the remote *service* has gone (or never
> appeared in the first place)
>
> In theory, you can use it to clean up resources required by the remote
> service. For example, you could shut down daemons no longer required
> or destroy the database used by the remote service. In theory, you
> don't do this from the relation-departed hook, because the remote
> service still exists (even if it has no units) and new units could be
> added.
>
> In practice, I don't think I've ever seen this done and suspect
> relation-broken hooks

Re: Hook -relation-broken is broken with charms.reactive

[Cory Johns]

On Sat, Dec 19, 2015 at 3:45 AM, Stuart Bishop 
wrote:

> Which unit name would you use? -relation-departed gets run multiple
> times, once for each unit. -relation-broken gets run once, after all
> the -departed hooks have been run.


That can't be right.  Surely it must run at least once on each unit still
remaining in the relation.  Every relation consists of two end-points, and
even if the implementation of Juju means that it's difficult or impossible
for the agent to populate that variable, there's still an objectively
correct value to put there.  And it doesn't seem unreasonable to have
expected Juju to do so, like it does for every relation hook.

Also, as I referenced previously, I'm pretty sure that I could reconstruct
the expected value by saving the list of departing unit(s) in the charm and
comparing that to the list during the -broken hook.  But my point was that
I'm not sure it's worth doing that because I'm not sure I see a use-case
for this hook that couldn't just as easily be done with the -departed hook
alone.


> Oh, and as the relation is *gone* by this point, self.set_remote and
> get_remote will fail.
>

I'm fully aware of that and never intended to use get/set_remote during
-broken.  However, it does make sense to remove reactive states during
-broken to ensure that they aren't incorrectly applied to relations that no
longer exist.  However, this could also reasonably be done in -departed.


> As far as the reactive framework is concerned, I don't think it fits
> as a handler on a RelationBase subclass. It would work fine as a
> 'standard' parameterless handler. Maybe you want some magic to destroy
> conversations and such from the now defunct and useless relation
> object.
>

I'm not sure I understand what you mean here.  I don't see the need for any
"magic" here.  During a relation hook, charms.reactive needs to be able to
determine what two units the relation applied to in order to know what
conversations they may have been participating in and those conversations'
associated states.  If it can't determine that for -broken, then -broken
can't be used with charms.reactive.

But, again, my question is whether it is even useful to do anything with
-broken in reactive charms?
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charms, layers, and Launchpad

[Cory Johns]

Andrew,

Good point.  I opened https://github.com/juju/charm-tools/issues/84 for
offline dev support.

On Thu, Dec 17, 2015 at 6:33 PM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Fri, Dec 18, 2015 at 9:27 AM Cory Johns <cory.jo...@canonical.com>
> wrote:
>
>> Andrew,
>>
>> It's mentioned at the start of
>> https://jujucharms.com/docs/stable/authors-charm-building and there is a
>> PR (https://github.com/juju/docs/pull/746) to rework the existing
>> authors doc into a developer guide focused on creating charms with layers
>> that will bring a lot of this information together that is currently in
>> various locations.  Reviews on that are welcome.
>>
>
> Thanks, not sure how I missed that.
>
> As for building reactive charms offline, I'm not sure I understand the
>> question.  Layer and interface deps are cached under $JUJU_REPOSITORY/deps
>> and after the first build the wheelhouse will be in the charm output dir
>> and we could potentially prefer them over hitting the index again, but the
>> first build as well as any new deps, layer, interface, or wheelhouse, will
>> inherently require network access.
>>
>
> So I wanted to build charms while on a plane without Internet access.
> Maybe I was just doing something wrong, but it wanted network access
> despite having fetched/built the dependencies once before.
>
> Obviously we'll need to hit the network on the first build, and that's
> totally fine. If pip could be optionally instructed to reuse the existing
> wheelhouses, that would be helpful. I'd build the charms once before losing
> network, and then continue iterating with the cached dependencies.
>
> Cheers,
> Andrew
>
>
>> On Thu, Dec 17, 2015 at 6:09 PM, Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> On Fri, Dec 18, 2015 at 8:58 AM Cory Johns <cory.jo...@canonical.com>
>>> wrote:
>>>
>>>> Greetings, all.
>>>>
>>>> I wanted to suggest a convention for managing layered charms with
>>>> Launchpad.
>>>>
>>>> Until the publish workflow is ready, the "built charm" (i.e., output
>>>> from `charm build`) must be checked in to Launchpad in a repo such as:
>>>>
>>>> lp:~user/charms/trusty/foo/trunk
>>>>
>>>> The base path and branch are required to be charms/ and /trunk,
>>>> respectively, for the charm to be ingested into the store.
>>>>
>>>> Launchpad isn't really set up to deal with charm layers, but I think we
>>>> could settle on a convention of using the branch /layer to denote the
>>>> source charm layer for the corresponding /trunk built charm.  The source
>>>> layer (under /layer) is what we would like to have submitted to the Review
>>>> Queue, and the /trunk branch could be used only for ingestion into the
>>>> store.
>>>>
>>>> Note that interface and base layers would need to have their own
>>>> project, since they don't really fit into the charms/series project
>>>> structure.  They can also live outside of Launchpad and work just fine as
>>>> long as they are registered in http://interfaces.juju.solutions/
>>>> (which can be done by anyone with Launchpad credentials) (eventually, the
>>>> plan is for them to be published to the store in a similar way to charms).
>>>>
>>>> I'd also like to mention our recommendations for developing layered
>>>> charms.  Specifically, you should create a base Juju repository directory
>>>> (e.g., ~/charms) and subdirectories for "layers", "interfaces" (if you plan
>>>> to develop those), and any series directories such as "trusty".  Then, you
>>>> should ensure that the following variables are set in your environment:
>>>>
>>>> JUJU_REPOSITORY=~/charms
>>>> LAYER_PATH=$JUJU_REPOSITORY/layers
>>>> INTERFACE_PATH=$JUJU_REPOSITORY/interfaces  # optional
>>>>
>>>> Many layer and interface repos are prefixed with "layer-" or
>>>> "interface-" to indicate their role (e.g.,
>>>> https://github.com/juju-solutions/layer-hadoop-base) but when cloned
>>>> locally to work on them, the directory name must match the layer or
>>>> interface name ("hadoop-base", in this case).  So, to clone that repo:
>>>>
>>>> git clone https://github.com/juju-solutions/layer-hadoop-base
>>>> $JUJU_REPOSITORY/layers/ha

Bug with @when_not

[Cory Johns]

The next release of the charms.reactive library (probably coming today)
will include a fix for the behavior of @when_not.

See https://github.com/juju-solutions/charms.reactive/pull/43 for more
information, but in short, @when_not was intended to behave as @when_none,
i.e. it should trigger if none of the states were active and *not* trigger
if any of the states were active.  Instead, it was incorrectly triggering
as long as any one of the states were not active.

This  was a subtle difference, and one I'm hopeful hasn't affected anyone,
but if you are depending on this behavior, it is recommended that you break
apart your handlers such that it is exact and explicit what the triggering
conditions are and what states will be active vs not active when the
handler is entered.

I also added the aliases @when_all and @when_none in case they are more
clear what the expected behavior is.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

charms.reactive 0.3.7

[Cory Johns]

Greetings.

I just cut release 0.3.7 of charms.reactive.  Unfortunately, due to
https://github.com/juju/charm-tools/issues/83 you will need to either
rebuild your charm from scratch from your source layer, or manually remove
the old version from the output charm's wheelhouse.

# Changes

beff693 [Cory Johns] Add release tagging to Makefile
efe48a9 [Cory Johns] Fixed bug in when_not logic and added perhaps less
confusing aliases when_all and when_none
ecff486 [Cory Johns] Doc string improvements for toggle_state suggested by
@mbruzek
3c7ce73 [Cory Johns] Added is_state and toggle_state helpers to Conversation
1a62a12 [Cory Johns] Prevent same conversation from being in the same state
multiple times
8e6b65a [Stuart Bishop] Docstrings
6f6c081 [Stuart Bishop] Allow filename arguments to be a callable, defering
their generation.
06ad7ac [Kevin W Monroe] drop which when sourcing charms.reactive.sh
1822408 [Kevin W Monroe] source charms.reactive.sh better
95362b3 [Cory Johns] Fix #36 - Improve docs based on feedback
b5131a0 [Stuart Bishop] Set JUJU_HOOK_NAME only when necessary
3ccb74e [Konstantinos Tsakalozos] Minor fixes on documentation typos
b351a34 [Stuart Bishop] Make set_remote docstring match the implementation
a7376c5 [Cory Johns] Added CLI docs
b61c219 [Cory Johns] Fixed charms.reactive.sh to work with set -u

# Highlights

This is mostly a bug-fix and doc improvement release, but it does add some
additional helpers.

# Usage

You should automatically get this update when you rebuild your charm layer
with `charm build`.  However, see the note above about the previous version.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: zookeeper resource for apache-flume-kafka

[Cory Johns]

Thanks for the catch, Merlijn, and thanks for the fix, Kevin.  We had
resolved this for the Apache Zookeeper charm (
https://jujucharms.com/apache-zookeeper/) but I didn't realize that the
apache-flume-kafka charm was using a bundled ZK.

(Also, CC'ing on the juju list for visibility.)

On Mon, Dec 14, 2015 at 6:40 PM, Kevin Monroe 
wrote:

> Hi folks,
>
> Merlijn noticed that the zookeeper resource in apache-flume-kafka [1] was
> no longer valid.  We were referencing an apache mirror URL, which is only
> valid for the current release.  Since zookeeper recently went from 3.4.6 ->
> 3.4.7, the mirror no longer included the binary needed for this charm.
>
> We have since moved zookeeper into our s3 bucket and updated the affected
> resources.  The charm store has been refreshed and apache-flume-kafka-4
> contains this fix.  FYI, the correct url for resources.yaml is:
>
>
> https://s3.amazonaws.com/jujubigdata/apache/x86_64/zookeeper-3.4.6-01b3938.tar.gz
>
> Apologies for any inconvenience, and thanks Merlijn for the report!
>
> [1] https://jujucharms.com/u/bigdata-dev/apache-flume-kafka
> --
> Kevin
>
> --
> Bigdata mailing list
> bigd...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/bigdata
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] zulu8, mysql, bird, calico, apache2, postgresql, and ethercalc

[Cory Johns]

Greetings!

The big data team, including myself, Kevin, Andrew, and Konstantinos, hit
the Review Queue today:


   -

   zulu8
   -

  https://bugs.launchpad.net/charms/+bug/1519858
  -

  Refactor to use java interface
  -

 https://github.com/juju-solutions/interface-java
 -

  Discovered issue when charm-building on one architecture and
  deploying to another:
  -

 https://github.com/juju/charm-tools/issues/58
 -

  This charm could not be successfully deployed, but we suggested
  README and reactive changes to fix this.
  -

  We also ran into a source control issue that may affect other
  layered-charm authors. The *source* for a charm can be committed anywhere
  (launchpad, github, etc), but it must not interfere with where the charm
  store will look for deployable charms:
  -

 lp:~/charms///trunk
 -

   mysql
   -


  
https://code.launchpad.net/~tvansteenburgh/charms/trusty/mysql/fix-tests/+merge/277053
  -

  Fixes for tests d.sentry[‘mysql’][0] vs d.sentry[‘mysql/0’]
  -

  All tests are passing
  -

  +1 this has been merged
  -

   Ping for follow-up: bird, Calico, apache2/hostname-resolution-fix
   -

  https://bugs.launchpad.net/charms/+bug/1431445
  -

  https://bugs.launchpad.net/charms/+bug/1421230
  -


  
https://code.launchpad.net/~verterok/charms/trusty/apache2/hostname-resolution-fix/+merge/272127
  -

  These were all given approval conditional upon some minor feedback
  and were awaiting response by the submitter, so we pinged them again to
  keep the process moving.
  -

   postgresql/fix-test-returncode
   -


  
https://code.launchpad.net/~stub/charms/trusty/postgresql/fix-test-returncode/+merge/277312
  -

  +1 merged
  -

   ethercalc
   -

  https://bugs.launchpad.net/charms/+bug/1486247
  -

  +1 for promulgation, but the copyright is still assigned to Canonical
  - Going to give one last chance to reclaim the copyright


Questions/comments? We're in #juju on irc.freenode.net

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

Re: [ANN] charm-tools 1.9.3

[Cory Johns]

Stuart,

Yes, the `--no-binary` option is supposed to prevent that but doesn't seem
to be being honored.  https://github.com/juju/charm-tools/issues/58 has
been opened to track it, and I'm looking in to creating a work-around using
`--no-use-wheel` until I can get clarification or a fix from upstream.

On Thu, Dec 3, 2015 at 5:16 AM, Stuart Bishop <stuart.bis...@canonical.com>
wrote:

> On 1 December 2015 at 05:55, Cory Johns <cory.jo...@canonical.com> wrote:
> > PyYAML includes a pure-Python version which would be used if building
> fails.
>
> I'm getting confused now.
>
> When I do 'charm build' with 1.9.3, my generated charm ends up with an
> embedded amd64 binary wheel for PyYAML which includes a .so file. What
> happens when I deploy this charm on power8 or arm? How does the pure
> python version of PyYAML appear when the only thing available is a
> amd64 binary wheel?
>
> --
> Stuart Bishop <stuart.bis...@canonical.com>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju