Is this starting to go in the direction Alan Cabrera was proposing:
https://cwiki.apache.org/confluence/display/FELIX/CAT-Scan+Project+Proposal
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<[email protected]>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
