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 <[email protected]>: > 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 <[email protected]> > 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
