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

[Merlijn Sebrechts]

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 :

> 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 there's no way which unit's or
> service's host and port you are trying to get, since there could be many.
> If it's true that there should only be a single connected service on this
> relation, then you should switch it to  GLOBAL scope to indicate that.
> Otherwise, you need to be handling the possibility of multiple connected
> units explicitly.
>
> See
> https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L74
> for an example of how an interface layer should handle multiple
> conversations.
>
> On Mon, Oct 26, 2015 at 5:58 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> I have the following piece of code that reacts to the
>> httprelation.available hook (called rest2jfed in this case):
>>
>>
>> @when('rest2jfed.available')
>> def setup_rest2jfed(rest2jfed):
>> hostname = rest2jfed.host()
>> port = rest2jfed.port()
>> # Do some stuff with hostname and port
>> hookenv.status_set('active', 'Ready')
>>
>>
>> This piece of code gets called on the upgrade-charm hook. This throws an
>> error because there is not a relationship context.
>>
>>   File "lib/charms/reactive/relations.py", line 88, in __accessor
>> return self.get_remote(field)
>>   File "lib/charms/reactive/relations.py", line 308, in get_remote
>> return self.conversation(scope).get_remote(key, default)
>>   File "lib/charms/reactive/relations.py", line 255, in conversation
>> raise ValueError('Unable to determine default scope: no current hook
>> or global scope')
>>
>> Am I using this relation wrong or is this a bug?
>>
>>
>>
>> Kind regards
>> Merlijn
>>
>> --
>> 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

charm license requirements with multi-licensed payloads

[Kevin Monroe]

Hi folks,

Our big data charms (apache licensed) deploy Hadoop (apache licensed).
Hadoop supports various compression codecs, with one of the more popular
being lzo.  lzo is GPLv2 licensed and therefore not distributed with Hadoop.

As a charm author, what is my licensing obligation if I want my charm to
install lzo on top of Hadoop?  Fwiw, the charm would fetch both hadoop.tgz
and lzo.tgz from an external repo at install-time, so neither payload is
bundled into the charm.  I assume this absolves me of any special licensing
in my charm source, but I'd like to get a +1 on that.

As the maintainer of an external repo, are there licensing obligations for
hosting charm payloads?  I assume I could put a NOTICE in the root of the
repo that says "hadoop.tgz is apache licensed (link to license).  lzo.tgz
is gplv2 (link to source and license)."

The sticky part to me is that no one would likely find my NOTICE in the
repo, so I'm curious if I should put it directly in the charm source.  Is
anyone else dealing with charm payloads of differing licenses?  How did you
handle it?

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

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

[Cory Johns]

Merlijn,

Unfortunately, the correct solution for the issue with the HTTP interface
layer is to change how the requires side works a bit.  I went ahead and
made those changes and moved the repo (with Ben's permission) to
https://github.com/juju-solutions/interface-http (which will also allow
easier PR submissions).  I added a README with example usage but it will
require a bit of change to your code.  I also updated
interfaces.juju.solutions so that the next time you do a `charm build`, you
should get the new version of the interface.

Let me know if you run into any issues with that implementation, and of
course PRs are welcome.

As an aside, I just wanted to note that the http interface protocol is a
good example of one that has suffered for the lack of a standard
implementation like what the interface layer gives us.  When trying to
determine how to implement that side of the relation, it became apparent
that each charm that supports it seems to have added its own extensions to
the protocol (e.g., haproxy accepts entire HA proxy YAML configuration
blocks, Apache2 supports overriding the service grouping, etc.).  I only
implemented the most basic, common use-case as I saw it; if we, as a
community, determine that it needs to support more, we can do so, but
things like the HA proxy config block should really be in a separate
interface protocol (which could be a superset, with a negotiation protocol).

On Tue, Oct 27, 2015 at 5:04 AM, Merlijn Sebrechts <
merlijn.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 :
>
>> 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 there's no way which unit's or
>> service's host and port you are trying to get, since there could be many.
>> If it's true that there should only be a single connected service on this
>> relation, then you should switch it to  GLOBAL scope to indicate that.
>> Otherwise, you need to be handling the possibility of multiple connected
>> units explicitly.
>>
>> See
>> https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L74
>> for an example of how an interface layer should handle multiple
>> conversations.
>>
>> On Mon, Oct 26, 2015 at 5:58 AM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi all
>>>
>>>
>>> I have the following piece of code that reacts to the
>>> httprelation.available hook (called rest2jfed in this case):
>>>
>>>
>>> @when('rest2jfed.available')
>>> def setup_rest2jfed(rest2jfed):
>>> hostname = rest2jfed.host()
>>> port = rest2jfed.port()
>>> # Do some stuff with hostname and port
>>> hookenv.status_set('active', 'Ready')
>>>
>>>
>>> This piece of code gets called on the upgrade-charm hook. This throws an
>>> error because there is not a relationship context.
>>>
>>>   File "lib/charms/reactive/relations.py", line 88, in __accessor
>>> return self.get_remote(field)
>>>   File "lib/charms/reactive/relations.py", line 308, in get_remote
>>> return self.conversation(scope).get_remote(key, default)
>>>   File "lib/charms/reactive/relations.py", line 255, in conversation
>>> raise ValueError('Unable to determine default scope: no current hook
>>> or global scope')
>>>
>>> Am I using this relation wrong or is this a bug?
>>>
>>>
>>>
>>> Kind regards
>>> Merlijn
>>>
>>> --
>>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: charm license requirements with multi-licensed payloads

[José Antonio Rey]

Hey Kevin,

When you write a charm and include a copyright file, what you are licensing
are the lines of code that you write in the charm, not the software itself.
You may choose any license you want.

If you want to specify the license each piece of software uses, you can do
so in the README file, so users know what license each piece holds.

--
José Antonio Rey

On Tue, Oct 27, 2015, 12:01 Kevin Monroe  wrote:

> Hi folks,
>
> Our big data charms (apache licensed) deploy Hadoop (apache licensed).
> Hadoop supports various compression codecs, with one of the more popular
> being lzo.  lzo is GPLv2 licensed and therefore not distributed with Hadoop.
>
> As a charm author, what is my licensing obligation if I want my charm to
> install lzo on top of Hadoop?  Fwiw, the charm would fetch both hadoop.tgz
> and lzo.tgz from an external repo at install-time, so neither payload is
> bundled into the charm.  I assume this absolves me of any special licensing
> in my charm source, but I'd like to get a +1 on that.
>
> As the maintainer of an external repo, are there licensing obligations for
> hosting charm payloads?  I assume I could put a NOTICE in the root of the
> repo that says "hadoop.tgz is apache licensed (link to license).  lzo.tgz
> is gplv2 (link to source and license)."
>
> The sticky part to me is that no one would likely find my NOTICE in the
> repo, so I'm curious if I should put it directly in the charm source.  Is
> anyone else dealing with charm payloads of differing licenses?  How did you
> handle it?
>
> Thanks,
> -Kevin Monroe
> --
> 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: How to make Juju High Availability work properly?

[Cheryl Jennings]

Hi Leon,

I was able to recreate the "lost" agent in a simple environment and have
opened up a bug for it:  https://bugs.launchpad.net/juju-core/+bug/1510651

Since my environment was pretty simple, I didn't run into any hook errors.
Could you attach the unit logs from some of the services with errors into
the bug above?  The unit logs will be in /var/log/juju/unit-* on the
respective machines.

Thanks!
-Cheryl

On Mon, Oct 26, 2015 at 11:20 AM, Mark Ramm-Christensen (Canonical.com) <
mark.ramm-christen...@canonical.com> wrote:

> Thanks for following up!
>
> We will take a look at the logs and get back to you soon.
>
> --Mark Ramm
>
> On Mon, Oct 26, 2015 at 4:41 AM, 曾建銘  wrote:
>
>> Hi Mark & Marco,
>>
>> Really appreciate your help. I have already provide the logs to Marco.
>>
>> Hope it could help you to enhance the Juju HA feature.
>>
>> Sincerely yours,
>> Leon
>>
>> On Sat, Oct 24, 2015 at 7:03 AM, Mark Shuttleworth 
>> wrote:
>>
>>> On 23/10/15 00:54, 曾建銘 wrote:
>>> > Was the juju doing something for fixing specific problem? I think that
>>> > service on failed node should only become lost and not interfere
>>> services
>>> > on workings nodes. But it didn't act as I expected.
>>> >
>>> > By the way, I used Juju to deploy OpenStack, so I deployed a lot of
>>> charms
>>> > on it. Is that matter?
>>>
>>> No, the scale of the model you're managing should not affect HA in any
>>> way.
>>>
>>> The team is trying to reproduce your situation by repeatedly causing
>>> failover, but I'm told has not seen anything like your symptoms. Can you
>>> provide copies of logs to Marco?
>>>
>>> Mark
>>>
>>
>>
>> --
>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Merlijn Sebrechts]

Hi Cory


Thanks for this! I'll try this out as soon as I get the time.

I completely agree that the HA proxy block config should be in a seperate
interface protocol. I would even go as far as to say that a block of
application-specific config should not be passed between services. The way
the apache2 charm relations are implemented now makes it impossible to
create an Nginx Charm that implements the same relations. I think this is a
real shame, since that's one of the beauties of Juju relations...

I have been thinking of creating a new Apache2 Charm that has relations
that are not Apache specific. One of the uses for this would be an Apache2
server acting as a vhost-based reverse-proxy for multiple services
connected using the http relation. Each service could specify a hostname.
The Apache2 service forwards the traffic based on hostname. If the relation
is generic enough, it would be possible to create an Nginx Charm
implementing 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 discussion?



Kind regards
Merlijn

2015-10-27 18:01 GMT+01:00 Cory Johns :

> Merlijn,
>
> Unfortunately, the correct solution for the issue with the HTTP interface
> layer is to change how the requires side works a bit.  I went ahead and
> made those changes and moved the repo (with Ben's permission) to
> https://github.com/juju-solutions/interface-http (which will also allow
> easier PR submissions).  I added a README with example usage but it will
> require a bit of change to your code.  I also updated
> interfaces.juju.solutions so that the next time you do a `charm build`, you
> should get the new version of the interface.
>
> Let me know if you run into any issues with that implementation, and of
> course PRs are welcome.
>
> As an aside, I just wanted to note that the http interface protocol is a
> good example of one that has suffered for the lack of a standard
> implementation like what the interface layer gives us.  When trying to
> determine how to implement that side of the relation, it became apparent
> that each charm that supports it seems to have added its own extensions to
> the protocol (e.g., haproxy accepts entire HA proxy YAML configuration
> blocks, Apache2 supports overriding the service grouping, etc.).  I only
> implemented the most basic, common use-case as I saw it; if we, as a
> community, determine that it needs to support more, we can do so, but
> things like the HA proxy config block should really be in a separate
> interface protocol (which could be a superset, with a negotiation protocol).
>
> On Tue, Oct 27, 2015 at 5:04 AM, Merlijn Sebrechts <
> merlijn.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 :
>>
>>> 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 there's no way which unit's or
>>> service's host and port you are trying to get, since there could be many.
>>> If it's true that there should only be a single connected service on this
>>> relation, then you should switch it to  GLOBAL scope to indicate that.
>>> Otherwise, you need to be handling the possibility of multiple connected
>>> units explicitly.
>>>
>>> See
>>> https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L74
>>> for an example of how an interface layer should handle multiple
>>> conversations.
>>>
>>> On Mon, Oct 26, 2015 at 5:58 AM, Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
 Hi all


 I have the following piece of code that reacts to the
 httprelation.available hook (called rest2jfed in this case):


 @when('rest2jfed.available')
 def setup_rest2jfed(rest2jfed):
 hostname = rest2jfed.host()
 port = rest2jfed.port()
 # Do some stuff with hostname and port
 hookenv.status_set('active', 'Ready')


 This piece of code gets called on the upgrade-charm hook. This throws
 an error because there is not a relationship context.

   File "lib/charms/reactive/relations.py", line 88, in __accessor
 return self.get_remote(field)
   File "lib/charms/reactive/relations.py", line 308, in get_remote
 return self.conversation(scope).get_remote(key, default)
   File "lib/charms/reactive/relations.py", line 255, in conversation
 raise ValueError('Unable to determine default scope: no current
 hook or global scope')

Re: charm license requirements with multi-licensed payloads

[Merlijn Sebrechts]

Thanks, José! I was curious about this too.


A follow-up on this question: I have a Charm repo
 that includes Charms from
different sources with patches. Some of these Charms are licensed
differently, some require copyleft and some don't. Now, I do it this way: I
have my own licence at the top of the repo. Charms from different sources
have their own licence at the top of the Charm.

This way, and I am only guessing this is how copyright works, when I patch
a Charm, the patch automatically has the same licence as the Charm. If the
Charm doesn't have a license, the repo licence is applied. Am I correct?



Kind regards
Merlijn

2015-10-27 18:12 GMT+01:00 José Antonio Rey :

> Hey Kevin,
>
> When you write a charm and include a copyright file, what you are
> licensing are the lines of code that you write in the charm, not the
> software itself. You may choose any license you want.
>
> If you want to specify the license each piece of software uses, you can do
> so in the README file, so users know what license each piece holds.
>
> --
> José Antonio Rey
>
> On Tue, Oct 27, 2015, 12:01 Kevin Monroe 
> wrote:
>
>> Hi folks,
>>
>> Our big data charms (apache licensed) deploy Hadoop (apache licensed).
>> Hadoop supports various compression codecs, with one of the more popular
>> being lzo.  lzo is GPLv2 licensed and therefore not distributed with Hadoop.
>>
>> As a charm author, what is my licensing obligation if I want my charm to
>> install lzo on top of Hadoop?  Fwiw, the charm would fetch both hadoop.tgz
>> and lzo.tgz from an external repo at install-time, so neither payload is
>> bundled into the charm.  I assume this absolves me of any special licensing
>> in my charm source, but I'd like to get a +1 on that.
>>
>> As the maintainer of an external repo, are there licensing obligations
>> for hosting charm payloads?  I assume I could put a NOTICE in the root of
>> the repo that says "hadoop.tgz is apache licensed (link to license).
>>  lzo.tgz is gplv2 (link to source and license)."
>>
>> The sticky part to me is that no one would likely find my NOTICE in the
>> repo, so I'm curious if I should put it directly in the charm source.  Is
>> anyone else dealing with charm payloads of differing licenses?  How did you
>> handle it?
>>
>> Thanks,
>> -Kevin Monroe
>> --
>> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Cory Johns]

Merlijn,

Be aware that I had to make some small changes to the interface since my
previous email.  In particular, I had to remove the "changed" state, as it
does not function in any way like it was intended.  I updated the example
in the README to achieve the same end result, however.

I agree that charms should strive for general interface protocols whenever
possible, to ensure portability and compatibility.  However, I do think
that there are use-cases that couldn't be satisfied if we kept all
interface protocols completely generic.  As long as the specific extensions
are clearly indicated (e.g., using http-apache instead of plain http) or
possibly if there is a negotiation protocol that can degrade gracefully to
the common protocol, it could potentially work.

I think your use-case is a good one, and I think it will require some
additions to the http interface layer as it stands.  Currently, the
hostname is just the private-address of the remove unit, and the units are
grouped naturally by their service name.  It does seem like it would be
useful to be able to specify a public-facing host name and group by that.
I'm not sure if that's what the current Apache2 charm does with the
service_name override or not.

On Tue, Oct 27, 2015 at 3:25 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Cory
>
>
> Thanks for this! I'll try this out as soon as I get the time.
>
> I completely agree that the HA proxy block config should be in a seperate
> interface protocol. I would even go as far as to say that a block of
> application-specific config should not be passed between services. The way
> the apache2 charm relations are implemented now makes it impossible to
> create an Nginx Charm that implements the same relations. I think this is a
> real shame, since that's one of the beauties of Juju relations...
>
> I have been thinking of creating a new Apache2 Charm that has relations
> that are not Apache specific. One of the uses for this would be an Apache2
> server acting as a vhost-based reverse-proxy for multiple services
> connected using the http relation. Each service could specify a hostname.
> The Apache2 service forwards the traffic based on hostname. If the relation
> is generic enough, it would be possible to create an Nginx Charm
> implementing 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 discussion?
>
>
>
> Kind regards
> Merlijn
>
> 2015-10-27 18:01 GMT+01:00 Cory Johns :
>
>> Merlijn,
>>
>> Unfortunately, the correct solution for the issue with the HTTP interface
>> layer is to change how the requires side works a bit.  I went ahead and
>> made those changes and moved the repo (with Ben's permission) to
>> https://github.com/juju-solutions/interface-http (which will also allow
>> easier PR submissions).  I added a README with example usage but it will
>> require a bit of change to your code.  I also updated
>> interfaces.juju.solutions so that the next time you do a `charm build`, you
>> should get the new version of the interface.
>>
>> Let me know if you run into any issues with that implementation, and of
>> course PRs are welcome.
>>
>> As an aside, I just wanted to note that the http interface protocol is a
>> good example of one that has suffered for the lack of a standard
>> implementation like what the interface layer gives us.  When trying to
>> determine how to implement that side of the relation, it became apparent
>> that each charm that supports it seems to have added its own extensions to
>> the protocol (e.g., haproxy accepts entire HA proxy YAML configuration
>> blocks, Apache2 supports overriding the service grouping, etc.).  I only
>> implemented the most basic, common use-case as I saw it; if we, as a
>> community, determine that it needs to support more, we can do so, but
>> things like the HA proxy config block should really be in a separate
>> interface protocol (which could be a superset, with a negotiation protocol).
>>
>> On Tue, Oct 27, 2015 at 5:04 AM, Merlijn Sebrechts <
>> merlijn.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 :
>>>
 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 there's no way which unit's or
 service's host and port you are trying to get, since there could be many.
 If it's true that there should only be a single connected service on th

Re: charm license requirements with multi-licensed payloads

[José Antonio Rey]

That is right. When you do a patch and include it inside a charm, what you
are doing is a contribution to the pre-existing code, hence inheriting the
license from another charm.

If it doesn't have a license and it's been released, I would assume a
public domain license until a license is specified. Of course, be polite
and ask the author first - they may have missed a bzr add!

--
José Antonio Rey

On Tue, Oct 27, 2015, 14:37 Merlijn Sebrechts 
wrote:

> Thanks, José! I was curious about this too.
>
>
> A follow-up on this question: I have a Charm repo
>  that includes Charms from
> different sources with patches. Some of these Charms are licensed
> differently, some require copyleft and some don't. Now, I do it this way: I
> have my own licence at the top of the repo. Charms from different sources
> have their own licence at the top of the Charm.
>
> This way, and I am only guessing this is how copyright works, when I patch
> a Charm, the patch automatically has the same licence as the Charm. If the
> Charm doesn't have a license, the repo licence is applied. Am I correct?
>
>
>
> Kind regards
> Merlijn
>
> 2015-10-27 18:12 GMT+01:00 José Antonio Rey :
>
>> Hey Kevin,
>>
>> When you write a charm and include a copyright file, what you are
>> licensing are the lines of code that you write in the charm, not the
>> software itself. You may choose any license you want.
>>
>> If you want to specify the license each piece of software uses, you can
>> do so in the README file, so users know what license each piece holds.
>>
>> --
>> José Antonio Rey
>>
>> On Tue, Oct 27, 2015, 12:01 Kevin Monroe 
>> wrote:
>>
>>> Hi folks,
>>>
>>> Our big data charms (apache licensed) deploy Hadoop (apache licensed).
>>> Hadoop supports various compression codecs, with one of the more popular
>>> being lzo.  lzo is GPLv2 licensed and therefore not distributed with Hadoop.
>>>
>>> As a charm author, what is my licensing obligation if I want my charm to
>>> install lzo on top of Hadoop?  Fwiw, the charm would fetch both hadoop.tgz
>>> and lzo.tgz from an external repo at install-time, so neither payload is
>>> bundled into the charm.  I assume this absolves me of any special licensing
>>> in my charm source, but I'd like to get a +1 on that.
>>>
>>> As the maintainer of an external repo, are there licensing obligations
>>> for hosting charm payloads?  I assume I could put a NOTICE in the root of
>>> the repo that says "hadoop.tgz is apache licensed (link to license).
>>>  lzo.tgz is gplv2 (link to source and license)."
>>>
>>> The sticky part to me is that no one would likely find my NOTICE in the
>>> repo, so I'm curious if I should put it directly in the charm source.  Is
>>> anyone else dealing with charm payloads of differing licenses?  How did you
>>> handle it?
>>>
>>> Thanks,
>>> -Kevin Monroe
>>> --
>>> 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
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Follow up - "Missing contrib.amulet in charm-helpers-hooks"

[David Ames]

James,

Some responses in line:

On 10/26/2015 11:38 PM, James Beedy wrote:

As a follow up to my earlier post "Missing contrib.amulet in 
charm-helpers-hooks” I want to clarify a few things, as well as hopefully get to the 
bottom of some hook errors I am experiencing. Earlier, I mentioned that
I thought I had found the cause of my hook errors. I realize now that what 
I thought was causing my shared-db-relation-changed hook error is most likely 
entirely unrelated. I apologize for any misconception I may of had there. What 
definitely is happening though, is that I am experiencing 
shared-db-relation-changed hook errors amongst a few other inconsistencies for 
the charms heat, glance and neutron-api, when related to percona-cluster, and 
ampq-relation-changed hook errors for rabbitmq-server on ampq-relation-changed 
for cinder and heat as well.

  My setup is as follows:

deployer-ha.yaml: http://paste.ubuntu.com/12977516/
rels.py: http://paste.ubuntu.com/12977480/
ha_rels.yaml: http://paste.ubuntu.com/12977481/
primary_rels.yaml: http://paste.ubuntu.com/12977487/


I am kicking off my deploy with the following procedure:

1. '$ juju-deployer -c deployer-ha.yaml --no-relations'
2. '$ ./rels.py ha_rels.yaml'
3. '$ ./rels.py primary_rels.yaml'

* Once #1 finishes, and before running #2, I wait for my env to settle and look 
like: http://paste.ubuntu.com/12977466/
* After running #2, my env settles and looks like: 
http://paste.ubuntu.com/12977494/
* After running #3, my env settles and looks like: 
http://paste.ubuntu.com/12977593/



I am curious why you are separating out relations from the juju-deployer 
run. Have you had better success with that?



As you can see, after #3 I have a few incomplete relations, a few hook errors, 
and a few
hooks stuck in executing.

To gain some insight here, I opened up a few new terminal windows and decided 
to debug the
hooks in question.

The output of debugging the relation changed hook for glance/0 is as follows: 
http://paste.ubuntu.com/12977635/

Notice the line 'No handlers could be found for logger "oslo_config.cfg"' is 
the last bit of
information I can get here before what looks like an sql connection failure...I 
assumed the
handlers not being available for the logger might of been blockingthis is 
what led
me on the wild goose chase of the missing import:-)


