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 <j...@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 <j...@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.bis...@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.bis...@canonical.com> >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/juju >>> >> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
