@johnsca in thinking about the issue with #10, the only charms i can find that break interface encapsulation (that is, they call the old RelationBase.set_remote() directly) are reverse proxy providers that try to ship services yaml over to things like apache2/haproxy.
As discussed, these will break with the endpoint transition. I think the permanent solution for them would be to have a new interface specifically for rev proxies. We talked about a proper rev proxy method in the http interface, but that feels to me like turning the simple http interface into a kitchen sink (what's next, interface-http provides basic auth too?).
In the short term, how do you feel about this proposed simple method that maintains back compat by letting charms dump kwargs over this interface?
The pros for this is that we can make the switch to Endpoints quickly and no charms need to change. The con is that we introduce a new method that we will need to deprecate later.
One alternative would be to go ahead and write a new rev proxy interface, alter charms like graylog to use it, and then proceed with #10 as is. Got a feeling one way or another?
@johnsca in thinking about the issue with #10, the only charms i can find that break interface encapsulation (that is, they call the old
RelationBase.set_remote()
directly) are reverse proxy providers that try to shipservices
yaml over to things like apache2/haproxy.As discussed, these will break with the endpoint transition. I think the permanent solution for them would be to have a new interface specifically for rev proxies. We talked about a proper rev proxy method in the http interface, but that feels to me like turning the simple http interface into a kitchen sink (what's next, interface-http provides basic auth too?).
In the short term, how do you feel about this proposed simple method that maintains back compat by letting charms dump kwargs over this interface?
The pros for this is that we can make the switch to Endpoints quickly and no charms need to change. The con is that we introduce a new method that we will need to deprecate later.
One alternative would be to go ahead and write a new rev proxy interface, alter charms like graylog to use it, and then proceed with #10 as is. Got a feeling one way or another?