ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Configuration Generations/Auditing
Date Thu, 11 Nov 2010 08:59:57 GMT
On 10 Nov 2010, at 15:49 , Steven Siebert wrote:

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

Indeed.

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

We can probably all agree that in general an OSGi based application is defined by both its
bundles and its configuration. You can argue about if you also want to capture each bundle's
local data store (and specifications like Deployment Admin even explicitly mention this) and
of course there can be many other things you need to capture depending on the actual bundles
you use. However, I do think it's a good "quality" of an OSGi based application if it can
be defined only by "deployable artifacts" without needing anything else.

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

I agree with you here Steven, I would be very hesitant to make storing and reverting to "versions"
of configurations a responsibility of the Configuration Admin bundle. In fact, I don't like
that idea at all, so I would not like to see option (1) being implemented as part of Configuration
Admin.

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

Conceptually, I think there should always be one component in charge of managing the life
cycle of the OSGi container and usually this component is called the management agent (in
the OSGi spec). The management agent is responsible for executing changes, so it would also
be the natural place to record them (in whatever way) so you can go back to previous states.

In practice this means that if you combine both an ACE management agent and a console, they
together are the new "management agent" and they need to work together to record changes and
provide rollback. As a side note, one could also create console commands that talk to the
ACE server to make changes to ones own target. That way, even though you make your changes
on the local console, they are recorded on the server and can always be "played back".

ACE uses deployment packages to deploy versions (or generations) of an OSGi framework and
based on the meta data stored on the server it can always go back in time to each and every
version that existed. It uses Deployment Admin for that. The ACE management agent can indeed
cache versions of deployment packages locally to speed that process up, but that's merely
a performance improvement.

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

For reasons stated above I would not choose this option.

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

I would say this responsibility should be delegated to the management agent that controls
the life cycle of your framework. It probably knows best when to record the state and what
to record. I fully agree the problem does not end with configurations only so it should not
be solved at that level.

Greetings, Marcel


Mime
View raw message