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 <[email protected]>: > 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 <[email protected]>: > > > >> 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é <[email protected]>: > >> > >>> 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é > >>> [email protected] > >>> 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: [email protected] <mailto:[email protected]> | > Twitter: @KSobkowiak > Calendar: http://goo.gl/yvsebC >
