felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: Deploying bundles across "equal" nodes...
Date Mon, 10 Oct 2011 09:56:34 GMT
An alternative solution might be the apache karaf cellar project

Kind regards
On Oct 10, 2011 10:32 AM, "Jean-Philippe Clement" <
jeanphilippe.clement@sogeti.com> wrote:

> => http://fabric.fusesource.org/
> Kind regards,
> Jean-Philippe
> Quoting DEBROUX Lionel <Lionel.DEBROUX@atos.net>:
>  Hello,
>> I have a use case for deploying bundles (which may have transitive,
>> versioned dependencies) accross several LAN nodes all installed with
>> the Felix framework.
>> The main goal is to have, for each node, the ability of:
>> - (1) acting as a server for bundles towards other nodes
>> - (2) downloading and installing bundles from other nodes, since all
>>      nodes provide (1)
>> Each node would also be expected to:
>> - (3) have every downloaded and/or installed bundle automatically
>>      appearing as available for download to other nodes.
>> Therefore, the use case is a step beyond the standard model, where
>> client nodes are in most cases constantly downloading from a known
>> and predefined "central" OBR.
>> The point is to:
>> - enhance robustness, in case remote OBRs are unreachable when the
>> need to deploy bundles to other nodes arise.
>> - favor deployments within local node neighbourhood, by exposing
>> bundles to a set of nearby nodes.
>> Example:
>> Nodes A, B and C belong to the same network neighbourhood N1
>> Nodes C, D and E belong to the same network neighbourhood N2
>> - C gets and deploys bundle Foo from E using (2)
>> - as a member of both N1 and N2, bundle Foo becomes then available
>> to all members of N1 and N2 because of (3) and (1)
>> - E dies
>> - A and B can get and deploy bundle Foo from C rather than from E.
>> I'd like hints on how to best use the OBR infrastructure to achieve
>> (1), (2) and especially (3). Maybe it needs to be modified ?
>> Or maybe there are better solutions than the OBR infrastructure ?
>> I looked at OBRs because the OBR client can download from multiple
>> OBRs, and transitive dependencies are handled.
>> However, I noticed that:
>>    * updating OBR XML files takes some work. There's the Maven plugin,
>>      but I'd rather not use that in production, there should be
>>      something leaner;
>>    * when deploying a bundle, ResolverImpl.deploy() calls
>>      BundleContext.installBundle() but does not keep a separate copy
>>      of the bundle, which I'd like to do;
>>    * dumping the local repository to XML form, through
>>      DataModelHelper.**writeRepository(), is easy, but there are no
>>      URIs for the bundles in there. As a consequence, even if I
>>      exposed the local repository XML file on the network, OBR
>>      clients wouldn't be able to install the bundles.
>> For demo purposes, I can build a custom solution, starting by exposing
>> through servlets directories containing bundles. In fact, I have been
>> given some code that does just that. From that point, I have made some
>> rough code to download and install individual bundles into the target
>> framework.
>> But for production use, I'll want to provide some higher-level
>> information (bundle symbolic names, dependencies, etc.) and handle
>> transitive dependencies... which brings me back to the already
>> invented OBR wheel :)
>> Thanks in advance for replies,
>> Lionel.
>> ______________________________**__
>> Ce message et les pièces jointes sont confidentiels et réservés à  l'usage
>> exclusif de ses destinataires. Il peut également être  protégé par le secret
>> professionnel. Si vous recevez ce message par  erreur, merci d'en avertir
>> immédiatement l'expéditeur et de le  détruire. L'intégrité du message ne
>> pouvant être assurée sur  Internet, la responsabilité du groupe Atos ne
>> pourra être engagée  quant au contenu de ce message. Bien que les meilleurs
>> efforts  soient faits pour maintenir cette transmission exempte de tout
>>  virus, l'expéditeur ne donne aucune garantie à cet égard et sa
>>  responsabilité ne saurait être engagée pour tout dommage résultant  d'un
>> virus transmis.
>> This e-mail and the documents attached are confidential and intended
>>  solely for the addressee; it may also be privileged. If you receive  this
>> e-mail in error, please notify the sender immediately and  destroy it. As
>> its integrity cannot be secured on the Internet, the  Atos group liability
>> cannot be triggered for the message content.  Although the sender endeavors
>> to maintain a computer virus-free  network, the sender does not warrant that
>> this transmission is  virus-free and will not be liable for any damages
>> resulting from any  virus transmitted.
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<users-unsubscribe@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message