Hi You may want to take a look at Fuse Fabric https://github.com/jboss-fuse/fuse http://fuse.fusesource.org/fabric/
Fuse Fabric : a provisioning, configuration and management solution for Apache Karaf, Apache ServiceMix and Fuse Fabric has the concept of profiles that allows you to describe/define what container(s) should be running. Then you can do rolling upgrades/downgrades of profiles on the containers. And you can have a git store so all the profiles is stored persistent and you have all the power of git, so you can look in the git commit logs for when/who did what, and versioning etc. On the containers a Fabric Agent is running to handle the provisioning and whatnot. Fuse Fabric comes out of the box in JBoss Fuse - http://www.jboss.org/products/fuse. And you have Fabric commands in the Karaf shell, and for web UI you have hawtio - http://hawt.io/ On Fri, Nov 15, 2013 at 5:36 PM, Steve <[email protected]> wrote: > Hello Karaf users, > > I’m in the process of developing a provisioning agent for a > Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features > exclusively as my unit of deployment as opposed to working directly > with individual bundles when provisioning. The Features mechanism is > quite nice and has been pleasant to work with programmatically via the > FeaturesService interface. In the course of developing this agent > though I’ve come up with a few questions, mostly related to > best-practices. I haven’t found answers in existing documentation; if > such information does exist, you have my apologies in advance for > troubling the mailing-list with something already answered elsewhere. > With that being said, here are my questions: > > > > 1.) A container has a Feature installed, “example-app”, at version > 1.0. Now let’s say I decide I want to run version 1.1 at some point > down the road. Would the best practice be to first uninstall the > Feature at version 1.0 and then install version 1.1, or to just > install version 1.1 directly (skipping the explicit uninstall step)? > Currently I use the FeaturesService programmatically to uninstall the > old version prior to install the new. While this seems to work fine, > I thought it wise to inquire if there was an existing best practice > around this or, perhaps, potential pitfalls to be avoided. > > > > 2.) The provisioning agent itself is installed as part of a Feature. > I currently let the agent install a new version of its encapsulating > Feature. With other Features not associated with the agent, as I > mentioned in question #1, I explicitly uninstall the old version prior > to installing the new. For the agent I don’t do this to prevent a > “bundle-suicide” type of situation. When the agent installs a new > version of its encapsulating Feature this triggers an implicit > framework restart after which the new version is installed and the > older version uninstalled. Interestingly enough, if I try to go the > other direction, say from 1.1 back to 1.0, I get unfulfilled > dependencies that prevent the older version of the Feature from > installing (and both features end up uninstalled). The dependency in > question (commons-lang 3.x) is actually embedded in both version 1.0 > and 1.1 of the bundle containing the application (both bundles are > identical except in version number for testing). I suspect the old > version is attempting to import packages from the new version’s > bundle, but fails to do so because the latter is then invalid. Should > I allow my agent to install a new version of its encapsulating Feature > or is this going down the wrong road? Is there a best practice (or > any advice) around a Feature self-update scenario? > > > I will greatly appreciate any information/advice that can be given > (even “RTFM” if you can point me to the right manual). > > > Thanks! > > -Steve -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
