Re: 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 :
>
>> 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 
>> 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@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>



-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[Merlijn Sebrechts]

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 to use a library to connect to
another java service. The actual network protocol is unstable between
versions, but the API of the supplied library is stable.

2016-01-21 17:24 GMT+01:00 Nate Finch :

> 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 way to know how to use the client library)... so why not just put
> that static API on the server? and then you don't need a different client.
> Obviously, you can distribute new clients with new functionality, but by
> definition, you'd need new code in the client charm to understand how to
> use that functionality.
>
> On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi Mark
>>
>>
>> I understand your concern. Leaking operational details is something that
>> should not be done in Juju. Apache proxy relationship cannot be implemented
>> by Nginx because the relation leaks operational details (apache specific
>> config files). This is not 'the Juju way'.
>>
>> The reason for sharing resources actually is interoperability. Say a
>> client wants to connect to a server, then the client may need libraries to
>> do that. What libraries will be used is dependent on both the client and
>> the server. If you ship the libraries with the client, you are essentially
>> hard-coding the server version. This is also not the Juju way; information
>> like this should be passed over relations. The problem here is that both
>> Charms have to make a joint decision about what libraries, if any, to use
>> and where to get them. No Charm has full knowledge to make that decision.
>>
>> I've seen two common patterns in the wild for these kind of libraries:
>>
>> 1. The client uses its own libraries compiled for that specific version
>> of the server.
>> 2. The client uses libraries bundled with the server.
>>
>> The first case is easy: The client has full knowledge about where to get
>> the libraries. It only needs to know the server version. The server tells
>> the client his version and it's done. The second case is a little bit
>> tougher. The client has knowledge about what libraries it needs, but the
>> server has knowledge about where to get those libraries. In this case, the
>> client should request the libraries from the server, and the server should
>> have a way to send them to the client.
>>
>> If both cases are supported by the server, you can swap any client in and
>> out. This also translates nicely to the idea that a Charm gets created by
>> the person who is an expert in that service. The server experts know where
>> to get the libraries if the server has to provide them. The client expert
>> knows how to compile the libraries if the client has to compile them.
>>
>> What do you think?
>>
>>
>>
>>
>> *PS: I don't think this should be done on stack level, since the shared
>> libraries are only relevant to the two related Charms. The relevance of the
>> libraries is on relation-level so they should be handled by the relations.*
>>
>>
>>
>>
>> 2016-01-21 13:58 GMT+01:00 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

Re: Sending binaries over relations

[Nate Finch]

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 way to know how to use the client library)... so why not just put
that static API on the server? and then you don't need a different client.
Obviously, you can distribute new clients with new functionality, but by
definition, you'd need new code in the client charm to understand how to
use that functionality.

On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Mark
>
>
> I understand your concern. Leaking operational details is something that
> should not be done in Juju. Apache proxy relationship cannot be implemented
> by Nginx because the relation leaks operational details (apache specific
> config files). This is not 'the Juju way'.
>
> The reason for sharing resources actually is interoperability. Say a
> client wants to connect to a server, then the client may need libraries to
> do that. What libraries will be used is dependent on both the client and
> the server. If you ship the libraries with the client, you are essentially
> hard-coding the server version. This is also not the Juju way; information
> like this should be passed over relations. The problem here is that both
> Charms have to make a joint decision about what libraries, if any, to use
> and where to get them. No Charm has full knowledge to make that decision.
>
> I've seen two common patterns in the wild for these kind of libraries:
>
> 1. The client uses its own libraries compiled for that specific version of
> the server.
> 2. The client uses libraries bundled with the server.
>
> The first case is easy: The client has full knowledge about where to get
> the libraries. It only needs to know the server version. The server tells
> the client his version and it's done. The second case is a little bit
> tougher. The client has knowledge about what libraries it needs, but the
> server has knowledge about where to get those libraries. In this case, the
> client should request the libraries from the server, and the server should
> have a way to send them to the client.
>
> If both cases are supported by the server, you can swap any client in and
> out. This also translates nicely to the idea that a Charm gets created by
> the person who is an expert in that service. The server experts know where
> to get the libraries if the server has to provide them. The client expert
> knows how to compile the libraries if the client has to compile them.
>
> What do you think?
>
>
>
>
> *PS: I don't think this should be done on stack level, since the shared
> libraries are only relevant to the two related Charms. The relevance of the
> libraries is on relation-level so they should be handled by the relations.*
>
>
>
>
> 2016-01-21 13:58 GMT+01:00 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
>> > 

Re: Sending binaries over relations

[Cory Johns]

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 plugin charm, and it does version
matching when the plugin is connected to the Hadoop cluster to ensure that
it is compatible with the cluster.

Thus, the client doesn't need to worry about the Hadoop library version,
and it isn't version-locked to a specific Hadoop library version.  As long
as the client supports the plugin relation and the plugin charm is
connected to a compatible Hadoop cluster, the client knows that the
provided libraries will work.

The plugin charm also gives us a single charm to update with new library
versions, while retaining the ability to test those libraries to ensure
they work before updating the charm.

There is one case of potential incompatibility that wasn't addressed in
your original proposal nor in the plugin charm design as described: the
case where the client itself has trouble using certain versions of the
libraries.  Luckily, this is relatively uncommon, and if it arises, we can
address it using the same or similar "spec matching" logic that the plugin
(and other Hadoop component charms) use to ensure version compatibility, as
long as the plugin charm passes through the Hadoop version on the relation.

