The original intention of conversations and scopes was to simply certain interface interaction patterns where it may not be relevant or useful on your end of the relation to deal with each remote unit individually. An example might be if the remote service is expected to have a leader which speaks for all the units (SERVICE scope), or subordinates where you are guaranteed to only ever have a single remote unit (GLOBAL scope). When in doubt, you can always use UNIT scope (which is the default) and treat the list of conversations as a list of all of the remote units on the relation.
The effect of SERVICE scope is to merge the received data from remote units on a per-remote-service basis, and the effect of GLOBAL scope is to both merge received data from all remote units and to send the same data to all connected relations. The scope that one end of a relation uses has no effect on the other end of the relation. The error that you got seems like you performed an upgrade-charm after changing the scope of the interface layer. There is persisted context used to associate states with individual remote units based on the scope which does not deal well with such a change. You will need to redeploy if you change the scope of a interface layer. On Wed, Jun 7, 2017 at 9:27 PM, fengxia <fx...@lenovo.com> wrote: > Just to clarify my question. I know the official doc of these scopes, that > data are broadcasted in GLOBAL and UNIT is maintained as 1-to-1. What I'd > like to know is when we should use GLOBAL, and when to use UNIT? When I > deploy multiple units of a charm, does it mean its end of relation must use > UNIT? if so, what about the provide end, should it be UNIT? GLOBAL? SERVICE? > > > > On 06/07/2017 09:22 PM, fengxia wrote: > >> Hi Juju, >> >> I'm learning to write a relation. One thing that's puzzling to me is the >> scope. The question is, must provide and require use the same scope? >> >> For experiment, I have a scope.GLOBAL provide and scope.UNIT require. In >> deployment, there is one provide unit and three require units. In this >> setup, I was able to call set_remote() from provide side to pass a dict to >> require side (get_remote()). >> >> However, if I change provide to be scope.UNIT also, it generated an error: >> >> unit-A-52: 21:15:44 INFO unit.A/52.b-relation-joined ValueError: >> Conversation with scope 'b/120' not found >> >> Could you elaborate what the behavior should be when these scopes >> selected on either side? >> >> | provides | requires | >> | GLOBAL | GLOBAL | >> | UNIT | UNIT | >> | GLOBAL | UNIT | >> >> > -- > Feng xia > Engineer > Lenovo USA > > Phone: 5088011794 > fx...@lenovo.com > > Lenovo.com > Twitter | Facebook | Instagram | Blogs | Forums > > > -- > 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