Comment 5 for bug 1718259

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

Let me first define a term that I am going to use:

instance = object in object oriented programming terms = a copy of a struct

relation instance = an object for two units in question

If there are N units of app1 and M units of app two there will be N x M relation objects.

A relation with the same name can be reused for multiple applications.

N (app1), M (app2), K(app3)

app1 <-> rel_example_name <-> app2
app1 <-> rel_example_name <-> app3

In total I will have N x M + N x K = N (M + K) relation objects.

If I have subordinates, there is no need for me to have N x M or M x K - I will just have N1 = M, N2 = K.

So, in total, there will be: M + K container-scoped relations.

If I don't make them container-scoped, they will be treated as normal and I lose the benefit of a subordinate application. They will be placed locally but there will be additional joined, changed etc. event lifecycles for units that are not primaries or subordinates.

So, if app1 is a subordinate but relations are not container scoped, I will still get N (M + K).

Juju code assumes that both ends of a relation "instance" (think objects in object-oriented programming) for two particular units should round up to the smallest scope.

If a charm on the other end is container-scoped all copies of the relation objects in Juju will be container scoped.

This makes sense because if I wanted to have app4 as a non-subordinate but use the same relation, I would have an option to do so:

app1 (scope: container) <-> rel_example_name <-> app2 (scope: global) => final scope: container

app1 (scope: container) <-> rel_example_name <-> app3 (scope: global) => final scope: container

app4 (scope: global) <-> rel_example_name <-> app3 (scope: global) => final scope: global

This is also beneficial when I don't control app2 and app3 but want to leverage container scope (like with telegraf and postgres or mysql).

There is, however, a bug which prevents us from using that

In addition to the upgradability problem.

The end goal is to cut down the amount of event life cycles while maintaining ownership and stability of charms we are relating to.