Saturday, May 07, 2011

Configuration with FuseSource Fabric

From a high level, ZooKeeper can be seen as a replicated tree, and Fabric uses this tree to store the configuration of the various agents (we call Agent, any Karaf instance connected to the same Fabric cluster).

Fabric defines a notion of profile, which is a "kind" of agent. We can define different profiles for various applications we want to deploy in Karaf, for example an ActiveMQ broker or a web server. A given agent can be assigned multiple profiles, allowing a single Karaf instance to serve multiple purposes.

To configure a Karaf instance, Fabric uses the ConfigAdmin OSGi service which is the standard way to push configurations to OSGi applications. An agent will have a bundle deployed which will monitor the ZooKeeper tree and update the configurations according to the profiles it has been assigned. Each bundle will then automatically be notified of the changes through the ConfigAdmin service.

It is often the case that configurations are mostly the same between several nodes, but to one or two parameters that may change. In order to increase sharing between profiles, profiles can inherit other profiles. The actual configurations are computed using an overlay mechanism so that the parent's configurations are overriden by the children ones.

The zookeeper layout for the configurations is setup using the following nodes in the zookeeper tree:
/fabric/configs/agents/{agent}
/fabric/configs/versions/{version}/agents/{agent}
/fabric/configs/versions/{version}/profiles/{profile}


The first node contains the {version} used for a given agent. I'll explain more about versions in a later post. Once we have the version, we can go the the second node which will give the list of profiles assigned to that node. The computation is done by going to the list of parents and retrieving the configurations maps which are organized as following:
 /.../{profile}/{pid}/{key}

A profile can contain any number of such nodes, which gives a map (indexed by the {pid}) of maps (indexed by the {key}) and which values are the content of the node. A special value #deleted# can be used to flag a {pid} or {key} as deleted so that it won't appear in the overlaid configuration. The {pid} will be used as the OSGi configuration pid and the contents will be the various {key}s defined. Note that a {pid}containing a dash will be identified as a factory pid.

After creating creating the ZooKeeper server in Fabric using the fabric:zk-cluster root command, you can experiment with the zookeeper commands and see the changes reflected on agents.

Provisioning is done through this very mechanism. My next post will explain in details how this is done. Stay tuned!

Wednesday, May 04, 2011

Introducing FuseSource Fabric

I'm very pleased to introduce FuseSource Fabric, a distributed configuration, management and provisioning system for the products supported by FuseSource: Apache ServiceMix, Apache Camel, Apache ActiveMQ and Apache CXF.

The user's guide contains lots of informations, so I won't rewrite it all again, but I instead invite you to have a quick look at it. The core Fabric is deployed on top of Apache Karaf and heavily reuses the very mature Apache ZooKeeper project.

I'm really excited about Fabric. I've been working on it since Apache Karaf 2.2.0 has been released and I'm glad to share this work. I won't add much more for now, but stay tuned as I plan to write a number of posts explaining the various parts of Fabric.

Tuesday, May 03, 2011

CamelOne conference


I just want to point out the great conference FuseSource is sponsoring around open source integration and especially Apache Camel. Unfortunately, I won't be able to attend the event as my wife is expecting our sixth child in the coming weeks :-). That would have been a great opportunity to have my copy of the EIP book signed by Gregor though.

You should definitely go there and listen to all the great speakers. Click on the image below for more informations.


CamelOne