That's an interesting project proposal - and I can see something like this level of "monitoring" being useful in a manager as well, even though the proposal was heavily academic/research oriented. I'm in the weeds, though, and much more interested in the functional aspect that will allow me to eventually do as little work as possible =) I can actually see the "snapshots" gathered by a CM agent being sanitized and used to solve this academic problem as well. Perhaps taking this angle could incite additional developers to contribute =)
S On Wed, Nov 10, 2010 at 10:14 AM, Richard S. Hall <[email protected]>wrote: > 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 >>> >>> >>>
