Pass website provider kwargs through relation, add 'path' param

[cmars]

I think it'd be nice if charms that provide the website endpoint could specify to the reverseproxy endpoint the path under which they'd like to be located. I just don't like messing with rewrite rules. They're not hard, but they're always a hassle to look up.

For an example charm with a reverseproxy that supports the path relation setting, see https://github.com/cmars/nginx-layer. This charm is great for development -- I'm using it to reverseproxy and route a bunch of microservices behind a single HTTP endpoint. Doesn't support load-balancing yet, but I bet there's a way to do it by grouping the units by path or something.

Passing custom kwargs through allows the website endpoint to also provide compatibility with charms that do relation setting of chunks of yaml for complex stuff, like haproxy, etc.

[marcoceppi]

I'm going to disagree with this. You've just overloaded the definition of the interface and it's no longer a strongly typed communication protocol but a whack-a-mole variant where anything can be set on the relation channel. How is anyone implementing the requires portion of this able to know what values will be sent?

If you don't agree with the limited scope of this interface I suggest building a new interface instead which suites your needs.

[marcoceppi]

Also, there's already an nginx layer in the directory. I recommend collaborating with existing layers instead of creating duplicate competing solutions, esp when they both set to achieve the same goal

[cmars]

I see what you're saying. I found these changes useful for development and backwards-compatibility with charms that need extra service config over the "http" interface in production. Maybe this isn't appropriate for the simple or ideal case so I'll close it.

[marcoceppi]

There is only really one or two charms that have "extra" http data, and they're in violation of the interface, not the norm