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.sebrec...@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.jo...@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.sebrec...@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.jo...@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.sebrec...@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@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 >>> >>> >> >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju