Hi, Am Mittwoch, den 10.11.2010, 08:39 +0100 schrieb Guillaume Nodet: > On Tue, Nov 9, 2010 at 14:58, 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. > > 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 > > > > > > >
