Relation scope clarification
stuart.bishop at canonical.com
Wed Oct 18 17:56:08 UTC 2017
On 18 October 2017 at 02:21, 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.)
In the current implementation, the 'subordinate' telegraf has access
to the master so it can connect to it and create the resources in the
database that it needs (if some other unit hasn't already beaten it
If a container scoped relation is used, the subordinate telegraf would
need to create the database resources if it happens to be connected to
the master, or wait until some other subordinate creates them if not.
Either way, my original query remains.
Is it allowed to relate charms with one end declaring the scope as
global and the other end declaring the scope as container?
If yes, should a PostgreSQL unit still be able to see the relation
data from its peers, even if it is related to a charm declaring the
relation as container scoped? Or should charms avoid inspecting
relation data of peer units because it will fail in this case?
> 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"
If mismatched relations are not allowed (one end declaring global, but
the other end disagreeing and declaring container), then I can provide
a separate relation, yes. It might also be the simplest solution, as
having the PostgreSQL charm share relation connection details from
master to standbys via the peer relation instead of the client
relation is fairly invasive.
Stuart Bishop <stuart.bishop at canonical.com>
More information about the Juju