Providing alternative config mechanism than felix.fileinstall/Preserving config changes on re-install

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Providing alternative config mechanism than felix.fileinstall/Preserving config changes on re-install

tomq42
I'm trying to establish some alternative configuration behaviour than what felix-fileinstall gives me.
I have written a very simple component that reads configuration files in from /etc and updates config admin with the information, much like fileinstall does. I can run this and it appears to work, however I still have the existing mechanism in that I'd like to remove.

So I naively did the following:
   set the start-level of my bundle to be 11, same as fileinstall
   set felix.fileinstall.enableConfigSave to false in etc/custom.properties
   set felix.fileinstall.dir to empty

Karaf fails to start.

So my suspicion is that apache fileinstall is more centrally required than I'd hoped. Looking at the karaf code there are certainly a few places where it assumes a configuration contains a felix.fileinstall.filename property that names the file where the configuration is stored, and seems to directly read and write those files. This appears to mean that I wouldn't be able to substitute my own configuration storage backend, which is a shame (I'm actually confused what org.apache.karaf.config.core.ConfigRepository is actually doing here -- why does is write directly to the file, rather than just letting fileinstall do it, especially as it only seems to allow for ".cfg" and not ".config" files). There may be other reasons why karaf won't start though.

Is it likely that I would substitute felix.fileinstall in this way?


What I was actually trying to solve was what to do when a user uninstalls and reinstalls our karaf-based product, and attempting to preserve any configuration changes. What I had hoped to do was store any actually modified configuration properties in separate files (just the actual properties that were different from default or from the originals in the etc/*.cfg files), so that the original etc/*.cfg files would be replaced without difficulty, and the changed configuration changes would then be applied.

So alternative question: How else can I achieve the same thing without making the users manually merge the configuration changes?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Providing alternative config mechanism than felix.fileinstall/Preserving config changes on re-install

jbonofre
Hi

I guess you want to use an alternative backend to the filesystem (a database for instance).

In that case we have a Jira about that and you can provide your own persistence backend.

Regards
JB
On Oct 6, 2017, at 12:30, [hidden email] wrote:
I'm trying to establish some alternative configuration behaviour than what felix-fileinstall gives me.
I have written a very simple component that reads configuration files in from /etc and updates config admin with the information, much like fileinstall does. I can run this and it appears to work, however I still have the existing mechanism in that I'd like to remove.

So I naively did the following:
set the start-level of my bundle to be 11, same as fileinstall
set felix.fileinstall.enableConfigSave to false in etc/custom.properties
set felix.fileinstall.dir to empty

Karaf fails to start.

So my suspicion is that apache fileinstall is more centrally required than I'd hoped. Looking at the karaf code there are certainly a few places where it assumes a configuration contains a felix.fileinstall.filename property that names the file where the configuration is stored, and seems to directly read and write those files. This appears to mean that I wouldn't be able to substitute my own configuration storage backend, which is a shame (I'm actually confused what org.apache.karaf.config.core.ConfigRepository is actually doing here -- why does is write directly to the file, rather than just letting fileinstall do it, especially as it only seems to allow for ".cfg" and not ".config" files). There may be other reasons why karaf won't start though.

Is it likely that I would substitute felix.fileinstall in this way?


What I was actually trying to solve was what to do when a user uninstalls and reinstalls our karaf-based product, and attempting to preserve any configuration changes. What I had hoped to do was store any actually modified configuration properties in separate files (just the actual properties that were different from default or from the originals in the etc/*.cfg files), so that the original etc/*.cfg files would be replaced without difficulty, and the changed configuration changes would then be applied.

So alternative question: How else can I achieve the same thing without making the users manually merge the configuration changes?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Providing alternative config mechanism than felix.fileinstall/Preserving config changes on re-install

tomq42
I can see KARAF-418, but that's pretty old, and sounds like it was considered unnecessary? Is there anything else I can't find?

I don't necessarily want to store things in a database, I just want different behaviour to normal, to provide my own implementation of something that listens to config changes and injects configuration on startup. And I can write that bit, what I can't do is substitute it in at a central enough level to replace fileinstall.

I've made a little progress. I manually edited the "startup.properties" file and put my bundle in there at level 11. It got activated. So what I don't currently understand is a) where that file comes from (it's clearly generated as part of building my karaf distribution, it's not in source control) and b) what specifying the start-level in the feature.xml file does (since it doesn't appear to specify the start level :-)).
My problem now appears to be that I'd written my code using declarative services, and I think I need to go back to old fashioned bundle activators and service trackers in order to reduce the dependencies and make the code work in the "simple" environment I encounter down at that start level.

There was also a comprehension question of why the ConfigRepository was attempting to write the config files directly, rather than just calling Configuration.update. Surely one thing or the other (calling update I assume is preferable), but not both?

Thanks.

> On 06 October 2017 at 11:40 Jean-Baptiste Onofré <[hidden email]> wrote:
>
>
> Hi
>
> I guess you want to use an alternative backend to the filesystem (a database for instance).
>
> In that case we have a Jira about that and you can provide your own persistence backend.
>
> Regards
> JB
>
> On Oct 6, 2017, 12:30, at 12:30, [hidden email] wrote:
> >I'm trying to establish some alternative configuration behaviour than
> >what felix-fileinstall gives me.
> >I have written a very simple component that reads configuration files
> >in from /etc and updates config admin with the information, much like
> >fileinstall does. I can run this and it appears to work, however I
> >still have the existing mechanism in that I'd like to remove.
> >
> >So I naively did the following:
> >   set the start-level of my bundle to be 11, same as fileinstall
> >set felix.fileinstall.enableConfigSave to false in
> >etc/custom.properties
> >   set felix.fileinstall.dir to empty
> >
> >Karaf fails to start.
> >
> >So my suspicion is that apache fileinstall is more centrally required
> >than I'd hoped. Looking at the karaf code there are certainly a few
> >places where it assumes a configuration contains a
> >felix.fileinstall.filename property that names the file where the
> >configuration is stored, and seems to directly read and write those
> >files. This appears to mean that I wouldn't be able to substitute my
> >own configuration storage backend, which is a shame (I'm actually
> >confused what org.apache.karaf.config.core.ConfigRepository is actually
> >doing here -- why does is write directly to the file, rather than just
> >letting fileinstall do it, especially as it only seems to allow for
> >".cfg" and not ".config" files). There may be other reasons why karaf
> >won't start though.
> >
> >Is it likely that I would substitute felix.fileinstall in this way?
> >
> >
> >What I was actually trying to solve was what to do when a user
> >uninstalls and reinstalls our karaf-based product, and attempting to
> >preserve any configuration changes. What I had hoped to do was store
> >any actually modified configuration properties in separate files (just
> >the actual properties that were different from default or from the
> >originals in the etc/*.cfg files), so that the original etc/*.cfg files
> >would be replaced without difficulty, and the changed configuration
> >changes would then be applied.
> >
> >So alternative question: How else can I achieve the same thing without
> >making the users manually merge the configuration changes?
> >
> >Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Providing alternative config mechanism than felix.fileinstall/Preserving config changes on re-install

jbonofre
Hi Tom,

You can implement your own PersistenceManager (ConfigAdmin service).

Regards
JB

On 10/06/2017 01:07 PM, [hidden email] wrote:

> I can see KARAF-418, but that's pretty old, and sounds like it was considered unnecessary? Is there anything else I can't find?
>
> I don't necessarily want to store things in a database, I just want different behaviour to normal, to provide my own implementation of something that listens to config changes and injects configuration on startup. And I can write that bit, what I can't do is substitute it in at a central enough level to replace fileinstall.
>
> I've made a little progress. I manually edited the "startup.properties" file and put my bundle in there at level 11. It got activated. So what I don't currently understand is a) where that file comes from (it's clearly generated as part of building my karaf distribution, it's not in source control) and b) what specifying the start-level in the feature.xml file does (since it doesn't appear to specify the start level :-)).
> My problem now appears to be that I'd written my code using declarative services, and I think I need to go back to old fashioned bundle activators and service trackers in order to reduce the dependencies and make the code work in the "simple" environment I encounter down at that start level.
>
> There was also a comprehension question of why the ConfigRepository was attempting to write the config files directly, rather than just calling Configuration.update. Surely one thing or the other (calling update I assume is preferable), but not both?
>
> Thanks.
>
>> On 06 October 2017 at 11:40 Jean-Baptiste Onofré <[hidden email]> wrote:
>>
>>
>> Hi
>>
>> I guess you want to use an alternative backend to the filesystem (a database for instance).
>>
>> In that case we have a Jira about that and you can provide your own persistence backend.
>>
>> Regards
>> JB
>>
>> On Oct 6, 2017, 12:30, at 12:30, [hidden email] wrote:
>>> I'm trying to establish some alternative configuration behaviour than
>>> what felix-fileinstall gives me.
>>> I have written a very simple component that reads configuration files
>>> in from /etc and updates config admin with the information, much like
>>> fileinstall does. I can run this and it appears to work, however I
>>> still have the existing mechanism in that I'd like to remove.
>>>
>>> So I naively did the following:
>>>    set the start-level of my bundle to be 11, same as fileinstall
>>> set felix.fileinstall.enableConfigSave to false in
>>> etc/custom.properties
>>>    set felix.fileinstall.dir to empty
>>>
>>> Karaf fails to start.
>>>
>>> So my suspicion is that apache fileinstall is more centrally required
>>> than I'd hoped. Looking at the karaf code there are certainly a few
>>> places where it assumes a configuration contains a
>>> felix.fileinstall.filename property that names the file where the
>>> configuration is stored, and seems to directly read and write those
>>> files. This appears to mean that I wouldn't be able to substitute my
>>> own configuration storage backend, which is a shame (I'm actually
>>> confused what org.apache.karaf.config.core.ConfigRepository is actually
>>> doing here -- why does is write directly to the file, rather than just
>>> letting fileinstall do it, especially as it only seems to allow for
>>> ".cfg" and not ".config" files). There may be other reasons why karaf
>>> won't start though.
>>>
>>> Is it likely that I would substitute felix.fileinstall in this way?
>>>
>>>
>>> What I was actually trying to solve was what to do when a user
>>> uninstalls and reinstalls our karaf-based product, and attempting to
>>> preserve any configuration changes. What I had hoped to do was store
>>> any actually modified configuration properties in separate files (just
>>> the actual properties that were different from default or from the
>>> originals in the etc/*.cfg files), so that the original etc/*.cfg files
>>> would be replaced without difficulty, and the changed configuration
>>> changes would then be applied.
>>>
>>> So alternative question: How else can I achieve the same thing without
>>> making the users manually merge the configuration changes?
>>>
>>> Thanks.

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Providing alternative config mechanism than felix.fileinstall/Preserving config changes on re-install

Guillaume Nodet-2
You could also look at the read-only implementation of ConfigAdmin we have in Karaf.
That can easily be used to remove fileinstall completely, as done in the static configurations.

2017-10-06 13:39 GMT+02:00 Jean-Baptiste Onofré <[hidden email]>:
Hi Tom,

You can implement your own PersistenceManager (ConfigAdmin service).

Regards
JB


On 10/06/2017 01:07 PM, [hidden email] wrote:
I can see KARAF-418, but that's pretty old, and sounds like it was considered unnecessary? Is there anything else I can't find?

I don't necessarily want to store things in a database, I just want different behaviour to normal, to provide my own implementation of something that listens to config changes and injects configuration on startup. And I can write that bit, what I can't do is substitute it in at a central enough level to replace fileinstall.

I've made a little progress. I manually edited the "startup.properties" file and put my bundle in there at level 11. It got activated. So what I don't currently understand is a) where that file comes from (it's clearly generated as part of building my karaf distribution, it's not in source control) and b) what specifying the start-level in the feature.xml file does (since it doesn't appear to specify the start level :-)).
My problem now appears to be that I'd written my code using declarative services, and I think I need to go back to old fashioned bundle activators and service trackers in order to reduce the dependencies and make the code work in the "simple" environment I encounter down at that start level.

There was also a comprehension question of why the ConfigRepository was attempting to write the config files directly, rather than just calling Configuration.update. Surely one thing or the other (calling update I assume is preferable), but not both?

Thanks.

On 06 October 2017 at 11:40 Jean-Baptiste Onofré <[hidden email]> wrote:


Hi

I guess you want to use an alternative backend to the filesystem (a database for instance).

In that case we have a Jira about that and you can provide your own persistence backend.

Regards
JB

On Oct 6, 2017, 12:30, at 12:30, [hidden email] wrote:
I'm trying to establish some alternative configuration behaviour than
what felix-fileinstall gives me.
I have written a very simple component that reads configuration files
in from /etc and updates config admin with the information, much like
fileinstall does. I can run this and it appears to work, however I
still have the existing mechanism in that I'd like to remove.

So I naively did the following:
   set the start-level of my bundle to be 11, same as fileinstall
set felix.fileinstall.enableConfigSave to false in
etc/custom.properties
   set felix.fileinstall.dir to empty

Karaf fails to start.

So my suspicion is that apache fileinstall is more centrally required
than I'd hoped. Looking at the karaf code there are certainly a few
places where it assumes a configuration contains a
felix.fileinstall.filename property that names the file where the
configuration is stored, and seems to directly read and write those
files. This appears to mean that I wouldn't be able to substitute my
own configuration storage backend, which is a shame (I'm actually
confused what org.apache.karaf.config.core.ConfigRepository is actually
doing here -- why does is write directly to the file, rather than just
letting fileinstall do it, especially as it only seems to allow for
".cfg" and not ".config" files). There may be other reasons why karaf
won't start though.

Is it likely that I would substitute felix.fileinstall in this way?


What I was actually trying to solve was what to do when a user
uninstalls and reinstalls our karaf-based product, and attempting to
preserve any configuration changes. What I had hoped to do was store
any actually modified configuration properties in separate files (just
the actual properties that were different from default or from the
originals in the etc/*.cfg files), so that the original etc/*.cfg files
would be replaced without difficulty, and the changed configuration
changes would then be applied.

So alternative question: How else can I achieve the same thing without
making the users manually merge the configuration changes?

Thanks.

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com



--
------------------------
Guillaume Nodet

Reply | Threaded
Open this post in threaded view
|

Re: Providing alternative config mechanism than felix.fileinstall/Preserving config changes on re-install

tomq42
In reply to this post by jbonofre

> You can implement your own PersistenceManager (ConfigAdmin service).

OK, I'm actually super confused now (not hard).
felix configadmin appears to have logic in it that persists configurations to and from files. It's unclear in the karaf environment where the FilePersistenceManager is attempting to read, and more importantly write, changes to/from. I can't see any evidence of it writing files anywhere, but the logic would appear to be to fall back to writing to the current directory if there isn't any explicit configuration (which there doesn't appear to be that I can find).

Given the presence of felix configadmin and FilePersistenceManager, I can only assume that the reason that filinstall is *actually* the thing that is used in karaf for persistence of configuration is the polling behaviour, allowing you to change the files and have it pick the changes up without having to restart.

Say I implemented my own felix configadmin PersistenceManager. I'd still need to get that activated very early, which is something I've not yet understood how to do.
Any suggestions for how to get a bundle that's activated super early, same as configadmin/fileinstall?