create child resource and configuration

John Mazzitelli jmazzite at redhat.com
Mon Mar 5 17:53:53 UTC 2012


On Mon, 2012-03-05 at 17:43 +0100, Heiko W.Rupp wrote:
> When I create a child resource, the <resource-configuration> is taken as configuration for that child 
> (not the <plugin-config> !  as in the case of manual-add ) - is there a way to signal that I either want to use 
> the <plugin-config> instead OR that the <resource-config> is only for create-child, but not to be used otherwise?

OK, here is the thinking about that.

First, for those that are uninitiated :) ...

What Heiko is referring to is the ability to manually create a new child
resource. Plugin developers can indicate a resource can be manually
created by using the metadata attribute creationDataType="configuration"
on the <server> or <service> element (the other value that attribute can
be is "content" - but in this case, ignore that - for this discussion we
are talking about creating the resource through the setting of resource
configuration property values as opposed to giving the system a piece of
content (like a jar file)).

Now... you are creating an actual new resource (NOT a plugin resource
component). For example, our Postgres plugin has this metadata on the
Table resource - thus, you are allowed to create literally new tables in
your database through this mechanism. Since you are creating an *actual*
new managed resource, you have to tell it how it is supposed to be
configured (what's the name of the table? what are its columns? which
columns are nullable? etc. etc). Otherwise, how does the plugin know
what to create if not through the resource configuration? You can't use
the plugin configuration because, in general, that does not indicate
anything about the config OF THE ACTUAL RESOURCE ITSELF - it only tells
the plugin HOW to connect to an already existing resource (e.g. the
plugin configuration of the Postgres Table doesn't have anything about
what columns are on the table, their nullability, etc).

Since you are using the plugin to create the managed resource, the
plugin should be able to discover that new resource with the appropriate
plugin configuration (so the theory goes). In the case of the Postgres
plugin, for example, it discovers tables in the database by querying the
Postgres Server resource for all of its table names - when the plugin
discovers a new table, it can easily build the plugin configuration
because it knows (or should know) how to connect to it (after all, it
just connected to that new managed resource's parent so it should be
able to fill in the plugin config of the new child).

So, today, if creationDataType="configuration", you have no option - you
have to give it the resource config.

I can only assume you found a use-case where this separation of plugin
configuration and resource configuration doesn't make sense. Perhaps you
can provide a concrete use-case example you are working on. I can't
picture a use case where giving the plugin configuration allows a plugin
to create an actual managed resource (due to this fact that, in general,
plugin config doesn't say much of anything about the actual
configuraiton of the actual resource).

What you are asking for sounds more like is Manual-Add - where you know
the existing resource already exists and you just want to create a new
resource component (that is, an RHQ resource in inventory). This you can
do today and this you do provide a plugin configuration - here you say,
"I know there is already a resource that exists, I just need RHQ to
connect to it and inventory it". In this case, the plugin config IS the
config you give because that's how you tell the RHQ plugin how to
connect to the managed resource. In that case, you don't care how the
resource is fully configured, you just care about what settings are
needed for the plugin to connect to it.

Perhaps what you really are asking for is the ability to enter BOTH - a
plugin config and resource config (i.e. a manual-create followed by a
manual-add - which I can see would be needed if you know a resource you
are going to manually create won't be able to be auto-discovered by the
RHQ plugin - hence you will have to tell the system, "I am creating a
new resource with a new resource configuration, and the plugin will be
able to connect to it with this special set of plugin config values").
i.e. a manual-create-then-add feature.

> that the <resource-config> is only for create-child, but not
> to be used otherwise?

We have nothing like that. Although, I think you could use configuration
templates to at least assist the user with some defaults? But there is
nothing to say, "this rsource config is for create-child only". Each
resource has a single set of resource configuration (or none, if it
doesn't support resource config).  There is nothing in our metadata
schema today that allows you to say, "here's some resource config that
is needed to create the resource, but that same resource config is not
used to manage the actual resource during runtime - the actual real
resource config is a different set of properties" - that's not how the
resource-configuration is designed to work today.





More information about the rhq-devel mailing list