Hi,
We've been thinking recently about how to simplify the situation for the users when dealing with how RHQ manages content. Currently, users can use either the bundle subsystem to deploy/undeploy stuff or there is some support for doing it using our content subsystem.
We've realized that the content subsystem is very rigid and provides some (overly) strong guarantees when it comes to checking the type of the data deployable to certain locations. It is also able to link the resources in RHQ's inventory with the content deployed "underneath" them. Using it is very cumbersome and errorprone and users (as well as devs) generally had difficulties getting anything useful out of it (mainly due to very over- engineered server-side concepts like content source).
On the other hand, the bundle subsystem is designed to be free-form, scripted deployment tool that provides the users with ant-based "recipes" for deploying content giving them full power (and responsibility) over what and how is deployed from a bundle. This has become quite popular amongst our userbase (as far as we are aware of) exactly because of that power. The drawbacks of the bundle subsystem are its inability to directly link the resources in the inventory with the content that has been deployed through bundles and also its coupling to the filesystem - it is not possible to deploy using some kind of API from a bundle. Also, one cannot easily "just drop stuff somewhere" for it to be deployed without writing some kind of recipe for it first.
We've been thinking about various ways of unifying these two approaches (each of which has its pros and cons) but couldn't find a way that would be easy enough, provided enough value and was backwards compatible (if you are really interested, you can read through our wiki page that tracks the discussions we've had: https://docs.jboss.org/author/display/RHQ/Bundles+vs. +Content+-+On+Its+Head).
So far we identified what RHQ does *NOT* want to be: * a fullblown provisioning system akin to Linux package management solutions
We'd rather be a complement or a much simpler alternative way of deliverying content that would concentrate on deploying applications into "containers" - our main usecase obviously being webapps to appservers.
We'd like our new "provisioning" system to (in decreasing priority):
* create ties between deployed content and RHQ's inventory as much as possible (this might be difficult in the scripted scenarios), * provide scriptability similarly (if not in the same way) as bundle subsystem does today, * provide "drop stuff" type of functionality so that users don't have to write recipes for "well-known" types of content, * provide ability to "discover" content present on the already known resources.
What do you consider important? Do we miss usecases you'd like us to implement? Would you change the priorities of the above?
Thanks,
Lukas