Re: Subordinate charms

2016-05-26 Thread André Moreira
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:
  principal:
interface: principal


And a subordinate:
metadata.yaml:
name: charm-supordinate
summary: 
maintainer: OMMITED
description: |
  
tags:
  - misc
subordinate: true
requires:
  principal:
interface: principal
scope: container

When I deploy both charms, as expected, only the "charm-principal" get a
unit. I cannot destroy the relation between them and, if I remove
"charm-subordinate", the unit of the principal charm is destroyed.

André



2016-05-26 18:45 GMT-03:00 José Antonio Rey :

> 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 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.
>>
>> 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 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 Kickstart
>> <
>> http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/
>> >
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 26 May 2016 at 22:36, André Moreira > > wrote:
>>
>> 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 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:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>>
>>
>> --
>> Bilal Baqar
>> MTS - PLUMgrid Inc.
>>
>>
>>
>>
>>
>> --
>>
>> 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:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>>
>>
>>
>> --
>> Bilal Baqar
>> MTS - PLUMgrid Inc.
>>
>>
>>
>>
>>
>> --
>>
>> Le doux charme de maint songe
>> Par leur bel art inventé
>> Sous les habits du mensonge
>> Nous offre la vérité.
>>  -La Fontaine
>>
>>
>>
>
> --
> José Antonio Rey
>



-- 

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: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: Subordinate charms

2016-05-26 Thread José Antonio Rey

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

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


goal, but you can always help by sponsoring the project
)

On 26 May 2016 at 22:36, André Moreira > wrote:

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 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:
https://lists.ubuntu.com/mailman/listinfo/juju




--
Bilal Baqar
MTS - PLUMgrid Inc.





--

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:
https://lists.ubuntu.com/mailman/listinfo/juju





--
Bilal Baqar
MTS - PLUMgrid Inc.





--

Le doux charme de maint songe
Par leur bel art inventé
Sous les habits du mensonge
Nous offre la vérité.
 -La Fontaine





--
José Antonio Rey

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


Re: Subordinate charms

2016-05-26 Thread André Moreira
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.
>
> 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 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 Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 26 May 2016 at 22:36, André Moreira  wrote:
>>
>>> 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 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:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>


 --
 Bilal Baqar
 MTS - PLUMgrid Inc.



>>>
>>>
>>> --
>>>
>>> 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:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
>
> --
> Bilal Baqar
> MTS - PLUMgrid Inc.
>
>
>


-- 

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: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: Subordinate charms

2016-05-26 Thread Bilal Baqar
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 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 Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 26 May 2016 at 22:36, André Moreira  wrote:
>
>> 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 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:
 https://lists.ubuntu.com/mailman/listinfo/juju


>>>
>>>
>>> --
>>> Bilal Baqar
>>> MTS - PLUMgrid Inc.
>>>
>>>
>>>
>>
>>
>> --
>>
>> 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:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>


-- 
Bilal Baqar
MTS - PLUMgrid Inc.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: Subordinate charms

2016-05-26 Thread Tom Barber
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 Kickstart

goal, but you can always help by sponsoring the project
)

On 26 May 2016 at 22:36, André Moreira  wrote:

> 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 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:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>>
>> --
>> Bilal Baqar
>> MTS - PLUMgrid Inc.
>>
>>
>>
>
>
> --
>
> 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:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: Subordinate charms

2016-05-26 Thread André Moreira
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 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:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
>
> --
> Bilal Baqar
> MTS - PLUMgrid Inc.
>
>
>


-- 

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: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: Subordinate charms

2016-05-26 Thread 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 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:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>


-- 
Bilal Baqar
MTS - PLUMgrid Inc.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Subordinate charms

2016-05-26 Thread 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 mensonge
Nous offre la vérité.
-La Fontaine
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: information needed for Mariadb Enterprise edition

