On 4/7/11 6:29 AM, Heiko W.Rupp wrote:
Hi,
[ why is this not on rhq-devel ? ]
Can we please make sure that Drift management does not require files to be present, but can also work on other input sources?
In AS7, we may want to watch a managed server who gets configuration bits from the domain, where the bits are actually defined on a different machine - but where an effective configuration may be retrieved for a this managed server .
I am not exactly sure if this applies, but it at least illustrates my point :)
Heiko
For reference - http://www.rhq-project.org/display/RHQ/Drift+Management
I will move future communications to the devel list. What you are talking about sounds like it gets into the discussions around a resource-based versus a file-based approach. There are some definitely some nice upsides to a resource-based approach; however, there are also some big downsides. Here's a brief brain dump of pros/cons.
pros: * A resource-based approach would effectively enable us to generate snapshots of anything we manage, not just things off of the file system. This would include configuration data stored in a database or in a JMX bean as a couple examples.
* We already expose plugin APIs for accessing resource configuration and content. With some enhancements, notably raw config, I believe we could reuse the existing APIs to generate resource-based snapshots. One of the cons that I will discuss below is that we lack 100% of the AS in terms of management. I think that with raw config (with a slight twist) we could get that coverage. The raw config domain model has been in place for a while. A "basic" raw config which does not need to do any translating back and forth between structured and raw is mostly boilerplate code. It is just reading and files to and from RawConfiguration objects. We could offer a PC-managed raw config which would not require plugins to implement the raw config facet. It could be done by convention using plugin configuration properties. Something along these lines to illustrate the idea,
<plugin-configuration> <c:group name="advancedConfiguration"> <c:simple-property name="enableAdvancedConfiguration" default="false"/> <c:list-property name="fileSetList"> <c:map-property name="fileSetMap"> <c:simple-property name="path"/> <c:simple-property name="filter" description="Maybe an Ant-like filter/pattern syntax when path is a directory"/> <c:simple-property name="recursive"/> <c:simple-property name="include" default="true"/> <c:/map-property> <c:/list-property> <c:/group> </plugin-configuration>
With something along these lines, a user could essentially expand the configuration coverage of an AS instance with path="SERVER_HOME/config" and filter="**/*" which would result in PC-managed configuration for all files under the config directory. I think we might be able to expand content coverage using a similar approach.
* With resource-managed snapshots we can correlate changes to a specific resource. When change happens, we will know precisely which resource introduced the change. We will not always be able to do this with a file-based approach.
* Reuse of existing subsystems, UIs. With either approach, we are going to need some UI changes, like a diff editor. But for a resource-based approach, if I want to view a change that happened in a structured configuration, we already have UIs for viewing configs.
cons: * Storing snapshots on the server is likely more complex than a file-based approach. With the file based approach, we basically store the snapshot as a blob. But with a resource-based approach, we have configuration and content data spread across various tables. I think that this would potentially result in more complex relationships for storing snapshots.
* A resource-based approach may not be as intuitive for users. With the file-based approach, I think it is fairly intuitive to say I want a snapshot that includes *-ds.xml, *.war, and *.ear. With a resource-based approach, this would have to be expressed in terms of resource types. Maybe we could leverage the search functionality that Joseph added, but I still do not think it would be as intuitive as the file-based approach.
* Storing meta data may be more complex. The snapshot meta data is conceptually a table keyed off of the path. We can use that path to quickly look up the changed contents or the hash of the changed file. Since we need to ensure unique keys, I thought for a resource-based approach we might be able to use a combination of the resource type id, parent resource key, and the resource key. The problem with this though is that is requires existing resources. File-based snapshots do not have to be directly linked to resources which means we can more easily support use cases in which we start with some pre-existing snapshot that was not generated by the resources we want to monitor.
* Tracking change for the resource-based approach may involve more work. With both approaches we need to track the following:
* configuration data is modified * content is modified * configuration added or removed * content added or removed
For the resource-based approach I think we would additional want to track the addition/removal of child resources of those resource that have drift monitoring enabled.