karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Krzysztof Sobkowiak <krzys.sobkow...@gmail.com>
Subject Re: [HEADS UP] Profiles and static distributions
Date Thu, 11 Dec 2014 23:26:04 GMT
Hi Guillaume

I can see here the Fabric profiles. Do you plan to implement commands to
create/edit/delete profiles too?

Regards
Krzysztof

On 12.12.2014 00:11, Guillaume Nodet wrote:
> 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
>>


-- 
Krzysztof Sobkowiak

JEE & OSS Architect | Senior Solution Architect @ Capgemini | Committer
@ ASF
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <mailto:krzys.sobkowiak@gmail.com> |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC

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