felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Configuration Generations/Auditing
Date Wed, 10 Nov 2010 15:14:58 GMT
Is this starting to go in the direction Alan Cabrera was proposing:


Light on details, but it is about capturing framework state.

-> richard

On 11/10/10 9:49, Steven Siebert wrote:
> Felix,
> I was quite interested in this topic as well.  A similar question was raised
> during the Apache ACE session, so it seems to be a popular request.
> First, I agree this is something that many implementations would want/need -
> I too have a need for this.  In fact, I would argue more towards the #2
> aspect, because quite often the specific bundles I chose to use is indeed
> part of the system "configuration" (and each of these bundles have their own
> actual configuration, as defined by the Config Admin service).  A simple
> example of this may be an implementation of a LogReader Service, where I
> provide an additional bundle that provides a LogListener to do store/forward
> of log events.  This is part of my systems "configuration", and needs to be
> captured so I can manage my system(s).
> Given that the Configuration Admin Services concern is to provide a means to
> deliver configuration to a bundle/make it available when the bundle is
> activated, it seems like a logical extension of the Config Admin
> responsibility...however, I am hesitant to immediatly agree with this.  I
> wonder if this should be an organic functionality of the Configuration Admin
> service or that of a the implementation, a separate well defined service,
> and/or that of a deployment manager (such as the web console or Apache
> ACE).  Leaving this management functionality as part of the implementation
> or (as I would prefer) part of a management application, allows my OSGi
> implementations that do not need this local CM functionality to stay lean
> and allow my management systems to handle the management remotely.  I can
> also see this "configuration management" functionality be part of a new spec
> (Configuration Management), which could compliment the Configuration Admin
> service, allowing to view/change/rollback to previous runtime configuration
> "snapshots" (optionally including config and bundle deployments).
> All that said, I can see problems with the approach of leaving this to just
> the deployment manager.  For example, just because I use a manager of some
> sort doesn't mean that someone else can't use the console.  And, if I'm
> relying on these changes to be captured inline by the management console,
> I'll miss these changes.  Therefore, you need a service on the OSGi runtime
> to monitor these changes.  This problem was solved by the Apache ACE project
> by the means of providing "feedback" to the provisioning server (if one is
> configured) with audit messages.  I believe the ACE gateway (target)
> agent/manager caches the previous bundles and configuration as well, mostly
> for performance concerns, I believe.  Perhaps this work can be looked at and
> expanded?
> Thanks for all the great work!
> Respectfully,
> Steve
> On Tue, Nov 9, 2010 at 8:58 AM, 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.
>> (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.
>> 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