Relation scope clarification

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


John,

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 (
https://bugs.launchpad.net/telegraf-charm/+bug/1718259/comments/5) but
telegraf and postgres vs posgres and, say, mediawiki would be a good
example of a practical use-case.

https://bugs.launchpad.net/telegraf-charm/+bug/1718259/comments/5

I looked at the code that handles that and it seems to go "way back" with
an original intention of having the approach above:
https://bugs.launchpad.net/telegraf-charm/+bug/1718259/comments/2
https://github.com/juju/juju/blame/juju-2.2.4/state/state.go#L1661-L1668
" // If either endpoint has container scope, so must the other;"

The problems to use that are:

https://bugs.launchpad.net/juju/+bug/1721295 (a unit with a globally-scoped
relation definition tries to read settings where it shouldn't as the other
side is scope:container)
https://bugs.launchpad.net/juju/+bug/1721289 (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 arbash-meinel.com>
wrote:

> 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 arbash-meinel.com>
> 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 canonical.com> 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.
>>> https://bugs.launchpad.net/juju/+bug/1721295 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 canonical.com>
>>>
>>> --
>>> 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/20171017/75d44b19/attachment.html>


More information about the Juju mailing list