scope: global -> scope: container relations with multiple machines: cannot read settings for unit ... settings not found

[Dmitrii Shcherbakov]

https://code.launchpad.net/~dmitriis/telegraf-charm/+git/telegraf-charm/+merge/331171/comments/868804

when one side is;
    "scope": "global"

and the other side is:

    "scope": "container"

On a multi-machine environment some units will get this error:

ERROR cannot read settings for unit "postgresql/1" in relation "telegraf:postgresql postgresql:db-admin": settings not found

https://code.launchpad.net/~dmitriis/telegraf-charm/+git/telegraf-charm/+merge/331171/comments/868804

However, judging by the source code it should be supported properly:

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

It seems like the logic should be: "if either endpoint is container-scoped, both sides should be container-scoped" and but relation settings accesses should be properly filtered to avoid the above error.

[John A Meinel (jameinel)]

Stub also raised this on the list. My summary comment there is:

If telegraf isn't using the pgsql connection to imply "I want to store my data in postgresql", then it should probably be using a different relationship to postgresql. Because I imagine the pgsql is likely to tell telegraf things like "here is the current master, go send your data there", but telegraf monitoring of postgresql doesn't want to monitor the master, it wants to monitor the exact postgresql application that it is on the same machine that this instance of telegraf is sitting alongside.

I don't know the details of how telegraf is going to use its connection to postgresql, but the pgsql interface seems like it would have some very specific semantics around how you should be using the data, which may not fit a monitoring relationship in the same way it fits a 'store my data' relationship.

I could be completely wrong about that, though, and it may be that the needs are sufficiently similar that it should be ok.

I will say that if you did:
 juju deploy postgresql -n3
 juju deploy telegraf
 juju add-relation telegraf:? postgresql:?

Would it be weird that the leader of the postgresql charm *doesn't* see a relation from telegraf/1 and /2, because it is running on postgresql/0, but postgresql/1 does see telegraf/1, etc.

I don't know how postgresql itself does the charm data, but I would think that it would try to set up a username/password/database tables for the entire application that is connected to the pgsql endpoint, but won't be able to set up pg_hba.conf correctly because each unit of postgresql actually sees a different unit of telegraf.

[John A Meinel (jameinel)]

Also, I do believe the code has been in flux in this area recently, because of other issues that we encountered with container scoped relations actually having too many other units in their scope.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.