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