2016-05-26 Thread Antonio Rosales
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 ppc64le and ran across some
>>> interesting bits.  I'm looping in the charm maintainer (dbart) for extra
>>> insights.
>>>
>>> First, MariaDB has both enterprise and community versions available for this
>>> charm to deploy.  Rajith, as you saw in the readme, you should be able to
>>> obtain credentials from the MariaDB Portal
>>> (https://mariadb.com/user/login?destination=my_portal/download).  However, 
>>> there was a recent change in the package signing key [0] that
>>> may affect installation.  Daniel, are these "enterprise.yaml" creation
>>> instructions in the charm readme still valid?:
>>>
>>> http://bazaar.launchpad.net/~charmers/charms/trusty/mariadb/trunk/view/head:/README.md#L46
>>>
>> No. Those are old instructions. I submitted an updated version of the
>> charm way back in November, but it looks like it never made it into
>> the charm store. As a first step, the version of the charm currently
>> in my repo (revision 28) should immediately be pushed to the charm
>> store: lp:~dbart/charms/trusty/mariadb/trunk
>>
>> The correct readme is here:
>>
>> http://bazaar.launchpad.net/~dbart/charms/trusty/mariadb/trunk/view/head:/README.md#L24
>>
>> ...but the instructions there won't work unless the charm in the store
>> is updated.
>>
>
> After looking into the issues some more, I've uncovered some new ones
> relating to deployment of MariaDB Enterprise on POWER8 with the
> updated version of the charm my launchpad repo. It's probably best to
> keep the old charm in the store as-is until I have the new version I'm
> working on ready. I should have it done early next week. POWER8
> deployment issues with the old charm, as long as you don't configure
> the enterprise.yaml file, and just 'juju deploy mariadb' are now
> resolved AFAIK thanks to some modifications I made today to the
> community MariaDB repositories.

While you are in the midst of updating have you taken a look at
Resources and Terms in Juju 2.0?

Resources is documented at:
https://jujucharms.com/docs/master/developer-terms

Terms is under final review at:
https://github.com/juju/docs/pull/1122/files
Specifically,
https://github.com/mbruzek/docs/blob/abd31c0962d73efea76a1381a857a279e27d384d/src/en/developer-resources.md


Thanks for the work on the MariaDB charm. If you have any questions
please post here or in #juju@Freenode.
-Antonio

>
> Thanks.
>
> --
> Daniel Bartholomew, MariaDB Release Manager
> MariaDB | http://mariadb.com
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

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


Re: information needed for Mariadb Enterprise edition

2016-05-26 Thread Daniel Bartholomew
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 maintainer (dbart) for extra
>> insights.
>>
>> First, MariaDB has both enterprise and community versions available for this
>> charm to deploy.  Rajith, as you saw in the readme, you should be able to
>> obtain credentials from the MariaDB Portal
>> (https://mariadb.com/user/login?destination=my_portal/download).  However, 
>> there was a recent change in the package signing key [0] that
>> may affect installation.  Daniel, are these "enterprise.yaml" creation
>> instructions in the charm readme still valid?:
>>
>> http://bazaar.launchpad.net/~charmers/charms/trusty/mariadb/trunk/view/head:/README.md#L46
>>
> No. Those are old instructions. I submitted an updated version of the
> charm way back in November, but it looks like it never made it into
> the charm store. As a first step, the version of the charm currently
> in my repo (revision 28) should immediately be pushed to the charm
> store: lp:~dbart/charms/trusty/mariadb/trunk
>
> The correct readme is here:
>
> http://bazaar.launchpad.net/~dbart/charms/trusty/mariadb/trunk/view/head:/README.md#L24
>
> ...but the instructions there won't work unless the charm in the store
> is updated.
>

After looking into the issues some more, I've uncovered some new ones
relating to deployment of MariaDB Enterprise on POWER8 with the
updated version of the charm my launchpad repo. It's probably best to
keep the old charm in the store as-is until I have the new version I'm
working on ready. I should have it done early next week. POWER8
deployment issues with the old charm, as long as you don't configure
the enterprise.yaml file, and just 'juju deploy mariadb' are now
resolved AFAIK thanks to some modifications I made today to the
community MariaDB repositories.

Thanks.

-- 
Daniel Bartholomew, MariaDB Release Manager
MariaDB | http://mariadb.com

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


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

2016-05-26 Thread Kevin Monroe
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 for joining)
   -


  
https://code.launchpad.net/~stub/charms/trusty/cassandra/wait-for-joining/+merge/286993
  -

  Seems like there is potential for deadlock; timeout suggested
  -

   Openjdk
   -

  https://github.com/juju-solutions/layer-openjdk/pull/3
  -

  Pass java relation data to other subordinates on a principal
  -

  +1, merged
  -

   Logstash
   -

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

  New charm submission. Logstash is designed to efficiently process a
  growing list of log, event, and unstructured data sources for
distribution
  into a variety of outputs, including Elasticsearch.
  -

  This is the second round of review for this charm. The authors have
  revised their charm and addressed all comments.
  -

  +1, now available at https://jujucharms.com/logstash/
  -

   Ganglia-node
   -


  
https://code.launchpad.net/~kwmonroe/charms/trusty/ganglia-node/remove-memcached/+merge/295769
  -

  Remove memcached from the unit test since it is not needed.
  -

  Ran tests, which executed successfully.
  -

  +1, merged.


Questions or comments?  Let us know in #juju on freenode.

Thanks, and welcome Pete!!
-Kevin Monroe
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


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

2016-05-26 Thread Marco Ceppi
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 as a resource

There are free software that require a EULA and free software not readily
distributed and consumable in an off-line environment where you only have a
mirror of that distros archive.

Marco

On Thu, May 26, 2016 at 10:02 AM Charles Butler <
charles.but...@canonical.com> wrote:

> 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 firewall)  As I just went through several rounds of this with our
> own firewall setup to onboard a vendor into OIL.  Additionally it removes a
> barrier to entry as many of these apps are behind registration walls or pay
> walls (needs citation). Anywhere that we can ease use for our consumers I
> am a loud +1.
>
> Further more, terms ensures their IP concerns are being handled
> appropriately. You don't agree to pay? you don't get to play.
>
>
>
>
> On Thu, May 26, 2016 at 9:28 AM Mark Shuttleworth  wrote:
>
>> 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 needed for FLOSS charms or
>> resources.
>>
>> Mark
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your service | www.jujucharms.com
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


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

