Sending binaries over relations

[Mark Shuttleworth]

Two thoughts.

First, I think it's interesting that you see resources as such a dynamic
thing. I believe the current model accommodates this (we considered
user-provided resources, and what you are describing are essentially
charm-generated resources, but they would behave the same way).

Second, I am sceptical about cross-charm resource coordination. We go to
great lengths to keep a service encapsulated. Each service is generally
prevented from knowing too much about what is going on in the service
next door. This is deliberate because it leads to the development of
services which can more naturally be swapped out, because the web of
expectations between related services is limited by what they can
possibly know about each other. What you are describing suggests too
intimate an awareness between two services of their exact operational
implementation.

That said, we do have an idea in the "futures" department, which is a
higher-level charm that would manage a group of charms. While they would
remain encapsulated, the higher-level charm would have admin-like
visibility across all of the services it is supervising. Imagine an
"openstack" charm which can command-and-control events across all the
constituent services. In THAT case, yes, it would make sense for the
higher level charm, which we call a "stack", to be able to coordinate
resources across services under its supervision.

How does that sound?

Mark

On 21/01/16 01:21, Merlijn Sebrechts wrote:
> Hi John, Mark
>
>
> If I understand you correctly, a Charm will be able to decide what version
> of the resource it needs at runtime? This way, a Charm could tell related
> Charms what version of the resource they should get? That would solve my
> use-case almost completely...
>
> The only exception being the case where a Charm compiles a library during
> installation and wants to distribute that binary to its related Charms.
> This would require the Charm to be able to push the resource to the state
> server and then distribute a link to that resource over its relations.
>
> Using the state server instead of rsync would be a lot better long-term, I
> think. Network spaces and multi-tenancy might make it possible that a Charm
> cannot ssh to a related Charm...
>
>
> Any thoughts on this?
>
>
> Kind regards
> Merlijn Sebrechts
>
> 2016-01-21 7:42 GMT+01:00 John Meinel <john at arbash-meinel.com>:
>
>> It does feel like a good fit for resources, with the one caveat that he
>> wants to maintain a lock-step version of the resource across services.
>> There is slightly more work with the current designs for resources, in that
>> each charm will think about its version of the resource independently. But
>> we will have the fingerprint information to allow for users to compare and
>> be confident that both services are using the same resource.
>>
>> John
>> =:->
>>
>> On Wed, Jan 20, 2016 at 8:53 PM, Mark Shuttleworth <mark at ubuntu.com>
>> wrote:
>>
>>> On 20/01/16 14:24, Merlijn Sebrechts wrote:
>>>> So my question is: Is there a way to send large binary files between
>>>> Charms? Or is this problem better solved by using a subordinate
>>>> kafka-plugin Charm like the Hadoop Charms do?
>>> It sounds like you want the new "Resources" capability coming in Juju 2.0
>>> :)
>>>
>>> For shared large blobs (like a JVM or a big ball of libraries) the charm
>>> can ask the state server to cache the blob and distribute it to all the
>>> units. There are mechanisms for users to supply the blob if needed, too.
>>>
>>> Mark
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>