search

canonical / operator

Pure Python framework for writing Juju charms
Apache License 2.0
245 stars 119 forks source link

juju-info not supported #395

Closed stub42 closed 1 year ago

stub42 commented 4 years ago

The implicit juju-info peer relation is not supported by the operator framework. The framework assumes all relations are defined in metadata.yaml, which is otherwise true.

facundobatista commented 4 years ago

Info about implicit relations here.

jameinel commented 4 years ago

I'd like to understand what you want to do with the implicit relation so that we can make sure to support your use case. Is it just that the Harness doesn't let you set things up the way you would like? Generally a charm doesn't interact with its own juju-info relation very much, since (IIRC) it isn't allow to set any data on the relation. (Maybe it is possible to do so, but it would certainly be a violation of what 'juju-info' actually means, if you need to actually convey information between charms, that should be an interface with a concrete type.)

stub42 commented 4 years ago

I just reached for it to discover the IP addresses of my peers. The juju-info relation doesn't provide much (anything?) beyond that. I raised the issue here because it should either be exposed so charms using it can be ported, or deprecated in Juju as an atavism we no longer need.

johnsca commented 4 years ago

During the very early design discussions for the operator framework, there was talk about creating an implicit peer relation in Juju since, as far as I am aware, one does not exist. According to the linked docs, the only implicit relation endpoint is the provides side of the juju-info relation, intended for use with subordinates (but not actually restricted to scope: container). The other side still has to explicitly define a named requires endpoint of type juju-info to be relatable to that implicit endpoint.

I tried and was unable to discover any sort of implicit juju-info peer relation on a simple test charm (relation-ids returned nothing, and neither juju status --relations nor juju show-unit showed any peer relation), and even trying to create an explicit named peers endpoint of type juju-info failed to deploy with the following:

ERROR issue parsing "metadata.yaml" file: charm "ubuntu-lite" relation "info" using a reserved interface: "juju-info"

It does seem strange to me for a charm to have to explicitly define a peers relation endpoint, since the charm is going to have peers regardless of whether it defines a relation endpoint and allowing it to be explicitly defined means that there is inconsistency and a charm can even define multiple peer relations which doesn't seem to make sense. It also seems strange for the charm to have to declare an explicit interface type for the peer relation, since there is never a concern about interoperability given that it's always the same charm code and often the only thing that the charm cares about is the number of peers and their addresses, as mentioned. So, at the end of the day, adding peers: {peers: {interface: peers}} to every charm's metadata.yaml seems like superfluous boilerplate.

jameinel commented 4 years ago

We have talked about having an implicit peer. Some particular points that I'm aware of:

John =:->

On Mon, Sep 14, 2020 at 11:04 AM Cory Johns notifications@github.com wrote:

During the very early design discussions for the operator framework, there was talk about creating an implicit peer relation in Juju since, as far as I am aware, one does not exist. According to the linked docs, the only implicit relation endpoint is the provides side of the juju-info relation, intended for use with subordinates (but not actually restricted to scope: container). The other side still has to explicitly define a named requires endpoint of type juju-info to be relatable to that implicit endpoint.

I tried and was unable to discover any sort of implicit juju-info peer relation on a simple test charm (relation-ids returned nothing, and neither juju status --relations nor juju show-unit showed any peer relation), and even trying to create an explicit named peers endpoint of type juju-info failed to deploy with the following:

ERROR issue parsing "metadata.yaml" file: charm "ubuntu-lite" relation "info" using a reserved interface: "juju-info"

It does seem strange to me for a charm to have to explicitly define a peers relation endpoint, since the charm is going to have peers regardless of whether it defines a relation endpoint and allowing it to be explicitly defined means that there is inconsistency and a charm can even define multiple peer relations which doesn't seem to make sense. It also seems strange for the charm to have to declare an explicit interface type for the peer relation, since there is never a concern about interoperability given that it's always the same charm code and often the only thing that the charm cares about is the number of peers and their addresses, as mentioned. So, at the end of the day, adding peers: {peers: {interface: peers}} to every charm's metadata.yaml seems like superfluous boilerplate.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/canonical/operator/issues/395#issuecomment-692154973, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRQ7ORCTZE5VG5PYENYSLSFY5HFANCNFSM4QQLYM3Q .

benhoyt commented 1 year ago

Going to close this won't-fix for now as people aren't clamouring for it (reopen with more info if you disagree). In terms of your own IP address, you can call network-get.