felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Configuration Generations/Auditing
Date Wed, 10 Nov 2010 07:39:05 GMT
On Tue, Nov 9, 2010 at 14:58, Felix Meschberger <fmeschbe@gmail.com> wrote:
> Hi all,
> At ApacheCon -- IIRC it was during the OSGi Meetup -- a question was
> raised whether configuration modifications are in any way audited and
> whether a fall back to a previous version is at all possible.
> Of course, the Configuration Admin specification does not foresee such
> functionality. I could even argue that this happens by intent leaving
> such administrative functionality up to the actual implementations.
> Carsten Ziegeler and me further discussed options off-line and came to
> the following options:
> (1) The Configuration Admin implementation could maintain these
> configuration generations internally and also record the date/time of
> changes. This would probably require to add an API to access these
> generations and optionally to revert the current configuration to a
> previous state.

Shouldn't that be tied to the backend storage instead ?
If you use a CMS or something like svn/git underneath, all those
features would be provided de-facto and you could just go to the
backend to revert to the previous state.   I'm not sure about having
to rewrite a layer that would work on top of any storage.

> (2) But, actually, the problem does not end with configurations: What
> about bundles ? But if we start to record Bundle (and Framework) state
> changes, the most obvious solution would be to have a separate audit
> bundle recording configuration and bundle state changes. This bundle
> could in fact also record the configuration generations but obviously
> not the actual bundle generations because this data is not readily and
> easily available.

Couldn't that be related somehow to having a transactional framework?
Once again, leveraging existing technologies for snapshots / rollback
could make sense.   I think recording framework changes would be a
really good idea, however, if we don't record bundle themselves, I'm
not sure we'd really gain anything, and I'm also not sure it could be
done without cooperation from the framework somehow.  But that may be
slightly out of topic I guess.

> WDYT ?
> Would such a functionality be worth implementing (as part of Apache
> Felix) ?
> Would you think option #1 (Configuration Admin extension, ignoring
> bundles) or #2 (Separate bundle supporting both Configuration and Bundle
> states; but only configuration generations) superior ?
> Thanks and Regards
> Felix

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA

View raw message