[Juju] Proxy Charm examples

Cory Johns cory.johns at canonical.com
Fri Aug 21 14:10:39 UTC 2015


Oh, I just realized that I misunderstood your point about the identical
data and that you were suggesting designing the interface to match the need
for a proxy charm.  I would argue against that, since proxy charms to
external services are the exception rather than the rule, and with a bit
more smarts in the proxy charm, it can be handled more gracefully than I
did in my example.

On Fri, Aug 21, 2015 at 10:08 AM, Cory Johns <cory.johns at canonical.com>
wrote:

> Stuart,
>
> Excellent points.
>
> Supporting separate different data for different services is exactly what
> I was thinking of when I mentioned the actions, where calling the action
> would register a service name (or pattern) and associated data.  Structured
> data for the config value is another option there, as you mention.
>
> Yes, the proxy charm could be a subordinate.  You could also simply deploy
> it as a container on the bootstrap node with --to lxc:0 or similar.  That
> would still take up some amount of resources, though, so a subordinate
> would be a bit better there, but then you'd have a dangling (subordinate)
> relation that muddies up the model a bit.  So I'm not sure which is better
> in the end.
>
> In the end, though, this was intended as a simple example of the general
> idea of proxy charms, so I didn't bother making it more robust.  Perhaps it
> would be worth filling it out, though, to show off all of these
> considerations that one is faced with when using proxy charms that may not
> be apparent at first.
>
> On Fri, Aug 21, 2015 at 2:43 AM, Stuart Bishop <
> stuart.bishop at canonical.com> wrote:
>
>>
>> On 21 August 2015 at 01:45, Cory Johns <cory.johns at canonical.com> wrote:
>>
>>
>>
>>> Even as a proxy charm, this could be improved (it could use actions to
>>> enable per-service configuration, for example), but it should give you the
>>> basic idea.
>>>
>>>
>> The main limitation is that this approach only supports proxying a single
>> unit service, or a service where each unit presents identical data. If you
>> need a proxy like this, you may need to take these limitations into account
>> when designing the relation interface (eg. present hostnames (plural - a
>> list of all hosts) the same on each unit, rather than a individual hostname
>> on each unit).
>>
>> Can the proxy be a subordinate to save spinning up the container?
>>
>> --
>> Stuart Bishop <stuart.bishop at canonical.com>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150821/87f85648/attachment.html>


More information about the Juju mailing list