felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Configuration Generations/Auditing
Date Wed, 10 Nov 2010 08:20:57 GMT

Am Mittwoch, den 10.11.2010, 08:39 +0100 schrieb Guillaume Nodet: 
> 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.

Of course the backend can help with that (and that would make sense to a
certain extent).


The Configuration Admin is in charge of setting configuration and not
any backend. So if we want to rollback, the Configuration Admin would
ask the backend to get the requested configuration, persist that as the
current, and distribute the configuration.

As such, the implementation would probably extend our PersistenceManager
API to allow for configuration generations -- create, list, get
generation -- and the Configuration Admin implementation to expose this
through some extension API.

The PersistenceManager implementation is of course free to roll its own
implementation (as we would do for the FilePersistenceManager) or reuse
existing mechanisms as could do a JCR-based or SVN/GIT-based

> >
> > (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.

I am not even thinking of transactions. I was just thinking of recording
changes to prevent the casual John Doe telling me "No, nothing was

But of course, like for configurations, being able to record the actual
bundles updated would be great, but ... we are missing the functionality
outside of the framework.


> > 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
> >
> >

View raw message