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'm sorry, I wasn't clear about this. I wasn't consistent enough with my
usage of Charm VS Service. The library is not for the connection between
two charms. The library is for the connection between two services (the two
services that the two Charms deploy).
I've seen it common for Java services
I actually don't see why you would ever need to distribute a specific
library for connecting to an API on another charm. The charm using the
dynamically determined client would still require a static (i.e. backward
compatible) API on the client library (otherwise the client charm would
have no
This use-case lines up almost exactly with how we deal with the Hadoop
client libraries in the Hadoop core charms.
We handle this using the apache-hadoop-plugin subordinate charm. The
subordinate charm provides the Hadoop libraries to the client, with the
versions supported being locked in the
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
I like the idea of rsync. Is there a way to restrict access to a single
file on the rsync server?
2016-01-20 16:16 GMT+01:00 Marco Ceppi :
> I don't think sending the binary via relation is a good idea. Either
> spinning up a web service or using rsync would be a better bet
>
>
@José: I worry that this will become a big strain to the state server. I
don't know much about the internal architecture to be certain of this,
though..
@Matthew: This would side-step jujuresources. It might be feasible if
jujuresources could provide a way for the Charm to Share that resource,
Would it not be better for the charm to have a path the client can `wget`
the libraries from - this path can be sent via the relation as a string
Matty
On Wed, Jan 20, 2016 at 2:30 PM, José Antonio Rey wrote:
> Hey,
>
> One of the options would be to cat the file as a string
It seems rssh might be able to do this!
2016-01-20 16:25 GMT+01:00 Merlijn Sebrechts :
> I like the idea of rsync. Is there a way to restrict access to a single
> file on the rsync server?
>
> 2016-01-20 16:16 GMT+01:00 Marco Ceppi :
>
>> I don't
Hey,
One of the options would be to cat the file as a string and pass that
string over the connection, finally echoing that string to foo.binary.
What do others think?
--
José Antonio Rey
On Wed, Jan 20, 2016, 08:25 Merlijn Sebrechts
wrote:
> Hi
>
>
> I have a
Hi
I have a question I'd like to discuss, if you guys aren't to busy prepping
for Ubucon.. :)
I've found a number of Java projects where, in order to communicate for
example with Kafka, they require the Kafka Java libraries for that specific
version. For the moment, I solve this by downloading
11 matches
Mail list logo