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
