Actually, feature <config/> now populate the etc folder as well (since
Karaf 4.0.5 AFAIR).
Regards
JB
On 11/28/2016 02:50 PM, Christian Schneider wrote:
You already found the confiFile option for features. This is the most
widely used option.
The alternative is the config option which simply adds the config in
config admin but not in etc.
Both variants do not cover the upgrade case. A simply way is to just
remove the old config to make sure the new default one is written. There
is no built in mechanism to preserve user changes in karaf.
Christian
On 28.11.2016 14:05, Tim Ward wrote:
I'm trying to work out how to handle configuration of a system
deployed to Karaf.
I can see that configuration items put into etc/<PID>.cfg end up being
passed to the @Activate method (or whatever), and that you can change
configuration either by editing the .cfg file or from the Karaf
command line (or, I'm guessing, from a JMX console). So that's all
fine, I think.
The parts of the process that I don't yet understand are
(a) getting the .cfg file into etc in the first place
(b) what happens on upgrade.
Let's say the Java source files for the code are in git, and get built
into bundles using Eclipse, and the bundles are installed into Karaf
by some mechanism (I gather that there are some choices, such as
simply dropping the bundle files into the deploy directory). So the
first question is, how do the initial, default, states of the .cfg
files get from git into the etc directory (I'm hoping for a less error
prone answer than checking them out manually and copying them manually)?
Then, the life cycle of a configuration file in other contexts is
typically
(1) when the software is first installed, the initial, default state
of the configuration file gets installed at the same time as part of
the same process
(2) the user then edits the configuration file to suit this particular
deployment
(3) a later upgrade to the software comes with a new version of the
configuration file containing some new items, and the upgrade process
must ensure that neither these new items nor the user changes at (2)
get lost.
So how is this managed?
What I've found so far is that one can create a "feature" and use
<configfile>. But the documentation I've seen doesn't appear to cope
with upgrade - I think it said that new versions of config files would
be silently discarded if an old version was already there? - which
doesn't meet the case (our Operations people get quite cross with
upgrades that do this). At the very very least there needs to be a
clear warning flagged up to the user that they need to do a manual merge.
And, what is the "URL" that one puts in a <configfile>, assuming that
there's a solution to the upgrade issue?
To summarise my questions:
(A) What are the options for getting initial, default config files
from git to etc?
(B) How do people cope with the upgrade issue?
(C) If features and <configfile> are part of the solution, what's the
"URL"?
Thanks.
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
