<div dir="ltr">Also:<div><br>"scope: global" vs "scope: container" in metadata.yaml are Juju-level per-relation concepts.<br><br>Regardless of reactive or non-reactive charms, when you do<div><br></div><div>juju add-relation <primary-app>:<endpoint-name> <subordinate-app>:<endpoint-name></div><div><br></div><div>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).</div><div><br></div><div>IoW:</div><div><br></div><div>scope: container</div><div>N relation "instances" between units, 2 * N relation lifecycles (one per unit)</div><div>or a primary only talks to its subordinate over that relation.</div><div><br></div><div>scope: global</div><div>N * N relation "instances" between units, 2 * N^2  relation lifecycles (N per unit)</div></div><div>a primary talks to a subordinate and any other same-app primary's subordinate over that relation<br></div><div><br></div><div>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.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Best Regards,<div>Dmitrii Shcherbakov</div><div><br></div><div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="color:rgb(68,68,68);font-size:12.8px">Field Software Engineer</span><br style="color:rgb(68,68,68);font-size:12.8px"><span style="font-size:12.8px">IRC (freenode): Dmitrii-Sh</span><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 22, 2017 at 8:51 PM, Cory Johns <span dir="ltr"><<a href="mailto:cory.johns@canonical.com" target="_blank">cory.johns@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You can use the "juju-info" interface type for subordinates, but I'm not sure that this is the correct thing for your case.<div><br></div><div>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.<div><br></div><div>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'<wbr>)" as the decorator.</div><div><br></div><div>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.</div><div><br></div><div>A final concern is that I don't see an interface layer for the "cassandra" interface protocol in the layer index (<a href="https://github.com/juju/layer-index#list-of-interface-layers" target="_blank">https://github.com/juju/<wbr>layer-index#list-of-interface-<wbr>layers</a>), 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.</div><div><div class="h5"><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 22, 2017 at 10:02 AM, Tilman Baumann <span dir="ltr"><<a href="mailto:tilman.baumann@canonical.com" target="_blank">tilman.baumann@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm writing a reactive subordinate charm for cassandra.<br>
I can not find a interface for cassandra. But that's ok, since I don't<br>
really need a full blown database connection client.<br>
<br>
Easy I thought and just re-used the juju-info interface for fun and profit.<br>
requires:<br>
  host-system:<br>
    interface: juju-info<br>
    scope: container<br>
  database:<br>
    interface: juju-info<br>
<br>
And in the code<br>
@when('database.available')<br>
def db_changed(cassandra):<br>
    for conv in cassandra.conversations():<br>
        username = conv.get_remote('username')<br>
        password = conv.get_remote('password')<br>
...<br>
<br>
However, that doesn't seem to work. Juju complains the relation doesn't<br>
exist.<br>
$ juju add-relation cassandra-backup:database cassandra:database<br>
ERROR no relations found<br>
<br>
So, is there a interface that I can (ab-)use in a similar way?<br>
<br>
I don't  want to build a full blown cassandra interface and at it to the<br>
list.<br>
<br>
Cheers and thanks<br>
<span class="m_-1070230059093802359gmail-HOEnZb"><font color="#888888"> Tilman<br>
<br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailm<wbr>an/listinfo/juju</a><br>
</font></span></blockquote></div><br></div></div></div></div></div></div>
<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/juju</a><br>
<br></blockquote></div><br></div>