2016-05-26 Thread Charles Butler
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 firewall)  As I just went through several rounds of this with our
own firewall setup to onboard a vendor into OIL.  Additionally it removes a
barrier to entry as many of these apps are behind registration walls or pay
walls (needs citation). Anywhere that we can ease use for our consumers I
am a loud +1.

Further more, terms ensures their IP concerns are being handled
appropriately. You don't agree to pay? you don't get to play.




On Thu, May 26, 2016 at 9:28 AM Mark Shuttleworth  wrote:

> 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 needed for FLOSS charms or
> resources.
>
> Mark
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


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

2016-05-26 Thread Mark Shuttleworth
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 needed for FLOSS charms or
resources.

Mark

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


issue after installing Mariadb Enterprise edition

2016-05-26 Thread Rajith P Venkata
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 
http://ftp.osuosl.org/pub/mariadb/repo/10.0/ubuntu/dists/trusty/InRelease 
Unable to find expected entry 'main/binary-ppc64el/Packages' in Release 
file (Wrong sources.list entry or malformed file)

2)After I got the above error I tried to follow the steps given in link: 
http://bazaar.launchpad.net/~dbart/charms/trusty/mariadb/trunk/view/head:/README.md#L24
 
 and used the mariadb code from lp:~dbart/charms/trusty/mariadb/trunk  or 
directly deploying from charm store, I am getting token error KeyError: 
'token , I have taken token from https://mariadb.com/my_portal


Attached log for 



Please help me in fixing above issue 



Rajith

IBM AIX Certified, OCPCertified


Cell- 9901966577
Email: rajith...@in.ibm.com



