Also:
"scope: global" vs "scope: container" in metadata.yaml are Juju-level
per-relation concepts.
Regardless of reactive or non-reactive charms, when you do
juju add-relation <primary-app>:<endpoint-name>
<subordinate-app>:<endpoint-name>
relation data will flow only between primary and subordinate units on a
given logical machine (machine or container). In that sense "scope:
container" means primary <-> subordinate on the same "logical machine"
(doesn't have to be an LXD container).
IoW:
scope: container
N relation "instances" between units, 2 * N relation lifecycles (one per
unit)
or a primary only talks to its subordinate over that relation.
scope: global
N * N relation "instances" between units, 2 * N^2 relation lifecycles (N
per unit)
a primary talks to a subordinate and any other same-app primary's
subordinate over that relation
Note that being primary or subordinate does not impact your ability to set
up "scope: global" relations - being a subordinate only affects your
placement and units you can observe over a "scope: container" relation.
Best Regards,
Dmitrii Shcherbakov
Field Software Engineer
IRC (freenode): Dmitrii-Sh
On Wed, Nov 22, 2017 at 8:51 PM, Cory Johns <cory.jo...@canonical.com>
wrote:
> You can use the "juju-info" interface type for subordinates, but I'm not
> sure that this is the correct thing for your case.
>
> You're trying to attach the non-subordinate "database" endpoint (of
> interface protocol "juju-info") on your charm to the "database" endpoint
> (of interface protocol "cassandra") on the cassandra charm. Because the
> interface protocols don't match, Juju will not establish the relation.
> Additionally, because you're not connecting to the subordinate endpoint
> (scope: container) and instead to the standard endpoint, even if the
> relation was established, you would never see an instance of your charm
> created because it has no host application.
>
> All charms have an implicit relation endpoint called "juju-info" of
> interface protocol "juju-info" that you can connect to, and as long as the
> interface protocol match and are unambiguous, you can omit them. To
> connect your charm using the "juju-info" interface protocol, you would need
> to only define the "host-system" endpoint in your charm (as you currently
> have it), leave off the "database" endpoint, and omit the endpoint portion
> when adding the relation (or, if you want to be explicit about that, you
> can use "juju add-relation cassandra-backup:host-system
> cassandra:juju-info"). Then, for the reactive portion, you would use
> "@when('host-system.available')" as the decorator.
>
> However, I see that you also want to retrieve relation data that the
> cassandra charm provides using the "cassandra" interface protocol. Here it
> becomes important to note that whether a relation is subordinate or not is
> independent of the interface protocol the relation uses. Thus, you could
> mark the endpoint as "scope: container" and still use the "cassandra"
> interface protocol. You would then want to drop the "host-system" endpoint
> from your charm, mark the "database" endpoint as "interface: cassandra",
> and connect as you were trying to do. However, I seem to recall that
> Stuart (the maintainer of the cassandra charm) raised a possible issue with
> subordinates using relations that the other end doesn't expect to be
> subordinate, so there might be some concerns there. I can't recall exactly
> what the issue was, and I can't seem to find the bug report now. Perhaps
> Stuart can chime in.
>
> A final concern is that I don't see an interface layer for the "cassandra"
> interface protocol in the layer index (https://github.com/juju/
> layer-index#list-of-interface-layers), meaning it will be more difficult
> to use in a reactive charm. Without the interface layer, you wouldn't get
> the flags set to react to and would need to manually inspect the relation
> data using charmhelpers.core.hookenv. It looks like your use case is
> fairly simple, though, so we can probably get a very basic interface layer
> for it put together pretty quickly that Stuart could then expand upon. I'm
> happy to help with that, but with the holidays in the US, I might be a few
> days before I can do so.
>
> On Wed, Nov 22, 2017 at 10:02 AM, Tilman Baumann <
> tilman.baum...@canonical.com> wrote:
>
>> I'm writing a reactive subordinate charm for cassandra.
>> I can not find a interface for cassandra. But that's ok, since I don't
>> really need a full blown database connection client.
>>
>> Easy I thought and just re-used the juju-info interface for fun and
>> profit.
>> requires:
>> host-system:
>> interface: juju-info
>> scope: container
>> database:
>> interface: juju-info
>>
>> And in the code
>> @when('database.available')
>> def db_changed(cassandra):
>> for conv in cassandra.conversations():
>> username = conv.get_remote('username')
>> password = conv.get_remote('password')
>> ...
>>
>> However, that doesn't seem to work. Juju complains the relation doesn't
>> exist.
>> $ juju add-relation cassandra-backup:database cassandra:database
>> ERROR no relations found
>>
>> So, is there a interface that I can (ab-)use in a similar way?
>>
>> I don't want to build a full blown cassandra interface and at it to the
>> list.
>>
>> Cheers and thanks
>> Tilman
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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
