Indeed. I haven't seen them before. I think it will be a great feature together with Docker and Kubernetes support
Regards Krzysztof On 12.12.2014 00:46, Guillaume Nodet wrote: > 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 >> -- Krzysztof Sobkowiak JEE & OSS Architect | Technical 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
