Provisioning - gathering requirements

Lukas Krejci lkrejci at redhat.com
Mon Mar 4 16:42:32 UTC 2013


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





More information about the rhq-devel mailing list