From:   Daniel Bartholomew 
To: Kevin Monroe 
Cc: Rajith P Venkata/India/IBM@IBMIN, juju , 
Mark Shuttleworth 
Date:   25-05-16 04:09 AM
Subject:Re: information needed for Mariadb Enterprise edition



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 maintainer (dbart) for extra
> insights.
>
> First, MariaDB has both enterprise and community versions available for 
this
> charm to deploy.  Rajith, as you saw in the readme, you should be able 
to
> obtain credentials from the MariaDB Portal
> (https://mariadb.com/user/login?destination=my_portal/download
>
> ).  However, there was a recent change in the package signing key [0] 
that
> may affect installation.  Daniel, are these "enterprise.yaml" creation
> instructions in the charm readme still valid?:
>
> 
http://bazaar.launchpad.net/~charmers/charms/trusty/mariadb/trunk/view/head:/README.md#L46

>

No. Those are old instructions. I submitted an updated version of the
charm way back in November, but it looks like it never made it into
the charm store. As a first step, the version of the charm currently
in my repo (revision 28) should immediately be pushed to the charm
store: lp:~dbart/charms/trusty/mariadb/trunk

The correct readme is here:

http://bazaar.launchpad.net/~dbart/charms/trusty/mariadb/trunk/view/head:/README.md#L24


...but the instructions there won't work unless the charm in the store
is updated.


> Second, line 382 of Rajith's log (http://paste.ubuntu.com/16514402/) 
shows that if the configured repo is ignored, the charm will continue to
> install mariadb-[server|client] from the trusty archives.  This will put
> mariadb-5.x on the unit, which may or may not be intended.  Perhaps the
> charm should warn the user if mariadb is installed from a location other
> than the configured repo?

A warning is something that could be added. In the log the configured
repo is ignored because it is trying to use the MariaDB repositories
(not the MariaDB Enterprise repositories). Only the MariaDB Enterprise
repositories have packages for the POWER8 architecture.


> Third, I was able to reproduce the behavior seen in Rajith's log where
> mariadb did not start successfully.  I think the default dataset-size
> configuration is too aggressive in some scenarios.  I've opened a bug 
[1] to
> track this.

It could be that the version of MariaDB in the Ubuntu repositories is
what is at fault here. It's the older 5.5 version, whereas the MariaDB
Enterprise version is 10.0. That said, I can definitely make the
change to the default config in the charm.


> Rajith, I know you specifically asked about the enterprise edition, and
> hopefully Daniel will be able to assist there.  That said, I have 
verified
> the community edition works when deploying from the charm store to a 
ppc64le
> container.  Let me know if I can be of any help to get that running in 
your
> environment.
>
> [0] https://jira.mariadb.org/browse/MDEV-9781

This MDEV is a red herring. It has no bearing on MariaDB Enterprise
and only affects MariaDB for Xenial and Debian Sid.

> [1] https://bugs.launchpad.net/charms/+source/mariadb/+bug/1583834

As mentioned above, assuming the default mem config is to blame, this
bug is simple to solve. I'll add the fix to the current update I'm
working on.

And speaking of updates, I'm working on an updated version of the
charm that installs the latest MariaDB from the community
repositories, including for POWER8, and only attempts to install
MariaDB Enterprise if the enterprise.yaml file is in place and called
during the deploy step.

Thanks.


> On Thu, May 19, 2016 at 8:01 AM, Mark Shuttleworth  
wrote:
>>
>>
>> Looks like MariaDB have an 

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

2016-05-26 Thread Curtis Hovey-Canonical
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 use the following commands to add the key and
> juju will try to use it when connecting to the machine:
> juju 1.x:  `juju authorized-keys add`
> juju 2.0:  `juju add-ssh-key`
>
> Let me know if this works for you.
> Thanks!
> -Cheryl
>
> On Sat, May 21, 2016 at 5:18 AM, phani shankar 
> wrote:
>>
>> Hi,
>>
>>  I am trying to use add-machine command to add a machine to juju
>> environment. The machine being added uses public/private key authentication.
>> I am facing following error.
>>
>> juju add-machine ssh:ubuntu@10.115.0.2
>> ERROR subprocess encountered error code 255 (Permission denied
>> (publickey).)
>>
>>
>> This works fine when I use the command to add a machine which does
>> password based authentication. I understand that it is due to not passing
>> the correct key credentials. But I am not sure how I can pass necessary
>> credentials. Please advise.

