You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by DEBROUX Lionel <Li...@atos.net> on 2011/10/08 10:24:01 UTC
Deploying bundles across "equal" nodes...
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.
RE : Deploying bundles across "equal" nodes...
Posted by DEBROUX Lionel <Li...@atos.net>.
Hello,
Thanks Richard for your reply :)
> Ultimately, you will need a "custom" solution as you suggest at the
> bottom, but it can still be based on OBR to some degree or the other.
OK :)
> The OBR API allows you to provide repositories, so you just need to
> define your own which don't have to be XML based. Then you can pass
> them to the OBR resolver. As far as deployment, you'd have to handle
> any additional work you need, but you can inspect the resolved
> result to know what bundles will be deployed when you call
> deploy()...
Indeed.
> the only trick is that the deploy() method tries to update in some
> cases and install in others and I don't think it tells you in
> advance which it is going to do (it actually calculates if an update
> is possible during deployment).
Yup.
That said, due to other constraints I didn't mention earlier, most of
the time, I'd rather have deploy() method not update bundles.
I'm thinking of adding a new flag for deployment, and patching
void deploy(int flags) so that it doesn't update if this flag is set.
I'll make some tests.
> You could always write your own code to do the deployment based on
> the resolver result. Regardless, what you want to do is possible,
> but will require you to do a bit more work since it is not the use
> case that OBR specifically targeted.
Understood.
Thanks,
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.
Re: Deploying bundles across "equal" nodes...
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Ultimately, you will need a "custom" solution as you suggest at the
bottom, but it can still be based on OBR to some degree or the other.
The OBR API allows you to provide repositories, so you just need to
define your own which don't have to be XML based. Then you can pass them
to the OBR resolver. As far as deployment, you'd have to handle any
additional work you need, but you can inspect the resolved result to
know what bundles will be deployed when you call deploy()...the only
trick is that the deploy() method tries to update in some cases and
install in others and I don't think it tells you in advance which it is
going to do (it actually calculates if an update is possible during
deployment).
You could always write your own code to do the deployment based on the
resolver result. Regardless, what you want to do is possible, but will
require you to do a bit more work since it is not the use case that OBR
specifically targeted.
-> richard
On 10/8/11 4:24 AM, DEBROUX Lionel wrote:
> 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
For additional commands, e-mail: users-help@felix.apache.org
Re: RE : Deploying bundles across "equal" nodes...
Posted by Arjun Panday <ar...@alcatel-lucent.com>.
Hi Lionel,
I've recently shared some thoughts and return of experience in the blog
post below, about using the OBR to build clusters.
The article focuses on dependency resolution rather than network
topology, but you may still be interested:
http://techjoune.blogspot.com/2011/07/osgi-obr-in-cluster-return-of.html
Best regards,
Arjun
On 10/10/2011 06:36 PM, DEBROUX Lionel wrote:
> Hello,
>
>>> "Jean-Philippe Clement"<je...@sogeti.com> wrote:
>>> => http://fabric.fusesource.org/
>>>
>>> Kind regards,
>>> Jean-Philippe
>> Andreas Pieber<an...@gmail.com> wrote:
>> An alternative solution might be the apache karaf cellar project
>> karaf.apache.org
>>
>> Kind regards
> Thanks both of you :)
> I've started looking at those, and noticed fixing of KARAF-628
> "Bundle replication" in the release notes, which could be good
> for me :)
>
>
> Regards,
> 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
For additional commands, e-mail: users-help@felix.apache.org
RE : Deploying bundles across "equal" nodes...
Posted by DEBROUX Lionel <Li...@atos.net>.
Hello,
> > "Jean-Philippe Clement" <je...@sogeti.com> wrote:
> > => http://fabric.fusesource.org/
> >
> > Kind regards,
> > Jean-Philippe
> Andreas Pieber <an...@gmail.com> wrote:
> An alternative solution might be the apache karaf cellar project
> karaf.apache.org
>
> Kind regards
Thanks both of you :)
I've started looking at those, and noticed fixing of KARAF-628
"Bundle replication" in the release notes, which could be good
for me :)
Regards,
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.
Re: Deploying bundles across "equal" nodes...
Posted by Andreas Pieber <an...@gmail.com>.
An alternative solution might be the apache karaf cellar project
karaf.apache.org
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 <Li...@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<us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Deploying bundles across "equal" nodes...
Posted by Jean-Philippe Clement <je...@sogeti.com>.
=> http://fabric.fusesource.org/
Kind regards,
Jean-Philippe
Quoting DEBROUX Lionel <Li...@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
For additional commands, e-mail: users-help@felix.apache.org