On Thu, Jan 21, 2016 at 12:15 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> 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 to use a library to connect to
> another java service. The actual network protocol is unstable between
> versions, but the API of the supplied library is stable.
>
> 2016-01-21 17:24 GMT+01:00 Nate Finch :
>
>> 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 way to know how to use the client library)... so why not just put
>> that static API on the server? and then you don't need a different client.
>> Obviously, you can distribute new clients with new functionality, but by
>> definition, you'd need new code in the client charm to understand how to
>> use that functionality.
>>
>> On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi Mark
>>>
>>>
>>> I understand your concern. Leaking operational details is something that
>>> should not be done in Juju. Apache proxy relationship cannot be implemented
>>> by Nginx because the relation leaks operational details (apache specific
>>> config files). This is not 'the Juju way'.
>>>
>>> The reason for sharing resources actually is interoperability. Say a
>>> client wants to connect to a server, then the client may need libraries to
>>> do that. What libraries will be used is dependent on both the client and
>>> the server. If you ship the libraries with the client, you are essentially
>>> hard-coding the server version. This is also not the Juju way; information
>>> like this should be passed over relations. The problem here is that both
>>> Charms have to make a joint decision about what libraries, if any, to use
>>> and where to get them. No Charm has full knowledge to make that decision.
>>>
>>> I've seen two common patterns in the wild for these kind of libraries:
>>>
>>> 1. The client uses its own libraries compiled for that specific version
>>> of the server.
>>> 2. The client uses libraries bundled with the server.
>>>
>>> The first case is easy: The client has full knowledge about where to get
>>> the libraries. It only needs to know the server version. The server tells
>>> the client his version and it's done. The second case is a little bit
>>> tougher. The client has knowledge about what libraries it needs, but the
>>> server has knowledge about where to get those libraries. In this case, the
>>> client should request the libraries from the server, and the server should
>>> have a way to send them to the client.
>>>
>>> If both cases are supported by the server, you can swap any client in
>>> and out. This also translates nicely to the idea that a Charm gets created
>>> by the person who is an expert in that service. The server experts know
>>> where to get the libraries if the server has to provide them. The client
>>> expert knows how to compile the libraries if the client has to compile them.
>>>
>>> What do you think?
>>>
>>>
>>>
>>>
>>> *PS: I don't think this should be done on stack level, since 

Re: Sending binaries over relations

[John Meinel]

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

Re: Sending binaries over relations

[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 think sending the binary via relation is a good idea. Either
> spinning up a web service or using rsync would be a better bet
>
> On Wed, Jan 20, 2016, 10:10 AM Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
>> 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 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 <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
 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 the libraries from a
 deployed Kafka installation and include them in the Charm. However, this
 has the disadvantage that everytime the Kafka charm version changes, I have
 to update the libraries in all the charms that connect to Kafka. It would
 be better if there was a way to send these libraries over the connection.
 This way, a Charm that can connect to one version of Kafka has a very high
 chance of being able to connect to the next version.

 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?



 Kind regards
 Merlijn Sebrechts
 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju

>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[Merlijn Sebrechts]

@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,
though... Even then, we might get into trouble if the binaries aren't
included as a resource but are compiled during installation...

2016-01-20 16:10 GMT+01:00 Matthew Williams 
:

> 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 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 <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> 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 the libraries from a
>>> deployed Kafka installation and include them in the Charm. However, this
>>> has the disadvantage that everytime the Kafka charm version changes, I have
>>> to update the libraries in all the charms that connect to Kafka. It would
>>> be better if there was a way to send these libraries over the connection.
>>> This way, a Charm that can connect to one version of Kafka has a very high
>>> chance of being able to connect to the next version.
>>>
>>> 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?
>>>
>>>
>>>
>>> Kind regards
>>> Merlijn Sebrechts
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[Matthew Williams]

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 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 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 the libraries from a
>> deployed Kafka installation and include them in the Charm. However, this
>> has the disadvantage that everytime the Kafka charm version changes, I have
>> to update the libraries in all the charms that connect to Kafka. It would
>> be better if there was a way to send these libraries over the connection.
>> This way, a Charm that can connect to one version of Kafka has a very high
>> chance of being able to connect to the next version.
>>
>> 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?
>>
>>
>>
>> Kind regards
>> Merlijn Sebrechts
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[Merlijn Sebrechts]

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 think sending the binary via relation is a good idea. Either
>> spinning up a web service or using rsync would be a better bet
>>
>> On Wed, Jan 20, 2016, 10:10 AM Matthew Williams <
>> matthew.willi...@canonical.com> wrote:
>>
>>> 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 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 <
 merlijn.sebrec...@gmail.com> wrote:

> 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 the 
> libraries
> from a deployed Kafka installation and include them in the Charm. However,
> this has the disadvantage that everytime the Kafka charm version changes, 
> I
> have to update the libraries in all the charms that connect to Kafka. It
> would be better if there was a way to send these libraries over the
> connection. This way, a Charm that can connect to one version of Kafka has
> a very high chance of being able to connect to the next version.
>
> 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?
>
>
>
> Kind regards
> Merlijn Sebrechts
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju


>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[José Antonio Rey]

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 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 the libraries from a
> deployed Kafka installation and include them in the Charm. However, this
> has the disadvantage that everytime the Kafka charm version changes, I have
> to update the libraries in all the charms that connect to Kafka. It would
> be better if there was a way to send these libraries over the connection.
> This way, a Charm that can connect to one version of Kafka has a very high
> chance of being able to connect to the next version.
>
> 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?
>
>
>
> Kind regards
> Merlijn Sebrechts
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Sending binaries over relations

[Merlijn Sebrechts]

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 the libraries from a
deployed Kafka installation and include them in the Charm. However, this
has the disadvantage that everytime the Kafka charm version changes, I have
to update the libraries in all the charms that connect to Kafka. It would
be better if there was a way to send these libraries over the connection.
This way, a Charm that can connect to one version of Kafka has a very high
chance of being able to connect to the next version.

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?



Kind regards
Merlijn Sebrechts
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju