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!

Comments

Post a Comment

Popular posts from this blog

Apache Karaf

ApacheCon was really interesting this year! Recently, a lot of people have expressed a real interest in ServiceMix Kernel , our generic OSGi distribution for server side applications. We've been discussing moving this subproject into Apache Felix for several reasons: raise the visibility and awareness on ServiceMix Kernel attract a broader community Several Apache projects are planning to use ServiceMix Kernel as their container: this includes Apache James , Apache Directory and Apache ActiveMQ . The Apache Sling community is also willing to contribute to this effort along with some other groups like the OPS4J project. During this discussion, a name as been proposed by Jamie Goodyear: Apache Karaf . A carafe is a small container used for serving wine and other drinks (http://en.wikipedia.org/wiki/Carafe). In similarity to the name the Kernel allows applications to be more easily handled, and improves their characteristics (much like a bottle of wine left to breath in a dec...
Read more

Camel Endpoint DSL

Image
Camel Endpoint DSL One of the new features of Camel 3.0  is an Endpoint DSL.  This new API aims to provide a type safe replacement for the URLs that are used in Camel to designate the consumer or producer endpoints.  These URLs provide 3 things: the scheme of the URL identifies the component to use, a unique name or id for the endpoint, and a set of parameters to customize the endpoint behavior. Here is an example of an FTP consumer endpoint definition: from( "ftp://foo@myserver?password=secret& recursive=true& ftpClient.dataTimeout=30000& ftpClientConfig.serverLanguageCode=fr" ) .to( "bean:doSomething" ); There are several drawbacks with such constructs : no type safety, bad readability and no simple completion. So we now use the meta model, which is currently extracted from the source using an annotation processor and written in various JSON files, to generate a fluent DSL for each endpoint.  The same...
Read more

ActiveMQ Pooling

Over the past weeks, I spend some times load testing ServiceMix and ActiveMQ . I discovered two things: * ActiveMQ broker is currently single threaded for a given JMS connection. The main effect is that if you send messages from several threads on the same connection, all threads will be processing sequentially (well, not exactly, but they will all be processed by a single thread on the broker side). * ActiveMQ Resource Adapter does not pool sessions and producers: this means that sending a single message with Jencks using the JMS best practices in a J2EE environment (create a connection, create a session, create a producer, send, close all) will take three consecutive roundtrips to the JMS broker and is very CPU intensive for the broker (at least, when using JMX). The first problem is mainly apparent when using persistent messages and there are a few things than can be used to speed up things (see the LogicBlaze tuning guide for ActiveMQ). However these tuning tweaks are no...
Read more