Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of smsiebe@gmail.com designates
 209.85.214.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=GCDPq2ndErvqxxXnb9s2ZiAb7qwfHnIw5j/W1HFpZCYDpBJOaZMiuA5sUWcDA6hIzp
         a1qPUNR+LHt7zXH+O2fmEXdbpGd3LfjXiu+0dx6yGAPPXaXgFHhsHgMBJ716Zcgeml+X
         ICxnJ/cu9MHUnf+rgUEJM7ZaWLNSgY6y58N+g=
MIME-Version: 1.0
In-Reply-To: <1289311084.2634.858.camel@meschbix.corp.day.com>
References: <1289311084.2634.858.camel@meschbix.corp.day.com>
From: Steven Siebert <smsiebe@gmail.com>
Date: Wed, 10 Nov 2010 09:49:44 -0500
Message-ID: <AANLkTik1VPVY_Z8wLBZeFZxCUukk_oiB5QCc=KwAk=6g@mail.gmail.com>
Subject: Re: Configuration Generations/Auditing
To: dev@felix.apache.org, ace-dev <ace-dev@incubator.apache.org>
Content-Type: multipart/alternative; boundary=005045015a2704da080494b3f9a0

--005045015a2704da080494b3f9a0
Content-Type: text/plain; charset=ISO-8859-1

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

--005045015a2704da080494b3f9a0--