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.
--
Tim Ward
