<div dir="ltr">Ah, I guess that telegraf is actually gathering extra data from mysql or postgres about database specific stats, and thus it should have a container scoped relation because it wants to explicitly sit with postgres and collect general machine information, as well as collect postgres specific information. It isn't that telegraf is using postgresql as its data store, its that it knows how to get extra statistical information about a database.<div><br></div><div>In that case, telegraf *should* use a container scope for its postgresql interface. I wonder how that works when you have HA postgres, and each telegraf connection to postgres is at least logically different. (telegraf should care very much that it never connect to the postgresql on a different machine and get its information.)</div><div><br></div><div>Is this a case where we actually need postgresql to offer up a "pgsql-monitoring" relation, rather that use the existing "store my data in postgres, 'pgsql' relation"</div><div>?</div><div><br></div><div>John</div><div>=:-></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 17, 2017 at 11:16 PM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.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">Why is the subordinate container scoped? The specific scope of container is that you only see the single instance that you share a machine with. Typically subordinates will use something like the juju-info relation because all they really care about is to be colocated on the same machine.<div><br></div><div>I can't claim to have deep knowledge here, but I would guess that if one end of a relation is normally scoped, and the other is container scoped, then the intent is that the relation itself is container scoped and each unit of each application only sees the other unit that shares the same machine/container.</div><div><br></div><div>Now in the telegraf case, I would expect telegraf to have 2 types of relations. 1 which is container scoped that means "I want to monitor this application", and *another* which must be global scoped which means "I want to use this application to store my data" (assuming telegraf is trying to connect to pgsql because it wants to record stuff in a database, if it just wanted to sit in the same machine and monitor postgres than I would have expected it to use juju-info for that relation.)</div><div><br></div><div>I can't say that I've paged in all the bug comments yet, so I may be speaking from misinformation.</div><div><br></div><div>John</div><div>=:-></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 17, 2017 at 3:16 PM, Stuart Bishop <span dir="ltr"><<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
<br>
A server declares a relation with standard scope. Lets use PostgreSQL<br>
for example, which declares the following in metadata.yaml:<br>
<br>
provides:<br>
  db:<br>
    interface: pgsql<br>
<br>
A client happens to be a subordinate, and declares its end of the<br>
relation as container scoped. So in its metadata.yaml:<br>
<br>
requires:<br>
  postgresql:<br>
    interface: pgsql<br>
    scope: container<br>
<br>
My first question is: Is this supported by Juju? Can charms have a<br>
relation with a different scope at each end? I know it works in most<br>
cases, but is it supported or just an accident of implementation?<br>
<br>
If the answer to that is yes, my second question is: If the relation<br>
fails when the two charms declare a different scope, whose fault is<br>
it?<br>
<br>
The problem I have is that if one end of the relation declares<br>
container scope, then the relation is container scoped, and<br>
relation-get calls attempting to inspect relation data of peers fail.<br>
Is this a Juju bug, or does the PostgreSQL charm need to understand<br>
this limitation and use some other mechanism if it wants the pgsql<br>
relation to work in either global or container scope?<br>
<br>
Should relation-get return an error if a charm attempts to access<br>
relation info from a peer unit, rather than only working if both ends<br>
of the relation agree that the relation scope is global.<br>
<br>
There are several bugs open on this issue dealing with large scale<br>
deployments and I'm not sure how to proceed.<br>
<a href="https://bugs.launchpad.net/juju/+bug/1721295" rel="noreferrer" target="_blank">https://bugs.launchpad.net/juj<wbr>u/+bug/1721295</a> is the juju one. I think<br>
I can update the PostgreSQL charm to support requirements, but I'm<br>
worried I would just be digging a deeper hole.<br>
<span class="m_-5157396086750894818HOEnZb"><font color="#888888"><br>
--<br>
Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>><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></blockquote></div><br></div>