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

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 compati

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:

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

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 th

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

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 ma

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 is the charm to deploy/mana

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 cs:~charmers/opentsd

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 Juju@lists.ubunt

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 loca

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 Rel

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 wil

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 so

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 th

Re: Submission of sme-1 for charm store

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 char

Re: Submission of sme-1 for charm store

elated 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 > > To: juju > > Subject: Re: Submission of sme-1 for ch

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 a

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 out

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

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 thi

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 reactiv

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 new

Re: Charm layer index now on GitHub

>> Fantastic, this is a great change - well done! >> >> On Fri, Sep 8, 2017 at 2:39 PM, Cory Johns >> wrote: >> >>> Greetings, >>> >>> Today we migrated the index of base and interface layers used to build >>> charms over to the GitHub

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 accountabili

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 u

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 wrote: > Alex, > >

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 something

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 w

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 --classic --candidate > conjure-up (ca

Re: set_remote() <-> get_local()?

get/set_remote deal with relation data sent over the wire. get/set_local never leave the unit in question and are simply there as a way to associate information locally with a given remote unit. Generally speaking, get/set_local aren't actually what you want, and I wouldn't recommend using them.

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 speaks

Re: How to count relations?

scopes and conversations anyway, instead). On Wed, Jun 7, 2017 at 12:30 PM, Alex Kavanagh wrote: > > > On Wed, Jun 7, 2017 at 4:44 PM, Cory Johns > wrote: > >> Alex beat me to it, but here's a marginally more complete example: >> https://gist.github.com/johnsca/

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

Re: Normalizing output dir for charm build

t 9:34 AM, Adam Israel 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 > wrote: > >> Yes, that's what I'm proposing. &g

Re: Normalizing output dir for charm build

the > following? > > > ├── charms# $JUJU_REPOSITORY > │ ├── my-charm > │ ├── ... > ├── interfaces# $INTERFACE_PATH > │ ├── ... > ├── layers# $LAYER_PATH > │ ├── ... > > > > 2017-05-10 23:39 GMT+02:00 Cory Johns : > >> There are

Re: Normalizing output dir for charm build

rom > `layers` and `interfaces`. > > This is my $JUJU_REPOSITORY: > > ├── charms > │ ├── builds > │ ├── deps > │ ├── interfaces > │ ├── layers > > > 2017-05-10 20:03 GMT+02:00 Cory Johns : > >> Started on https://github.com/juju/charm-tools/pull/320,

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 r

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 we

[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

[Review Queue] giraph, ghost, charmscaler, ibm-was-nd-dm, ibm-dsm-enterprise, ibm-cinder-storewize, ibm-was-nd-node

Greetings! Kevin, Pete, Konstantinos, and I got in our time on the queue this week: March 2, 2017 - giraph - https://review.jujucharms.com/reviews/82 - PR from last week was approved by the author. - Deployed fine and tests passed. Congrats! +1 and pr

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 discus

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 even better: >> - integration wi

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 testing

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

charms.reactive leadership team

The reactive framework has seen widespread adoption in the charming community and on the whole the response to it has been very positive. Unfortunately, due to the small size of the original leadership team and other obligations that we've had, development on the framework has not kept up with adop

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 ~charmers. He's put in consistent, thoughtful work towards mak

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 still

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, Dec 1, 2016 at 6:53 AM, Marc

[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: Feedback wanted: Changes to the Ubuntu Charm

On Thu, Sep 22, 2016 at 10:40 AM, Ryan Beisner wrote: > On Thu, Sep 22, 2016 at 8:47 AM, Cory Johns > 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 >

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

[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) - https://code.launchpad.net/~dbulig

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

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 We

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 December, I've been on 18 tours t

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

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 wi

Re: Backwards incompatible change to config.changed states

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 '

Re: Backwards incompatible change to config.changed states

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

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

Re: Questions about updated bundle\charms

(note: cc'ing to the juju list in case anyone there also has any confusion about these points) Hey, Alex! Welcome to the Big Data list. Many apologies for not getting a reply out to you sooner. Both of those bundles should be functionally the same now, but the one in the bigdata-dev namespace p

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 char

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.'? > That's correct. And no

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 you

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 > charms for 4+ years now :) > Th

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

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

Layered realtime-syslog-analytics and apache-hadoop-spark-zeppelin

Following up on the announcement of the layered Hadoop core bundle (apache-core-batch-processing), we have now also updated the apache-hadoop-spark-zeppelin ( https://jujucharms.com/u/bigdata-dev/apache-hadoop-spark-zeppelin) and the bundle that builds on it, realtime-syslog-analytics ( https://juj

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

[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 Date: Fri, Feb 26, 2016 at 4:27 PM Subject: Re: Charm build doesn&#

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 co

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

Re: Creating an action with a loosely defined parameter

I should clarify that patternProperties is supported by json-schema, but it might not be supported by Juju (I would guess not). You could try it with something like this: http://pastebin.ubuntu.com/14887866/ On Fri, Feb 5, 2016 at 4:34 PM, Cory Johns wrote: > You can do this, with f

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` > without params it might accep

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 tra

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 be

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 wou

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

Re: Does sftp eliminate the need to check sha1sum?

arm must always deploy > the same binary. > > > > Kind regards > Merlijn Sebrechts > > 2016-01-14 12:42 GMT+01:00 Cory Johns : > >> My preference over hard-coding a checksum into the charm would be hosting >> a GPG signature alongside the file and including 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 g

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 https://askubuntu.com/questions/36

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

n 20 December 2015 at 02:13, Cory Johns 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.

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 must run at least once on each

Hook -relation-broken is broken with charms.reactive

I recently stumbled across https://bugs.launchpad.net/juju-core/+bug/1098442 by way of realizing that the @hook('{relation_name}-relation-broken') handlers in my interface layer were not doing anything. At all. It turns out that without knowing for what remote unit the -relation-broken hook is ru

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 > wrote: > >> Andrew, >> >&g

Re: Charms, layers, and Launchpad

ec 18, 2015 at 8:58 AM Cory Johns > 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

Charms, layers, and Launchpad

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

charms.reactive 0.3.7

ff693 [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_

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 none

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

[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

a fix from upstream. On Thu, Dec 3, 2015 at 5:16 AM, Stuart Bishop wrote: > On 1 December 2015 at 05:55, Cory Johns wrote: > > PyYAML includes a pure-Python version which would be used if building > fails. > > I'm getting confused now. > > When I do 'charm build

[resolved] Install hook failure on apache-hadoop-plugin yesterday

If you were deploying the Apache Hadoop charms yesterday, you may have run into a deploy failure with the apache-hadoop-plugin charm. This was due to an updated dependency that ended up causing an issue. It has been resolved by making the version pinning on that dependency more strict, so this is

Re: [ANN] charm-tools 1.9.3

PyYAML includes a pure-Python version which would be used if building fails. I'm not entirely averse to coming up with a way to specify an exclude list for wheel deps that would be provided in some other way, but what if one layer excludes a wheel that another layer explicitly includes? And how w

  1   2   >