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 fmeschbe@gmail.com designates
 74.125.82.53 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:in-reply-to:references:content-type:date:message-id
         :mime-version:x-mailer:content-transfer-encoding;
        b=Au/IoX5G/I3e5mZZ3mC6gXRAWsG5hvaXKKYy7nqKe49Bb7d9BVnWFZkZrNzk0g02D1
         pDjZ83BWLlagKUg6m0j4LDz3qVz9J/beoPZy6AW0DYhhulboKJ63PB4hv6R8/HEdqwSt
         4FDPnxzWe4t7pO02GM0pkqya/SV3yZC1k+u2Q=
Subject: Re: Configuration Generations/Auditing
From: Felix Meschberger <fmeschbe@gmail.com>
To: dev@felix.apache.org
In-Reply-To: <AANLkTikK5-ByXveUMQxE-8JT4d-W=mWo6RTVKteWMsYm@mail.gmail.com>
References: <1289311084.2634.858.camel@meschbix.corp.day.com>
	 <AANLkTikK5-ByXveUMQxE-8JT4d-W=mWo6RTVKteWMsYm@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 10 Nov 2010 09:20:57 +0100
Message-ID: <1289377257.2634.930.camel@meschbix.corp.day.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi,

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

But...

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

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

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.

Regards
Felix

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