Re: Please promulgate Mattermost charm

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 >

python-libjuju 0.8.0

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

charms.reactive 0.6.3 has been released

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

Re:

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

Re:

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

Re: Should 'juju status' always include a timestamp

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

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

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 en

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

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

Re: Promulgate request

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

Re: Promulgate charms

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

charms.reactive 0.6.2

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

python-libjuju 0.7.3

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

charms.reactive 0.6.1

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

Re: [charms] Request to promulgate charms

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

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

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

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

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

charms.reactive 0.6.0

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

Re: Submission of sme-1 for charm store

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 6L

Re: Submission of sme-1 for charm store

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

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

Re: Debug logs

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

Re: Is there a universal interface I can use?

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

Re: Charm Tools distribution channels and versions

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

charms.reactive 0.5.0

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

Bug-fix release for python-libjuju

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

Re: Charm layer index now on GitHub

teenbu...@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 in

Re: Charm layer index now on GitHub

teenbu...@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 in

Charm snap is now strictly confined

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

Charm snap is now strictly confined

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

Charm layer index now on GitHub

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

Charm layer index now on GitHub

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

Re: How do upgrades handle resources?

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

Re: Is a set state called multiple times?

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

Re: Is a set state called multiple times?

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

Re: Is a set state called multiple times?

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

New release of python-libjuju

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

Re: Maximum AllWatcher frame size?

al > // 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? > >

Re: Maximum AllWatcher frame size?

nk 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 ra

Maximum AllWatcher frame size?

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

Re: Juju 2.2-rc2 has been released

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

Re: Does relation scopes need to match?

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

Re: How to count relations?

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 marginall

Re: How to count relations?

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 *

Re: Normalizing output dir for charm build

4 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

Re: Normalizing output dir for charm build

following? > > > ├── charms# $JUJU_REPOSITORY > │ ├── my-charm > │ ├── ... > ├── interfaces# $INTERFACE_PATH > │ ├── ... > ├── layers# $LAYER_PATH > │ ├── ... > > > > 2017-05-10 23:39 GMT+02:00 Cory Johns <cory.jo...@canon

Normalizing output dir for charm build

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

charms.reactive bi-weekly catch-up

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

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

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

charms.reactive bi-weekly sync recap

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

Re: Create Juju Charms from your browser!

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

juju-crashdump tool integration & its own repo

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

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

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 -

Re: Request to join ~charmers

+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

Re: Leadership Election Tools

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

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

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

Matrix: An Update

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:

Re: A (Very) Minimal Charm

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,

Re: A (Very) Minimal Charm

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,

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

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 -

Re: New helper library for unit-testing charms

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

Re: Feedback wanted: Changes to the Ubuntu Charm

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 candi

Re: Feedback wanted: Changes to the Ubuntu Charm

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

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

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) -

Re: Updating relation info during charm upgrades

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 /

Apache Bigtop Juju Charming Effort

[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

Re: Charmers membership request!

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

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

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

Re: Promulgated charms (production readiness)

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

Re: Backwards incompatible change to config.changed states

> 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

Re: Backwards incompatible change to config.changed states

ime > 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 du

Backwards incompatible change to config.changed states

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

Big Data charm & bundle updates!

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

Re: Testing Leader Election reconfiguration

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.'?

Re: Testing Leader Election reconfiguration

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

Re: Reactive roadmap

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 >

Re: Issues with missing positional arguments....

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,

charms.reactive 0.4.0 release

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

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

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

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

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 -

Fwd: Charm build doesn't update interface layers

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 Subje

Re: Hooks and interfaces!

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

Layered Hadoop Core

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

@when('config.changed')

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

Re: Creating an action with a loosely defined parameter

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` >

Re: Reactive when_file_changed decorator question

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

FYI: Rename of "basic" layer repo

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

Re: Leadership layer released

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

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

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 -

Re: Sending binaries over relations

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

Re: Does sftp eliminate the need to check sha1sum?

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

Re: Does sftp eliminate the need to check sha1sum?

ust 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 alon

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

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

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

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

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

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

Re: Charms, layers, and Launchpad

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

Bug with @when_not

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

charms.reactive 0.3.7

[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

Re: zookeeper resource for apache-flume-kafka

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,

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

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

Re: [ANN] charm-tools 1.9.3

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 conf

  1   2   >