Advice on the best method/practice for taking advantage of using Karaf to install bug fixes into a production environment

[Tim Jones <ti...@mccarthy.co.nz>]

Hi, I am looking for advice on the best method/practice for taking advantage
of using Karaf to install bug fixes into a production environment. 

The scenario we face is a dozen or so sites running Karaf with what is
essentially a customised product. These sites are spread across the country
but are connected via a network (which in some cases is fairly slow) and
communicate with each other.

OSGI/Karaf was chosen so as to provide the possibility of 'hot deploying'
bug fixes while trying cause minimal disruption to a system that
controls/monitors PLCs, label readers + other on a food processing floor.

Currently the deliverable is a large zip file containing a directory
structure that includes a slightly bastardised copy of the Karaf
directories/files (doesn't include the bin directory + the 3rd party and
application bundles have been added below the osgi/system directory). Karaf
is started programmatically via org.apache.karaf.main.Main.main(). The
bundles required are defined in a features file.

Currently a change requires the zip file to be FTPed to the sites, unzipped,
the Karaf server shut down, symbolic links changed to point to the new
installation and the server restarted from a custom shell script which in
turn runs a class that invokes org.apache.karaf.main.Main.main(). Obviously
this process has many downsides and certainly wont address minimising
disruption to the food processing plants.

Given that a bundle may have a bug what processes/practices are others using
to getting their modified bundle into a production environment? For example
we could 

a) FTP the bundle to the site and use the Karaf console to install and
update/refresh the necessary bundle

b) Set up a repository server (we use Nexus) at each site that mirrors our
one and refresh that then use the 
Karaf console to install and update/refresh the necessary bundle

c) Would the sub project Karaf Cave help here?


What is the best way of keeping track of what bundles are actually running
at each site? For example given that each site could potentially be running
different versions of the same bundle would you rely on say dumping out all
the bundle headers to say essentially 'these are the versions of the bundles
that are currently running at this site'?

Since we rely on the features file essentially 'defining' what our
application is comprised of, how do we coordinate this with the newly
installed bundle? Should the features file at the site be updated to reflect
the new version of the bundle?

Any other advice, things to consider would be most welcome.


thanks,

Tim



--
View this message in context: http://karaf.922171.n3.nabble.com/Advice-on-the-best-method-practice-for-taking-advantage-of-using-Karaf-to-install-bug-fixes-into-a-pt-tp4028520.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Advice on the best method/practice for taking advantage of using Karaf to install bug fixes into a production environment

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Tim,

I think that the provisioning from a repo is the easiest way.

You can share the Maven repo between your Karaf instances. You uploaded 
your features/bundles to this repo, and upgrade the Karaf instances with 
the new version (features:uninstall/features:install).
To avoid to do that on each Karaf instances, you can use Cellar which is 
able to spread the provisioning commands to all Karaf instances.

Cave is an OBR repository wrapper: it can host or take Maven 
repositories and expose them as OBR repositories. So basically, it uses 
the same approach as a Maven repository (the advantage of OBR is that 
you can install just a bundle, the OBR will resolve the dependencies for 
you, no need of a feature).

Regards
JB

On 04/30/2013 01:54 AM, Tim Jones wrote:
> Hi, I am looking for advice on the best method/practice for taking advantage
> of using Karaf to install bug fixes into a production environment.
>
> The scenario we face is a dozen or so sites running Karaf with what is
> essentially a customised product. These sites are spread across the country
> but are connected via a network (which in some cases is fairly slow) and
> communicate with each other.
>
> OSGI/Karaf was chosen so as to provide the possibility of 'hot deploying'
> bug fixes while trying cause minimal disruption to a system that
> controls/monitors PLCs, label readers + other on a food processing floor.
>
> Currently the deliverable is a large zip file containing a directory
> structure that includes a slightly bastardised copy of the Karaf
> directories/files (doesn't include the bin directory + the 3rd party and
> application bundles have been added below the osgi/system directory). Karaf
> is started programmatically via org.apache.karaf.main.Main.main(). The
> bundles required are defined in a features file.
>
> Currently a change requires the zip file to be FTPed to the sites, unzipped,
> the Karaf server shut down, symbolic links changed to point to the new
> installation and the server restarted from a custom shell script which in
> turn runs a class that invokes org.apache.karaf.main.Main.main(). Obviously
> this process has many downsides and certainly wont address minimising
> disruption to the food processing plants.
>
> Given that a bundle may have a bug what processes/practices are others using
> to getting their modified bundle into a production environment? For example
> we could
>
> a) FTP the bundle to the site and use the Karaf console to install and
> update/refresh the necessary bundle
>
> b) Set up a repository server (we use Nexus) at each site that mirrors our
> one and refresh that then use the
> Karaf console to install and update/refresh the necessary bundle
>
> c) Would the sub project Karaf Cave help here?
>
>
> What is the best way of keeping track of what bundles are actually running
> at each site? For example given that each site could potentially be running
> different versions of the same bundle would you rely on say dumping out all
> the bundle headers to say essentially 'these are the versions of the bundles
> that are currently running at this site'?
>
> Since we rely on the features file essentially 'defining' what our
> application is comprised of, how do we coordinate this with the newly
> installed bundle? Should the features file at the site be updated to reflect
> the new version of the bundle?
>
> Any other advice, things to consider would be most welcome.
>
>
> thanks,
>
> Tim
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Advice-on-the-best-method-practice-for-taking-advantage-of-using-Karaf-to-install-bug-fixes-into-a-pt-tp4028520.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com