karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject [HEADS UP] Profiles and static distributions
Date Thu, 11 Dec 2014 08:04:12 GMT
I've just committed to the 4.x branch two new features:
  * profiles
  * static distributions


A profile is a data structure that brings together configuration and
provisioning, so it's related to features, but is quite different.  A demo
is available at [1].
A profile contains a list of configuration files which can be either
properties based or in any other format.  Properties based configurations
are handled in a very specific way, as they can overlay each other (more
One of this properties based configuration holds provisioning informations
along with profiles specific attributes, such as a list of parent profiles,
a list of bundles, a list of features repositories and a list of features.

A profile can have one or more parents, so the hierarchy is an inverted
tree.  This allows to define generic profiles and specialise them in

Overlay profile: at some point, there is a need to flatten this hierarchy
into an "overlay" profile.  This process is done by walking into the
parents hierarchy (depth first) and computing the resulting configuration
for each configuration file.  Non properties configuration files simply
overwrite each other, while properties based configuration complement each
other (with the ability to clear a single value or all values).

Effective profile: properties configurations can contain placeholders to
resolve. The only one defined atm is a property placeholder pointing to a
value in a different configuration.  Those placeholders are resolved on the
overlay profile to give the end result effective profile which will be
actually used.  An example of using this placeholder is shown in [2] which
end up pointing to the configuration in its parent [3]

Provisioning: each profile contains a list of feature repositories,
features and bundles.  Those information will be used in the effective
profile to know which bundles and features are needed on a given instance.
  Profiles are not used at runtime for the moment and there are 2 main
usage : creating child instances and generating distributions using the
maven plugin.

Profile manipulation : profiles are manipulated using the Profiles class
(static helpers) and the ProfileBuilder (to build profile instances, which
are immutable).  Reading and writing profiles is done using the jdk7 in
FileSystem / Path interface, which obviously provides support for the
standard file system, but could be used with various file systems (inside a
zip [4], readonly github remote repository [5], sftp [6], in memory [7].
Those are the ones I know about).  A set of commands can be used to edit
the profiles.

Further considerations: possible improvements include an overlay mechanism
for xml, integration with cellar, file systems using a real git repo,
hazelcast, zookeeper, etc...  Applying profiles at runtime could be done
too.   Better integration with kars could be provided too.

Static distributions

One use case of profiles is to generate distributions.  Changes on the
profile need a rebuild on the distribution (this may or may not be a
problem, depending on your environment, but if it can seems weird in an
OSGi world, it's not so much in a cloud environment). This leads to the
distribution being mostly static, i.e. the user should not manually install
/ uninstall stuff.
A demo is available at [8]
Based on this idea, I improved the maven plugin a bit to allow generating
mostly static distribution : the profiles / features are all installed in
etc/startup.properties.  A simplistic read-only configuration admin is used
that will pick up configuration in the etc/ folder directly.  This lead to
no runtime dependencies for the provisioning of karaf itself : fileinstall,
the features service can all be removed.  The bare framework can only
contain 3 bundles : pax-logging + the static configadmin [9].  One
improvement is that the distribution is generated using reference:file:
urls in startup.properties, avoiding a copy of each jar into the cache.  An
additional improvement could be to pre-compute the wiring which can take
some time (but this is not supported by felix).

Thoughts welcomed !

[1] https://github.com/apache/karaf/tree/master/demos/profiles
[5] https://github.com/gnodet/githubfs
[7] https://github.com/google/jimfs
[8] https://github.com/apache/karaf/blob/master/demos/profiles/static/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message