Does "ssh ubuntu@10.115.0.2" work

This command is using your localhost to do the initial connection. The
error can be from your localhost, not from the
state-server/controller.

Once your *client* juju has entered the machine it checks that jujud
is not installed, the machine can connection to the
state-server/controller over the private address, and there is an
ubuntu user. Your juju client will provision the machine. Once
complete, the machine will talk to the state-server/controller
normally.


-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui

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


Re: Quick win - juju check

2016-05-26 Thread John Meinel
>
> ...
>


> 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: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Quick win - juju check

2016-05-26 Thread Stuart Bishop
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
https://bugs.launchpad.net/juju-core/+bug/1445066 (hey, you filed that
bug).

Adding a common option for the *-set and other hook environment tools
to get their data from stdin, rather than the command line, from
https://bugs.launchpad.net/juju-core/+bug/1274460

My favourite is as always 'juju wait', but that might not turn out to
be trivial.

-- 
Stuart Bishop 

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


Re: admin model now called "controller" model

2016-05-26 Thread Rick Harding
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 on those so that he can be
aware as Conjure up is a big stakeholder here. Alexis, can you get someone
to run through them please? I'm thinking of things like
s/services/applications, status output format, bundle output format,
defaulting to the non-list commands, etc.

On Wed, May 25, 2016 at 12:13 PM Nate Finch 
wrote:

> I believe it was discussed at the Vancouver sprint.
>
> On Wed, May 25, 2016 at 12:09 PM Adam Stokes 
> wrote:
>
>> Where was this discussed?
>>
>> On Wed, May 25, 2016, 10:56 AM Nate Finch 
>> wrote:
>>
>>> The change is merging as we speak, so if you have scripts etc that need
>>> to be updated, do so before pulling master.
>>>
>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev


Re: Fixing "juju help commands"

2016-05-26 Thread Rick Harding
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 because of the set. Some things are read/write properties
and those are get/set. list vs show is meant to be around entities in the
Juju model. You can list them to see tabular output of info about the
entity and you can show them for single details. I appreciate the config
case seems odd, but config isn't a root model entity, it's a property and
you can set that and you can't set other entities in the model. I think it
makes sense to keep these.

The list one is tricky. list is there to be consistent, help users discover
entities in the model (list-), and to help easily see things in the
help text as it jumps out as a common pattern (you can list, show, etc
things). However, it was agreed that leaving off the list should default to
the list output. It reads nicer and seems to make the most sense for users
that know enough Juju to know what they're doing.

With that in mind, hiding them behind an --alias or what not seems counter
productive. It's not there in the main output for new users, the ones we're
aiming to serve. With this in mind, it makes the most sense to just remove
them then, which I don't personally like, but I think makes things the most
clean and with the most consistent story.

On Wed, May 25, 2016 at 2:52 PM Nate Finch  wrote:

> +1 ... one and only one way to do something is a lot easier to
> understand.  Either we like juju list-foos or we like juju foos... pick one
> and move on.  This feels like two camps agreed to disagree and just kept
> both.
>
> On Wed, May 25, 2016 at 10:12 AM Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com> wrote:
>
>>
>> I think this has come up before on this list, but: isn't having 2 sets of
>> commands in the first place a design smell? If we need aliases because
>> users aren't using the originals, then  shouldn't we fix the original
>> commands?
>>
>> Tim Penhey  writes:
>>
>> > On 25/05/16 00:12, Marco Ceppi wrote:
>> >> Even if you don't expect people to run them, hidding them seems
>> >> awkward.
>> >> Better to simply educate with good help output about what the
>> >> command
>> >> does and when/why use the command.
>> >
>> > Was thinking, perhaps it would be better to have a feature flag to use
>> > the "hidden" commands instead of the ability to hide commands.
>> >
>> > If you set the feature flag, you get the additional commands, and they
>> > show up in help etc.  That way a way to get users to run them could be
>> > something like:
>> >
>> >   JUJU_FEATURE_FLAGS=dev-debug juju dump-model
>> >
>> > or something like that.
>> >
>> > Tim
>>
>> --
>> Katherine
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev