[charms.reactive] http relation.available gets called on upgrade-charm hook, gives error.

[Cory Johns]

Merlijn,

Be aware that I had to make some small changes to the interface since my
previous email.  In particular, I had to remove the "changed" state, as it
does not function in any way like it was intended.  I updated the example
in the README to achieve the same end result, however.

I agree that charms should strive for general interface protocols whenever
possible, to ensure portability and compatibility.  However, I do think
that there are use-cases that couldn't be satisfied if we kept all
interface protocols completely generic.  As long as the specific extensions
are clearly indicated (e.g., using http-apache instead of plain http) or
possibly if there is a negotiation protocol that can degrade gracefully to
the common protocol, it could potentially work.

I think your use-case is a good one, and I think it will require some
additions to the http interface layer as it stands.  Currently, the
hostname is just the private-address of the remove unit, and the units are
grouped naturally by their service name.  It does seem like it would be
useful to be able to specify a public-facing host name and group by that.
I'm not sure if that's what the current Apache2 charm does with the
service_name override or not.

On Tue, Oct 27, 2015 at 3:25 PM, Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> Hi Cory
>
>
> Thanks for this! I'll try this out as soon as I get the time.
>
> I completely agree that the HA proxy block config should be in a seperate
> interface protocol. I would even go as far as to say that a block of
> application-specific config should not be passed between services. The way
> the apache2 charm relations are implemented now makes it impossible to
> create an Nginx Charm that implements the same relations. I think this is a
> real shame, since that's one of the beauties of Juju relations...
>
> I have been thinking of creating a new Apache2 Charm that has relations
> that are not Apache specific. One of the uses for this would be an Apache2
> server acting as a vhost-based reverse-proxy for multiple services
> connected using the http relation. Each service could specify a hostname.
> The Apache2 service forwards the traffic based on hostname. If the relation
> is generic enough, it would be possible to create an Nginx Charm
> implementing the same relations... This might even be possible with the
> current relation, forwarding traffic for "hostname" to "private-ip"? I'm
> not familiar enough with how juju determines hostname and private-ip to
> know if this could work... Material for future discussion?
>
>
>
> Kind regards
> Merlijn
>
> 2015-10-27 18:01 GMT+01:00 Cory Johns <cory.johns at canonical.com>:
>
>> Merlijn,
>>
>> Unfortunately, the correct solution for the issue with the HTTP interface
>> layer is to change how the requires side works a bit.  I went ahead and
>> made those changes and moved the repo (with Ben's permission) to
>> https://github.com/juju-solutions/interface-http (which will also allow
>> easier PR submissions).  I added a README with example usage but it will
>> require a bit of change to your code.  I also updated
>> interfaces.juju.solutions so that the next time you do a `charm build`, you
>> should get the new version of the interface.
>>
>> Let me know if you run into any issues with that implementation, and of
>> course PRs are welcome.
>>
>> As an aside, I just wanted to note that the http interface protocol is a
>> good example of one that has suffered for the lack of a standard
>> implementation like what the interface layer gives us.  When trying to
>> determine how to implement that side of the relation, it became apparent
>> that each charm that supports it seems to have added its own extensions to
>> the protocol (e.g., haproxy accepts entire HA proxy YAML configuration
>> blocks, Apache2 supports overriding the service grouping, etc.).  I only
>> implemented the most basic, common use-case as I saw it; if we, as a
>> community, determine that it needs to support more, we can do so, but
>> things like the HA proxy config block should really be in a separate
>> interface protocol (which could be a superset, with a negotiation protocol).
>>
>> On Tue, Oct 27, 2015 at 5:04 AM, Merlijn Sebrechts <
>> merlijn.sebrechts at gmail.com> wrote:
>>
>>> Hi Cory
>>>
>>>
>>> Thanks for the explanation. Is there a way to override the scope of the
>>> http relation without forking the interface?
>>>
>>>
>>>
>>> Kind regards
>>> Merlijn
>>>
>>> 2015-10-26 18:21 GMT+01:00 Cory Johns <cory.johns at canonical.com>:
>>>
>>>> Merlijn,
>>>>
>>>> You'll note that the docs for auto_accessors
>>>> <https://pythonhosted.org/charms.reactive/charms.reactive.relations.html#charms.reactive.relations.RelationBase.auto_accessors>
>>>> says that it's not a good idea to use with non-GLOBAL scoped relations, for
>>>> this very reason.  The problem is that there's no way which unit's or
>>>> service's host and port you are trying to get, since there could be many.
>>>> If it's true that there should only be a single connected service on this
>>>> relation, then you should switch it to  GLOBAL scope to indicate that.
>>>> Otherwise, you need to be handling the possibility of multiple connected
>>>> units explicitly.
>>>>
>>>> See
>>>> https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L74
>>>> for an example of how an interface layer should handle multiple
>>>> conversations.
>>>>
>>>> On Mon, Oct 26, 2015 at 5:58 AM, Merlijn Sebrechts <
>>>> merlijn.sebrechts at gmail.com> wrote:
>>>>
>>>>> Hi all
>>>>>
>>>>>
>>>>> I have the following piece of code that reacts to the
>>>>> httprelation.available hook (called rest2jfed in this case):
>>>>>
>>>>>
>>>>> @when('rest2jfed.available')
>>>>> def setup_rest2jfed(rest2jfed):
>>>>>     hostname = rest2jfed.host()
>>>>>     port = rest2jfed.port()
>>>>>     # Do some stuff with hostname and port
>>>>>     hookenv.status_set('active', 'Ready')
>>>>>
>>>>>
>>>>> This piece of code gets called on the upgrade-charm hook. This throws
>>>>> an error because there is not a relationship context.
>>>>>
>>>>>   File "lib/charms/reactive/relations.py", line 88, in __accessor
>>>>>     return self.get_remote(field)
>>>>>   File "lib/charms/reactive/relations.py", line 308, in get_remote
>>>>>     return self.conversation(scope).get_remote(key, default)
>>>>>   File "lib/charms/reactive/relations.py", line 255, in conversation
>>>>>     raise ValueError('Unable to determine default scope: no current
>>>>> hook or global scope')
>>>>>
>>>>> Am I using this relation wrong or is this a bug?
>>>>>
>>>>>
>>>>>
>>>>> Kind regards
>>>>> Merlijn
>>>>>
>>>>> --
>>>>> Juju mailing list
>>>>> Juju at lists.ubuntu.com
>>>>> Modify settings or unsubscribe at:
>>>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151027/0ca6a215/attachment.html>