Re: Relation scope clarification

[Stuart Bishop]

On 18 October 2017 at 02:21, John Meinel  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
too 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 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Relation scope clarification

[Dmitrii Shcherbakov]

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 
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 
> 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 

Re: Relation scope clarification

[John Meinel]

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 
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 
>>
>> --
>> 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

Re: Relation scope clarification

[John Meinel]

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 
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 
>
> --
> 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

Relation scope clarification

[Stuart Bishop]

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 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju