Is there a universal interface I can use?

Dmitrii Shcherbakov dmitrii.shcherbakov at canonical.com
Wed Nov 22 18:57:52 UTC 2017


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.johns at 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.baumann at 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 at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20171122/43a82aa9/attachment.html>


More information about the Juju mailing list