Re: Subordinate charms

José, They are charms I created to deploy some services that I have. I have a "principal" charm with something like this (I had to change the actual names): metadata.yaml: name: charm-principal summary: maintainer: OMMITED description: | tags: - misc subordinate: false provides:

Re: Subordinate charms

André, What are you installing and trying to remove? I will do some quick testing around, and would like to reproduce the same scenario that you have. On 05/26/2016 04:43 PM, André Moreira wrote: Hi Bilal, I think that is not possible. When I try, I receive this: "You may not remove a

Re: Subordinate charms

Hi Bilal, I think that is not possible. When I try, I receive this: "You may not remove a subordinate relation." André 2016-05-26 18:41 GMT-03:00 Bilal Baqar : > Try removing the relation between the two. The unit of the subordinate > charm will be removed from that node.

Re: Subordinate charms

Try removing the relation between the two. The unit of the subordinate charm will be removed from that node. Regards On Fri, May 27, 2016 at 2:38 AM, Tom Barber wrote: > Hi Andre > > Can you give us a clue what you are installing/uninstalling because I > believe Bilal

Re: Subordinate charms

Hi Andre Can you give us a clue what you are installing/uninstalling because I believe Bilal is correct, I've not see it wipe out the parent charms either. Tom -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our

Re: Subordinate charms

Using this, it also removes the unit of the charm it is subordinated to. 2016-05-26 18:34 GMT-03:00 Bilal Baqar : > Try the normal charm remove command: > *juju remove-service * > > Regards > > 2016-05-27 2:24 GMT+05:00 André Moreira : > >> How can I

Re: Subordinate charms

Try the normal charm remove command: *juju remove-service * Regards 2016-05-27 2:24 GMT+05:00 André Moreira : > How can I remove a subordinate charm without removing the principal? > > -- > > Le doux charme de maint songe > Par leur bel art inventé > Sous les habits du

Subordinate charms

How can I remove a subordinate charm without removing the principal? -- Le doux charme de maint songe Par leur bel art inventé Sous les habits du mensonge Nous offre la vérité. -La Fontaine -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at:

Re: information needed for Mariadb Enterprise edition

On Thu, May 26, 2016 at 1:34 PM, Daniel Bartholomew wrote: > On Tue, May 24, 2016 at 6:38 PM, Daniel Bartholomew wrote: >> On Thu, May 19, 2016 at 7:46 PM, Kevin Monroe >> wrote: >>> I recently took a look at the mariadb charm on

Re: information needed for Mariadb Enterprise edition

On Tue, May 24, 2016 at 6:38 PM, Daniel Bartholomew wrote: > On Thu, May 19, 2016 at 7:46 PM, Kevin Monroe > wrote: >> I recently took a look at the mariadb charm on ppc64le and ran across some >> interesting bits. I'm looping in the charm

[Review Queue] cassandra (x2), openjdk, logstash, ganglia-node

Hi folks, Cory, Kostas, new guy Pete, and myself took a trip down the queue today. Here's what we found: - cassandra (fix disk checks) - https://code.launchpad.net/~stub/charms/trusty/cassandra/fix-diskchecks/+merge/283760 - +1, merged - cassandra (wait

Re: Charm Store Policy Update: Propritary applications usage of Terms and Resources

I don't think this needs to be scoped to just proprietary charms. It can be better scoped to: Any software which requires acceptance of a license or EULA has to have that as a term on the charm Any software which installs components from outside of a distributions archive needs to represent that

Re: Charm Store Policy Update: Propritary applications usage of Terms and Resources

I'm +1 to requiring terms and resources for prop. applications. This will effectively funnel our new onboarding efforts of these vendors into the juju 2.0 path, and start them off using best practices - which will really lend a hand to the robustness of their deployment (see: behind the corp

Re: Charm Store Policy Update: Propritary applications usage of Terms and Resources

On 26/05/16 00:21, Tom Barber wrote: > > I think Terms are good but terms for open source is overkill. > > For example if I apt install openjdk I wouldn't accept any terms > during the install process, but if I apt install oracle-jdk I would. > > Agreed, no acknowledgement of terms should be

issue after installing Mariadb Enterprise edition

Hi Thanks for earlier information. I have below issue : 1) After Installing Mariadb Enterprise edition on to power 8 machine from charm store, I am trying to install any layer charm from charm store on the same machine as I have dependency with mariadb, I am getting error :Failed to fetch

Re: Unable to add machine that uses public/private key based authentication

On Wed, May 25, 2016 at 5:11 PM, Cheryl Jennings wrote: > Hi Phani, > > Is the key used for the machine known to juju? You can view the ssh keys > with `juju authorized-keys list` for juju 1.x, and `juju list-ssh-keys` for > juju 2.0. > > If it's not there, you can

Re: Quick win - juju check

> > ... > > My favourite is as always 'juju wait', but that might not turn out to > be trivial. > > While not on our "trivial" set, it is concretely on our TODO for 16.10. John =:-> -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

Re: Quick win - juju check

On 24 May 2016 at 11:14, Tim Penhey wrote: > We talked quite a bit in Vancouver about quick wins. Things we could get > into Juju that are simple to write that add quick value. For trivial, quick wins consider: 'juju do --wait', from

Re: admin model now called "controller" model

This was brought up via a bug before the sprint and confirmed during the sprint. Apolgoies Adam, while the bug was public, we failed to reach out as this effects conjure up. There are some other requests that the team are processing. I'd like to ask that someone from Core meet with and Prep Adam

Re: Fixing "juju help commands"

Some feedback If we have a debug command we should just show the debug commands. If we don't want users to have them ootb they should be plugins then I would think. This assumes the commands can't do anything destructive or otherwise harm a running model/etc by being run. The get is there