You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by "Uwe K." <Ko...@t-online.de> on 2011/11/25 21:08:39 UTC
[DISCUSS] Extensions to features
Hello,
as our projects are moving forward we are running slowly in some sort of
maintenance problems as our projects are getting complexer.
Some (perhaps even most) of the problems could be solved by two extensions
to the features mechanism:
1. The ability to "install" a configuration is a great thing, but currently
only new configurations are installed. So if a configuration for a given PID
exists, it isn't touched.
For us it would be very helpful to be able to extend an existing
configuration by merging the new properties of a config-feature to the
existing configuration.
For example:
The initial configuration looked like:
<feature name="config-feature" version="1.0">
<config name="sample.conf">
prop1=value1
</config>
</feature>
The updated configuration could be:
<feature name="config-feature" version="1.1">
<config name="sample.conf">
prop1=value1
prop2=value2
</config>
</feature>
So if you install config-feature/1.0, uninstall it and install
config-feature/1.1, prop2 will not be set/initialized in CM, since
"sample.conf" is existing.
It would be very nice if the config-installer would be able to process the
existing configuration and at least adds properties that are not existing.
Possibly the behaviour of the config-installer could be influenced by an
extension to the "config"-tag. Something like
<config name="sample.conf" mergeconf="yes/no/overwrite">
would even allow the complete overwriting of an existing configuration.
2. The feature-definitions open the ability to "chain" to installation of
features by defining dependend features. So you could install a "main"
feature that includes all features you need to run your application. If you
install "main" all the defined and needed features are installed
(recursively).
But when you uninstall the "main" feature, all other features (referenced in
"main") aren't touched and are kept installed and each of them has to
uninstalled "by hand".
So an extension like "features:uninstall -r main" would be helpful that
uninstalls all dependend features recursively just like "features:install"
does for installing features.
I am aware of the fact that this not exactly the way features should be used
and that it is much more complex than described (look up features already
installed, etc.), but such an extension would make life much more easier.
Excuses if I missed some point or didn't understand something, since I am
wondering that no one else seems to ran in these problems so far.
Thank you for any responses/opinions.
Best regards,
Uwe.
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Extensions-to-features-tp3536881p3536881.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Extensions to features
Posted by "Uwe K." <Ko...@t-online.de>.
Hi Björn,
thank your for your support.
One of the most important reasons to choose Karaf was in fact the
feature-management with the option to uninstall/install features (bundles)
even on a fully running instance (and it really works).
The complete re-install was never an option for us, because actually with
300+ installations there are still around 10 percent of the instances in the
WAN which or only connected by ISDN or DSL-light (128kB). With a
cache-directory (alone) of 130-150MB it would take days to rollout an
update.
Btw.: Do you have only standard configurations for the installations or how
do you manage the existing configurations somehow (apart from backing up
.../bundles/5/*)
We started writing a tool that saves the configuration by reading them via
jmx and packing them into a single zip. But that is not an ideal solution in
all cases. So we are thinking about a shell-extension for backing up and
restoring configurations. This would for example provide a way to upgrade an
existing karaf-instance to a new Version (as karaf-3 is knocking at the
door).
Best regards,
Uwe.
Björn Bength wrote
>
> +1
> Uninstalling dependent features is a feature we also reeeally need some
> times.
> Now, most of our deployments and provisioning starts by simply removing
> karaf from disk completely and start fresh with unzipping a new copy.
> Or simply removing the data directory and start over.
> Regards
> Björn
>
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Extensions-to-features-tp3536881p3538529.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Extensions to features
Posted by Björn Bength <bj...@gmail.com>.
+1
Uninstalling dependent features is a feature we also reeeally need some
times.
Now, most of our deployments and provisioning starts by simply removing
karaf from disk completely and start fresh with unzipping a new copy.
Or simply removing the data directory and start over.
Regards
Björn
On Nov 25, 2011 9:36 PM, "Jean-Baptiste Onofré" <jb...@nanthrax.net> wrote:
> Hi Uwe,
>
> first of all, thanks for using Karaf and sharing your experience ;)
>
> See my comments inline:
>
> 1. The ability to "install" a configuration is a great thing, but
>> currently
>> only new configurations are installed. So if a configuration for a given
>> PID
>> exists, it isn't touched.
>> For us it would be very helpful to be able to extend an existing
>> configuration by merging the new properties of a config-feature to the
>> existing configuration.
>> For example:
>> The initial configuration looked like:
>> <feature name="config-feature" version="1.0">
>> <config name="sample.conf">
>> prop1=value1
>> </config>
>> </feature>
>>
>> The updated configuration could be:
>> <feature name="config-feature" version="1.1">
>> <config name="sample.conf">
>> prop1=value1
>> prop2=value2
>> </config>
>> </feature>
>>
>> So if you install config-feature/1.0, uninstall it and install
>> config-feature/1.1, prop2 will not be set/initialized in CM, since
>> "sample.conf" is existing.
>>
>> It would be very nice if the config-installer would be able to process the
>> existing configuration and at least adds properties that are not existing.
>> Possibly the behaviour of the config-installer could be influenced by an
>> extension to the "config"-tag. Something like
>> <config name="sample.conf" mergeconf="yes/no/overwrite">
>> would even allow the complete overwriting of an existing configuration.
>>
>
> A similar behavior exists if you use <configfile/> instead of <config/>.
> With <configfile/>, if the final configuration file already exists, you
> can set an attribute to override existing configuration.
> Regarding the <config/> tag, it makes sense to have something similar.
> If overwrite is easy to do, merge could be tricky.
> Anyway, I'm gonna raise the Jira for that, as it could be an interesting
> and logic enhancements for Karaf 3.0.
>
>
>>
>> 2. The feature-definitions open the ability to "chain" to installation of
>> features by defining dependend features. So you could install a "main"
>> feature that includes all features you need to run your application. If
>> you
>> install "main" all the defined and needed features are installed
>> (recursively).
>> But when you uninstall the "main" feature, all other features (referenced
>> in
>> "main") aren't touched and are kept installed and each of them has to
>> uninstalled "by hand".
>>
>
> True, it's the expected behavior as a dependent feature could be installed
> "outside" the main feature.
>
>
>> So an extension like "features:uninstall -r main" would be helpful that
>> uninstalls all dependend features recursively just like "features:install"
>> does for installing features.
>> I am aware of the fact that this not exactly the way features should be
>> used
>> and that it is much more complex than described (look up features already
>> installed, etc.), but such an extension would make life much more easier.
>>
>
> The -r (as recursive) option could be interesting on a feature. I'm OK to
> be an option, and raise a warning to the user that use it, as it could be
> very very dangerous ;)
>
>
> Regards
> JB
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [DISCUSS] Extensions to features
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
No problem Uwe,
I will try to work on it tomorrow and Monday.
Regards
JB
On 11/26/2011 07:08 PM, Uwe K. wrote:
> Hi Jean-Baptiste,
>
> thank you for your quick response and for raising the Jira-issues.
> That's one of the reasons, why we have chosen Karaf as a strategic
> platform...
>
> Maybe I could supply a patch for the config-issue (KARAF-1046). Some times
> ago (in karaf-1.x) we started testing around with such an extension, but it
> got never in production (priorities....).
> I'll have a look if I can get it recycled.
>
> Best regards,
>
> Uwe.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Extensions-to-features-tp3536881p3538478.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSS] Extensions to features
Posted by "Uwe K." <Ko...@t-online.de>.
Hi Jean-Baptiste,
thank you for your quick response and for raising the Jira-issues.
That's one of the reasons, why we have chosen Karaf as a strategic
platform...
Maybe I could supply a patch for the config-issue (KARAF-1046). Some times
ago (in karaf-1.x) we started testing around with such an extension, but it
got never in production (priorities....).
I'll have a look if I can get it recycled.
Best regards,
Uwe.
--
View this message in context: http://karaf.922171.n3.nabble.com/DISCUSS-Extensions-to-features-tp3536881p3538478.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Extensions to features
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Uwe,
first of all, thanks for using Karaf and sharing your experience ;)
See my comments inline:
> 1. The ability to "install" a configuration is a great thing, but currently
> only new configurations are installed. So if a configuration for a given PID
> exists, it isn't touched.
> For us it would be very helpful to be able to extend an existing
> configuration by merging the new properties of a config-feature to the
> existing configuration.
> For example:
> The initial configuration looked like:
> <feature name="config-feature" version="1.0">
> <config name="sample.conf">
> prop1=value1
> </config>
> </feature>
>
> The updated configuration could be:
> <feature name="config-feature" version="1.1">
> <config name="sample.conf">
> prop1=value1
> prop2=value2
> </config>
> </feature>
>
> So if you install config-feature/1.0, uninstall it and install
> config-feature/1.1, prop2 will not be set/initialized in CM, since
> "sample.conf" is existing.
>
> It would be very nice if the config-installer would be able to process the
> existing configuration and at least adds properties that are not existing.
> Possibly the behaviour of the config-installer could be influenced by an
> extension to the "config"-tag. Something like
> <config name="sample.conf" mergeconf="yes/no/overwrite">
> would even allow the complete overwriting of an existing configuration.
A similar behavior exists if you use <configfile/> instead of <config/>.
With <configfile/>, if the final configuration file already exists, you
can set an attribute to override existing configuration.
Regarding the <config/> tag, it makes sense to have something similar.
If overwrite is easy to do, merge could be tricky.
Anyway, I'm gonna raise the Jira for that, as it could be an interesting
and logic enhancements for Karaf 3.0.
>
>
> 2. The feature-definitions open the ability to "chain" to installation of
> features by defining dependend features. So you could install a "main"
> feature that includes all features you need to run your application. If you
> install "main" all the defined and needed features are installed
> (recursively).
> But when you uninstall the "main" feature, all other features (referenced in
> "main") aren't touched and are kept installed and each of them has to
> uninstalled "by hand".
True, it's the expected behavior as a dependent feature could be
installed "outside" the main feature.
>
> So an extension like "features:uninstall -r main" would be helpful that
> uninstalls all dependend features recursively just like "features:install"
> does for installing features.
> I am aware of the fact that this not exactly the way features should be used
> and that it is much more complex than described (look up features already
> installed, etc.), but such an extension would make life much more easier.
The -r (as recursive) option could be interesting on a feature. I'm OK
to be an option, and raise a warning to the user that use it, as it
could be very very dangerous ;)
Regards
JB
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com