Charms and admin passwords

Hi all, I was wondering about the right way to handle admin passwords for user-facing apps in a charm? Obviously, we don't want to have static default admin passwords, as that leads to insecure default setups. However, I haven't seen an easy, secure way for the charm to communicate a password up

[Review Queue] PyBossa, and refactoring pgbouncer to use charmhelpers

from the charms. Thanks, Cory Johns -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju

Re: Application for Juju Charmer Status

While I'm not an official charmer myself, my vote would be a solid +1 as well. I've always found José's reviews to be thorough and insightful, and his charm contributions to be excellent. On Thu, Aug 21, 2014 at 12:11 PM, Marco Ceppi wrote: > Hi Jose! > > Thank you so much for your submission to

Re: [Ecosystem-engineering] Proposal: New review queue and review process

Marco, I just wanted to follow up and say that this proposal sounds great to me. The only addition I would make is clarifying what the logic is when there are conflicting reviews; e.g., if you mark something as TRIAGED (I don't suppose there's any possibility of getting a FIX ACCEPTED status adde

[Review Queue] pgbouncer follow-up, NTP MP, Diaspora

I did a follow-up review for the pgbouncer merge proposal since Stuart addressed my comments from last week, and gave it my +1. [1] I also took a look at a merge proposal for the NTP charm which also got my +1. [2] Finally, I attempted to review Jason's improved Diaspora charm branch, but ran in

[Review Queue] hdp-tez and zabbix-agent

Yesterday evening, I reviewed two items from the new Review Queue[1]: a new Big Data charm, hdp-tez, for adding YARN support to Hadoop, as well as a zabbix-agent charm change that was submitted to the Review Queue but specifically noted as being for a personal namespace. Amir's hdp-tez charm[2] lo

[Review Queue] storage and zabbix-agent (personal namespace) followup

https://code.launchpad.net/~tribaal/charms/precise/storage/refactor-mount-volume/+merge/232236 I had some back-and-forth discussion with Chris and David regarding this refactor, which looks like a great change to me. I have personally reserved my +1 due to some tests that were necessarily removed

[Review Queue] rkhunter, logrotate, and mongodb/auth_experiment

Yesterday and today, I reviewed a couple of new charms by Chris Stratford, and an improvement to the MongoDB charm by Matthew Williams. Chris submitted a charm for the rkhunter rootkit detection package which, but for a config option value being hard-coded in one spot, looked very good. He also s

[Review Queue] ForgeRock OpenAM & OpenDJ, and Wildfly (MP)

Today I did a follow-up to Tim's review of the ForgeRock charms for OpenAM and OpenDJ [1]. I noted two items that need to be improved: required config options causing error state instead of simply blocking, and better handling of the requirement of a full domain name as opposed to an IP address.

[Review Queue] storage (encryption) and nfs (trusty)

I reviewed Chris's addition to the storage charm to add encrypted file-system support. He added tests per Tim's request, which were good, but I had issues running them as we as encountering a few small test breakages in the existing tests. I also reviewed Matt's test additions to get the nfs char

[Review Queue] mongodb and postgresql

Today I reviewed a small fix to the trusty version of the mongodb charm to get it passing tests[1]. I also revisited an addition to the mongodb charm[2] to manage the user in a way similar to the postgresql charm, which touched on the doc change I reviewed on that charm[3]. [1]: https://launchpad

[Review Queue] python-django and pubphoto

I reviewed the following items: [1]: https://code.launchpad.net/~patrick-hetu/charms/precise/python-django/pure-python/+merge/226742 [2]: https://bugs.launchpad.net/charms/+bug/1331844 The changes in [1] mostly look good, but the tests are missing "expose" directives which is causing them to fai

Re: charm-helpers fetch apt_install optimization

Reiterating my comment on the MP, I agree with Marco that, due in part to the fixed-point usage pattern of charm-helpers and in part to the specifics of the change, I don't see it as having much potential for breakage. That said, I'm certainly not against testing it before merging. On Thu, Nov 20

[Review Queue] mongodb rs.initiate(), python-django, and bip

Yesterday and today, I reviewed the following merge proposals: * [approve] mongodb, explicitly using public-address for rs.initiate() to resolved issues with unresolvable host name on MAAS https://code.launchpad.net/~jjo/charms/trusty/mongodb/jjo-lp1274947-use_private-address_at_rs-initiate/+m

[Review Queue] Charm testing / RTG: chef-server, thinkup, couchbase, and couchdb

I did reviews of four charm testing / red-to-green merge proposals: * chef-server: +1 * thinkup: -1 (charm proof) * couchbase: -1 (install hook failure) * couchdb: -1 (install hook failure) I submitted fixes for all of the failures, since they were relatively small fixes. https://code.launchpad

[Review Queue] Charm testing: distcc, stackmobile, firefox-sync, shelrtv

I did reviews of four charm testing / red-to-green merge proposals: * distcc: -1 (install hook failure) (fixed) * stackmobile: -1 (install hook failure) (SSL handshake error) * firefox-sync: -1 (install hook failure) * shelrtv: -1 (install hook failure) (PPA issue) I was able to add a fix for the

[Review Queue] chamilo, bitlbee, python-django, rabbitmq-server

* chamilo: -1 (test failure due to race; submitted fix) * bitlbee: +1 * python-django: +1 * rabbitmq-server: -1 (merge conflict; tried to resolve but wasn't confident in my resolution) https://code.launchpad.net/~jose/charms/precise/chamilo/add-tests/+merge/241363 https://code.launchpad.net/~jose/

[Review Queue] wildfly-ha-master and wildfly-ha-slave

I reviewed this pair of charms and game them my +1 with the caveat that a couple of small test fixes be made during promotion: * The test (in wildfly-ha-master) needs to point to the charm store, not local: * The test needs to be set to executable * The test needs to be copied to wildfly-ha-slave

Re: An Open Question: Charm Dependency Management

I think that it's important that we have tooling (i.e., bundletester) that sets up a (consistent) environment that is exactly the same as what the automated test runner uses (i.e., a fresh container or vm in which the tests are run) and that charm authors and reviewers alike use it. With that, the

[Review Queue] Tomcat interface improvement, and MySQL test additions

While helping with the OpenBook review, we discovered that the Tomcat charm was did not have clearly described ways for ingesting Java webapps, so I decided to submit a patch[1] to improve that. I also reviewed two test submissions to the trusty MySQL charm, one of which passed easily[2], and the

[Review Queue] ksplice, and python-django

Kevin and I worked together yesterday to review a new charm submission for KSplice / Uptrack [1], and a merge proposal to (re?)add pip_extra_args support to the trusty python-django charm [2]. The KSplice charm had an issue with the provided test requiring manual input, which would break the autom

Re: Unable to deploy a working 10 node hadoop cluster

Ken, Unfortunately, this is due to an upstream change in the openjdk package. A bug has been filed[1] and it has been noted that this breaks all of the Big Data charms in the store. Please indicate on that bug that this is affecting you. There is a symlink work-around mentioned on the bug, but

Re: keeping state in units

Awesome. I've been looking forward to this being released. I've already been using the proof-of-concept version in the Big Data charms, and it's great. On Wed, Feb 11, 2015 at 8:12 AM, Kapil Thangavelu wrote: > > Hi Folks, > > Just merged a new charm helper that I wanted to highlight. I've seen

Juju Resources (a tool / library)

Hi all, (cross-posting to juju & juju-dev) I've created a tool / library for organizing and managing resources (binary blobs, tarballs, Python packages, and, eventually, apt packages) required by a charm. The idea is to be an interim tool, and a test-bed for the resource features that have been

Re: Juju Resources (a tool / library)

Per request, the documentation is now also available on ReadTheDocs.org: http://jujuresources.readthedocs.org/ On Wed, Feb 11, 2015 at 11:25 AM, Cory Johns wrote: > Hi all, > > (cross-posting to juju & juju-dev) > > I've created a tool / library for organizing and mana

Re: Juju Resources (a tool / library)

to have in the long run. Having two resource > implementations and taking over important namespaces such as > resources.yaml might introduce unnecessary confusion down the road. > Instead, the project might have a nice non-generic name, and its > configuration file could also be named after it.

Re: charm creation and charmhelpers

Thierry, In the current template, charmhelpers is installed using pip, and the path you mentioned is the system package path for Python 2.7, so it should be on the path by default. I just created a new charm using the template and confirmed that it was able to import charmhelpers from that locati

[Review Queue] docker, flannel-docker, kibana, & nrpe

Hey all, Kevin, Amir, and I took on a few reviews, mainly focused on the new Docker charm submissions by Charles Butler, but also continuing to address the slew of test additions by nicopace, as well as some follow-ups to our previous reviews. + docker https://bugs.launchpad.net/charms/+bug/1

[Review Queue] kibana & nagios tests (follow-up)

Following up on previous reviews, I took a look at test additions by nicopace to both the kibana and nagios charms. Both had some minor issues causing failures, but I created secondary MPs with suggested fixes to help get these reviews finalized. https://code.launchpad.net/~nicopace/charms/trusty

Re: New Docker goodies

Thanks. :-) I do hope we can also to get local provider working inside the container as well, since it will provide a cleaner set of instructions for new charmers to test their charms, or just play around with Juju. But the --net=host workaround gives us immediate wins in CI, review, and developm

Re: Tests Best Practices

José, That's a good point that we definitely need recommended best practices for writing charm tests. I am also behind using the built-in unittest[1] library to organize and structure the tests. I am also behind encouraging combining tests inside test cases where possible, with the caveat that

Re: Tests Best Practices

As Nate pointed out, I forgot the link. >_< [1]: https://docs.python.org/2/library/unittest.html On Tue, Apr 14, 2015 at 1:59 PM, Cory Johns wrote: > José, > > That's a good point that we definitely need recommended best practices > for writing charm tests. I am also be

[Review Queue] was-base, was-nd, and galera-cluster

Hello all. Kevin and I reviewed the following charms yesterday: * websphere base https://bugs.launchpad.net/charms/+bug/1446966 In addition to a few small concerns, such as using the template icon, we noted some immutable config and ran into trouble testing the charm due to not being able to acc

[Plugin] sync-watch: Edit locally, run in the cloud

Last week, while in Nuremberg, Ben and I were able to create a new plugin to enable a much better charm development workflow. Once the Juju Plugins bundle (https://github.com/juju/plugins) is installed, you can now run `juju sync-watch ` to enable local editing of a remote charm. This works using

Re: [Plugin] sync-watch: Edit locally, run in the cloud

; of juju's architecture helped and hindered you? > > -eric > > On Fri, Apr 24, 2015 at 6:34 AM, Cory Johns wrote: >> Last week, while in Nuremberg, Ben and I were able to create a new >> plugin to enable a much better charm development workflow. >> >>

[Review Queue] redis, plumgrid-director, neutron-iovisor, and PlumGrid Bundle

Greetings! The Big Data team did some RQ time together today: + redis https://bugs.launchpad.net/charms/+bug/1459345 This looks like a rewrite of the redis-master and redis-slave charms to combine them into a single charm. We ran into some issues getting bundletester to run to test the charm.

[Review Queue] redis re-redux

Greetings all. My review queue time this week was a bit limited, due to being sick and other conflicts on my time, but I was able to revisit Francesco's new Redis charm (https://bugs.launchpad.net/charms/+bug/1459345) and, with a bit more back-and-forth related to ensuring that the automated test

Re: Juju Compose

On Tue, Jul 14, 2015 at 4:45 PM, Marco Ceppi wrote: > I think you're on the right train of thought as to what this is, but miss a > few important issues this helps address. It's is trivial to copy code > around, and we talk about it all the time in charm schools "find a charm > similar, fork, edit

[Review Queue] etcd, storage, postgresql (and some from last week)

Greetings. The Big Data team (myself, Kevin, and Amir) got in some Review Queue time today. We also apparently forgot to send out an email for the RQ items we got to last week, so those are included below, as well. + etcd https://bugs.launchpad.net/charms/+bug/1474061 Mostly good, Amir had a co

Charmers application

Dear Charmers, I would like to apply for membership to https://launchpad.net/~charmers I have worked on the current set of Big Data charms and bundles, Cloud Foundry charms , and several other smaller charms. I also tr

Re: i want in (to ~charmers)

I'm not a ~charmer yet, but if I were, Kevin would definitely get my +1. On Mon, Aug 10, 2015 at 2:08 PM, Matt Bruzek wrote: > Another person who delayed the charmer application too long! > > Kevin forgot to mention he is also a concierge for the IBM charmers. That > has been a lot of work ... s

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

language should >>> expose. This will enable us to document charm-helpers more thoroughly and >>> include code examples for each language supported in our docs. Also, by >>> having a narrowly defined scope of methods, it enables other communities to >>> create helpers f

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

On Wed, Aug 12, 2015 at 7:38 AM, Marco Ceppi wrote: > I can see how this helps for discoverability for those already pretty > intimate with the code base, but a lot of the key complaints we've gotten > around new authors getting started is there is just an overwhelming amount > of code. > I hone

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

On Thu, Aug 13, 2015 at 8:12 AM, Stuart Bishop wrote: > I think the documentation at https://pythonhosted.org/charmhelpers/ is > key here. To aid new authors, we need a reference guide of all the > helpful tools. Even if charm-helpers is split up, I think that we > still need some way of generati

Re: [Juju] Multiple sub service with a relation

I'd just like to chime in with a comment about the benefits and trade-offs of each approach. I don't think either approach is inherently more or less "Juju-ish". I think it just depends on your use-case. Using a structured data value for the config has the benefit that the current configuration

Re: [Juju] Proxy Charm examples

Sam, Ana, and Alberto, We tend not to have good examples of a proxy charm because they are much more limited than full charms and they also tend to be specific to particular use-cases. Thus, they are often one-off charms that don't end up in the store. If you're referring to https://jujucharms.c

Re: [Juju] Proxy Charm examples

though, to show off all of these considerations that one is faced with when using proxy charms that may not be apparent at first. On Fri, Aug 21, 2015 at 2:43 AM, Stuart Bishop wrote: > > On 21 August 2015 at 01:45, Cory Johns wrote: > > > >> Even as a proxy charm, this could

Re: [Juju] Proxy Charm examples

smarts in the proxy charm, it can be handled more gracefully than I did in my example. On Fri, Aug 21, 2015 at 10:08 AM, Cory Johns wrote: > Stuart, > > Excellent points. > > Supporting separate different data for different services is exactly what > I was thinking of when I men

[Review Queue] ibm-ib, mobicents-rescomm-charm, ethercalc, git

Greetings, Kevin, Amir, Andrew, and I attacked the Review Queue yesterday and threw in our two cents on several charm submissions by the excellent members of our community. + ibm-ib https://bugs.launchpad.net/charms/+bug/1452242 Following up on reviews by Matt and Adam, vsr addressed all of thei

[Review Queue] Suitecrm, and IBM XL C/C++

The Big Data team was able to get in some Review Queue time this week amongst preparing for our presence at Strata NY: Suitecrm https://bugs.launchpad.net/charms/+bug/1479471 The author addressed issues in our previous review. +1 promulgated. Welcome to the charmstore, SuiteCRM!

Re: Inconsistencies between juju debug-hooks and "normal" hook environment

Merlijn, That is an annoying inconsistency. It's probably related to debug-hooks bootstrapping itself via `juju ssh` which logs in as the ubuntu user since root ssh is disabled, as well as it being unlikely that the actual hook context is a login shell. I imagine the generate-config error is due

[Review Queue]

The Big Data team, including Kevin, Andrew, and myself, spent some time on the review queue today: - openbook - https://code.launchpad.net/~talligent/charms/trusty/openbook/trunk/+merge/267885 - This update changes web access URLs to use https. - Charm

Re: Inconsistencies between juju debug-hooks and "normal" hook environment

6 14:47:11 INFO config-changed A boilerplate environment >> configuration file has been written to /home/ubuntu/.juju/environments.yaml. >> >> Likewise if you want to create artifacts for the ubuntu user, use the "su >> - ubuntu" command. >> >> Hope that helps.

Re: [charms.reactive] http relation.available gets called on upgrade-charm hook, gives error.

Merlijn, You'll note that the docs for auto_accessors says that it's not a good idea to use with non-GLOBAL scoped relations, for this very reason. The problem is that t

Re: [charms.reactive] http relation.available gets called on upgrade-charm hook, gives error.

n.sebrec...@gmail.com> wrote: > Hi Cory > > > Thanks for the explanation. Is there a way to override the scope of the > http relation without forking the interface? > > > > Kind regards > Merlijn > > 2015-10-26 18:21 GMT+01:00 Cory Johns : > >> Mer

Re: [charms.reactive] http relation.available gets called on upgrade-charm hook, gives error.

ementing the same relations... This might even be possible with the > current relation, forwarding traffic for "hostname" to "private-ip"? I'm > not familiar enough with how juju determines hostname and private-ip to > know if this could work... Material for future d

Re: UOS 15.11 - Big Data session

hearing from you with questions or feedback. On Wed, Nov 4, 2015 at 1:02 PM, Antonio Rosales < antonio.rosa...@canonical.com> wrote: > Thanks Cory, I am also forwarding onto the Juju list if folks aren't > yet on the bigdata list. > > -thanks, > Antonio > > > On Wed,

[Review Queue] etcd, apache2, kibana, neutron-calico, bird

Greetings. The big data team (myself, Kevin, and Andrew) spent some time on the review queue yesterday and worked on the following reviews: - etcd - https://code.launchpad.net/~kubernetes/charms/trusty/etcd/trunk/+merge/275768 - This is a fairly simple update that

Python 3 default for all layered / reactive charms

https://github.com/juju-solutions/reactive-base-layer/issues/5 I am for using Python 3 in the base layer, but we need to address the effect that would have on the charms currently written using layers. I don't think the community effort to handle the switch at this point would be large, but we co

Re: The future of Charm Helpers

I feel like there's some confusion here about reactive vs. hookenv. I've never felt that there was any conflict between the two. The reactive pattern is intended to help your charm decide *when* to do something, while hookenv encapsulates the methods that it will use to actually *do* that thing.

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

On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen wrote: > Secondly, I'm mildly concerned with the namespace of choice (using the > shared charms. as the parent namespace). There may be a magical python 3ism > that resolves the mixed development + packaged use of common code (think > pip, virtualenvs,

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

However, further testing is always welcome. On Mon, Nov 23, 2015 at 2:01 PM, Cory Johns wrote: > > On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen > wrote: > >> Secondly, I'm mildly concerned with the namespace of choice (using the >> shared charms. as the parent nam

Re: Unit name issue with SFTP command.

You can get the full unit name with: unit_name = d.sentry['ibm-db2'][0].info['unit_name'] d.action_do(unit_name, ...) We should perhaps consider moving action_do to the UnitSentry so that it could instead be called as: d.sentry['ibm-db2'][0].action_do(...) On Fri, Nov 27, 2015 at 1:3

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

[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

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

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

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

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_

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

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

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

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

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

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

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

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

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

@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

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

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

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

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

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

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

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

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

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

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

  1   2   >