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:46:17 GMT
Those commands already exists.

Yes, the concept is a port of fabric profiles with major simplifications :
no versioning of profiles, no real runtime registry management and no
runtime application of profiles to existing containers.

2014-12-12 0:26 GMT+01:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com>:

> 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