Hi Angelo, Marcel, See below for my remarks. I think in general I agree with this patch, I only have some concerns left regarding configuration used by non-Amdatu bundles, see below (first comment). Configuration management keeps being a complicated issue. We moved to fileinstall for configuration management in the past, now we move to this approach but still with the side note that this is not the final approach. So I think we need to think about the 'final' approach.
Regards, Ivo From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Marcel Offermans Sent: donderdag 7 oktober 2010 0:45 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Moving bundle configuration out of their source Hello Ivo, Angelo, Since Ivo asked my opinion, I'm taking Angelo's reply as the base and I added some comments in-line below. On 6 Oct 2010, at 16:44 , Angelo van der Sijpt wrote: On Oct 6, 2010, at 4:10 PM, Ivo Ladage-van Doorn wrote: I analyzed the patch. If I'm correct the changes are: - Configuration files are moved from each individual bundle to one central config bundle - Use of fileinstall to automatically create configuration entries in ConfigAdmin and set defaults is replaced by a service that does so upon starting the service That is exactly what I intended. This bundle should make sure to only add or update a configuration if it really changed (compared to the data already in the Configuration Admin service. I have the following remarks: - By moving all individual configuration files to one central configuration bundle, the idea of each bundle must manage its own configuration is a bit lost; the bundle itself and its configuration are disconnected (see this discussion: http://amdatu.org/confluence/display/Amdatu/Configuration+management). One of the primary features of Configuration Admin is that it decouples managing the configuration of a service from the implementation of that service. So the concept that each bundle has its own configuration (opposed to bundles sharing a configuration) still exists, it's just not "managed" by the bundle that implements the service anymore. This, in my opinion, is not a bad thing. [Ivo Ladage-van Doorn] Ok, but the definition of configuration entries used by bundle A and the implementation of bundle A reading those configuration entries do belong to each other. So if I append a new configuration property P to bundle A including some method that reads from it, I will need to update bundle A as well as the configuration file physically located in the central configuration bundle. For bundles contained by the Amdatu platform this is not a real problem, but what if custom bundles are developed on the Amdatu platform? How do they add their configuration files? They cannot/should not update the central configuration bundle to make that happen. It would be a pitty if non-Amdatu bundles should implement their own mechanism for creating configurations in config admin and not being able to use the same mechanism used by all Amdatu bundles. Another issue is that all bundles that use configuration (which will be a lot) will now depend on this one bundle. Effectively, when the config bundle needs to be updated because of a config change in bundle A, all other bundles that use configuration will go through stop/start as well. So from that perspective, I doubt that this is the proper approach. I do not think this observation is true. First of all, when the bundle holding configurations for all other bundles is updated, it should probably (on being stopped) not remove any configuration it added in its "start" method (or rather, in the start method of the component that has a dependency on Configuration Admin). With that assumption, plus the comment made above that the bundle should not update a configuration unless it actually has a different one, means that you can update the configuration bundle at will, it will not affect already running bundles. Configuration changes will never stop bundles. They will also not stop services that have a dependency on a configuration. They will keep running and just be invoked on their ManagedService.updated(Dictionary) method. All in all, updating the configuration bundle will not cause any services or bundles to restart. [Ivo Ladage-van Doorn] Agreed, this observation was indeed incorrect. Although there is a dependency in terms of a configuration file holding configuration properties and Java methods reading those configuration properties, there is no direct service dependency between a bundle and the configuration bundle. I agree that this is not _the_ proper approach, and it is not production ready; the best approach would be one based on some external configuration mechanism. However, I do believe that for the time being, we should move away from the 'let's put file in the right location on the disc'-approach. The configuration bundle is just something we need as long as we do not have a mechanism to externally configure a framework. In the end, when moving to the cloud, configurations will probably be centrally managed and updated, sent to a framework as part of a deployment package. In that scenario, it's unlikely that any human will ever touch files on disk (in a cloud node). For cases where system administrators still have access to nodes, we should still consider some interface for them to edit the configuration that then gets translated into configurations for the services (as the link that Ivo mentioned above explains). - In the fileinstall approach, configs could be managed by editing the files on disk. This is an advantage for system administrators who cannot change and deploy bundles. In the new approach when a config needs to be changed the bundle needs to be updated by a developer since configuration is updated each time the central config service starts. The latter could be fixed however, configuration properties could be added/set only if they don't exist yet. Services should be able to cope with this (this is another point: I noticed that many services have a very basic approach to 'getting' configurations, we should use ManagedService for this). Not only "should", we "must" use ManagedService, because that is how the specification was intended. By the way, if you need to update configuration while developing, and you don't feel like deploying, you could use a shell command for this. I think this is where the Apache Felix Web Console can be used (or indeed the shell). However, in the end we need to work towards a situation where we can very rapidly deploy updates from within our development environment. To be honest, in my opinion, File install should never be used in production environments. It's a tool for developers, and that's the only place where we should use it. Managing configurations via files has a lot of issues that are hard to solve (partially written files that get picked up ending in "incomplete" configurations being pushed out, expensive polling mechanisms, little control over the exact moment at which updated configurations are "set", ...). [Ivo Ladage-van Doorn] Does the same apply to bundle updates? Fileinstall is currently not only used for updating configurations but also for updating bundles. In the cloud approach bundle updates need to be centrally managed/provisioned, so I guess your answer will be 'yes'. A positive thing now is that you can use ConfigAdmin to update configuration entries while in case of fileinstall this had to be done by editing the files on disk. However, the patch proposed looks very similar to the situation prior to introducing fileinstall. In my opinion the fileinstall approach is better, though it still needs some improvements: - Currently you can only update configuration by changing files on disk. It should be possible to use the ConfigAdmin java api for that too , so fileinstall should listen to changes in ConfigAdmin and write them back to the config files on disk. Hm, do you mean that we should keep a copy of the configuration that is in Config Admin, on the disk? I think that defeats the purpose of having config admin in the first place. [Ivo Ladage-van Doorn] Assuming that fileinstall is used, yes. But if we skip fileinstall I absolutely agree that having a copy of configuration files on disk is not the way to go. I agree with Angelo on this one, we should not try to sync configurations from Configuration Admin back to disk. That could easily create silly loops where Configuration Admin changes, triggering an update of the file, which again triggers an update of the configuration. Configurations should be in Configuration Admin, and that service has mechanisms for manipulating configurations. - I agree that copying the config files in the install phase of maven is not the proper way; when the config is changed updating the bundle would not change it on a runtime environment. Instead it should copy its config file to the fileinstall deploy directory when going thought the update phase of the OSGi lifecyle (however, without overwriting any changes). Marcel, what is your opinion about this issue? My 2 cents... :) Greetings, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101007/9760358e/attachment-0001.html
