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