The 'No handlers could be found for logger' is not the issue. That is 
related to logging and not the cause of the problems.



Your logs show two failures that caused all the rest:


cat /var/log/glance/api.log shows : http://paste.ubuntu.com/12977656/

cat /var/log/juju/unit-glance-0.log shows: http://paste.ubuntu.com/12977662/


Debugging the heat shared-db-relation-changed hook I get the following output: 
http://paste.ubuntu.com/12977674/

Heat logs:

cat /var/log/heat/heat-engine.log : http://paste.ubuntu.com/12977676/
cat /var/log/heat/heat-api.log : http://paste.ubuntu.com/12977678/
cat /var/log/heat/heat-api-cfn.log : http://paste.ubuntu.com/12977682/
cat /var/log/juju/unit-heat-0.log : http://paste.ubuntu.com/12977694/


Debugging neutron-api shared-db-relation-changed hook I get the output : 
http://paste.ubuntu.com/12977718/

cat /var/log/juju/unit-neutron-api-0.log : http://paste.ubuntu.com/12977720/
cat /var/log/neutron/neutron-server.log : http://paste.ubuntu.com/12977734/



First failure is percona-cluster. All of the above logs show problems 
connecting to mysql/percona-cluster. So the fault is with 
percona-cluster some where.


Can you provide logs for the percona-cluster service? And/or do some 
debugging there?



Debugging rabbitmq-server:

cat /var/log/juju/unit-rabbitmq-server-2.log: http://paste.ubuntu.com/12977743/


Hopefully this helps give a slightly better understanding of the hook errors 
I'm experiencing. Any insight would be greatly appreciated!


Second, is rabbitmq. We have been on a crusade to resolved rabbitmq 
clustering bugs. In this case it seems rabbitmq was down or stopped when 
then charm attempted to check status. I'll take a look and see if there 
is anything obvious.



Thank you all for your time,

James


So to summarize, two core services appear to have failed: 
percona-cluster and rabbitmq-server. Since most other services rely on 
these you see the various other failures including incomplete relations 
and failed relation hook runs.


If you can provide some logs for percona-cluster I'll see if there is 
anything obvious. I'll also look at rabbitmq.


--
David Ames



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