Relation scope clarification

Dmitrii Shcherbakov dmitrii.shcherbakov at
Tue Oct 17 20:35:14 UTC 2017


I think having relation scope to depend on both sides and take
min(scope_left, scope_right) is the right approach. After all, it doesn't
restrict other applications from using the same relation (with the same
unique interface name) in a different scope.

I described use-cases here in a generic way ( but
telegraf and postgres vs posgres and, say, mediawiki would be a good
example of a practical use-case.

I looked at the code that handles that and it seems to go "way back" with
an original intention of having the approach above:
" // If either endpoint has container scope, so must the other;"

The problems to use that are: (a unit with a globally-scoped
relation definition tries to read settings where it shouldn't as the other
side is scope:container) (change relation scope on
charm upgrade - either go through {-joined, -changed} lifecycle or
{-broken, -departed for some pairs of units)

I agree that it won't be feasible for all use-cases (e.g. where you need to
talk to a master/leader node) but sometimes you only need to talk to a
follower which will contact the master itself (Zookeeper comes to mind) so
it's just another way to model in my view.

Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Tue, Oct 17, 2017 at 10:21 PM, John Meinel <john at>

> 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.
> 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.)
> 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"
> ?
> John
> =:->
> On Tue, Oct 17, 2017 at 11:16 PM, John Meinel <john at>
> wrote:
>> 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.
>> 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.
>> 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.)
>> I can't say that I've paged in all the bug comments yet, so I may be
>> speaking from misinformation.
>> John
>> =:->
>> On Tue, Oct 17, 2017 at 3:16 PM, Stuart Bishop <
>> stuart.bishop at> wrote:
>>> Hi.
>>> A server declares a relation with standard scope. Lets use PostgreSQL
>>> for example, which declares the following in metadata.yaml:
>>> provides:
>>>   db:
>>>     interface: pgsql
>>> A client happens to be a subordinate, and declares its end of the
>>> relation as container scoped. So in its metadata.yaml:
>>> requires:
>>>   postgresql:
>>>     interface: pgsql
>>>     scope: container
>>> My first question is: Is this supported by Juju? Can charms have a
>>> relation with a different scope at each end? I know it works in most
>>> cases, but is it supported or just an accident of implementation?
>>> If the answer to that is yes, my second question is: If the relation
>>> fails when the two charms declare a different scope, whose fault is
>>> it?
>>> The problem I have is that if one end of the relation declares
>>> container scope, then the relation is container scoped, and
>>> relation-get calls attempting to inspect relation data of peers fail.
>>> Is this a Juju bug, or does the PostgreSQL charm need to understand
>>> this limitation and use some other mechanism if it wants the pgsql
>>> relation to work in either global or container scope?
>>> Should relation-get return an error if a charm attempts to access
>>> relation info from a peer unit, rather than only working if both ends
>>> of the relation agree that the relation scope is global.
>>> There are several bugs open on this issue dealing with large scale
>>> deployments and I'm not sure how to proceed.
>>> is the juju one. I think
>>> I can update the PostgreSQL charm to support requirements, but I'm
>>> worried I would just be digging a deeper hole.
>>> --
>>> Stuart Bishop <stuart.bishop at>
>>> --
>>> Juju mailing list
>>> Juju at
>>> Modify settings or unsubscribe at:
>>> an/listinfo/juju
> --
> Juju mailing list
> Juju at
> Modify settings or unsubscribe at:
> mailman/listinfo/juju
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Juju mailing list