karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [HEADS UP] Profiles and static distributions
Date Thu, 11 Dec 2014 23:11:22 GMT
Profiles are only used to generate a new assembly or child instance.

The "static" distributions is related to profiles, but can be generated out
of a pure feature list.  Such distributions, once started, are usually
limited (my initial goal was to really lock it down), at least that's the
case in the demo i pushed.  But this is somewhat controlled by the demo
itself (i.e. the fact that file install + features service aren't installed
is because the plugin is told to use a non standard framework instead of
the default one).  So once it has been started, such a static distribution
is "mostly" static, but it's still a valid osgi framework, so if you have a
way to access it (through the locale console, ssh or jmx) you could
manually install the features service bundle, then use it install
additional features.  But if everything has been disabled ...

That said, I suppose profiles could be enhanced to support applying a
profile at runtime, but it opens a whole bunch of different problems.


2014-12-11 22:46 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com>:

> Hi Guillaume,
>
> I'd have to play with it to get the full picture of the consequences.
> But from what I've seen so fare I like the idea.
> Just for clarification, profiles are a "blueprint" for generating a custom
> distribution during build time, but not while running already
> or is it possible to start a "static" karaf container and customize it
> after it has been started?
>
> regards, Achim
>
> 2014-12-11 10:19 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>
> > Thanks Guillaume,
> >
> > I gonna review and update the documentation.
> >
> > Regards
> > JB
> >
> >
> > On 12/11/2014 09:04 AM, Guillaume Nodet wrote:
> >
> >> I've just committed to the 4.x branch two new features:
> >>    * profiles
> >>    * static distributions
> >>
> >> Profiles
> >> ======
> >>
> >> 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
> >> below).
> >> 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
> >> children.
> >>
> >> 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
> >> [2]
> >> https://github.com/apache/karaf/blob/master/demos/
> >> profiles/registry/src/main/resources/karaf.profile/profile.cfg#L25
> >> [3]
> >> https://github.com/apache/karaf/blob/master/demos/
> >> profiles/registry/src/main/resources/default.profile/version.cfg
> >> [4]
> >> http://docs.oracle.com/javase/7/docs/technotes/guides/io/
> >> fsp/zipfilesystemprovider.html
> >> [5] https://github.com/gnodet/githubfs
> >> [6]
> >>
> https://github.com/gnodet/mina-sshd/commit/f68468c686099f6f12a9093e949c09
> >> e16f618704
> >> [7] https://github.com/google/jimfs
> >> [8] https://github.com/apache/karaf/blob/master/demos/profiles/static/
> >> [9]
> >> https://github.com/apache/karaf/blob/master/demos/
> >> profiles/static/src/main/resources/features.xml
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>

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