FYI, Fabric is a Apache licensed project from RedHat/Fuse, but not a project from the Apache Software Foundation (it doesn't follow the same policy in term of release/binding vote, etc).

The notion of profiles is in the Karaf roadmap (a bit different from the Fabric profile).

It's the same for hawt.io (not part of Apache Software Foundation, however under the Apache license).

Regards
JB

On 11/18/2013 09:49 AM, Claus Ibsen wrote:
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




--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to