2016-11-28 14:50 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> 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. > Fwiw, both should add the configuration to the etc/ folder. The main difference is that <configfile/> use an external file which can be any kind of file (an xml, or whatever) while <config/> use an inlined properties file and write the config both to config admin and to the etc/ folder. > > 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. >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
