Configuration changes during resource upgrade

Lukas Krejci lkrejci at redhat.com
Mon Aug 16 16:20:46 UTC 2010


Hi,

this is another topic that I think might be useful for the resource upgrade 
effort.

As it stands now (in the resource-upgrade branch), the resource upgrade 
functionality can be used to change the resource key, name (and description) 
of existing resources to conform with the new version of the plugin. 

The code in the branch currently leaves the responsibility of determining what 
version of the plugin to upgrade from and to up to the plugin developer and my 
previous email tried to detail some of the complexities we might hit 
implementing the support for such information.

Another area that I think would be useful for the plugin developers is the 
support for configuration upgrades.

Currently we mandate the plugin and resource configurations to remain 
backwards compatible. When a new version of a resource type is being 
persisted, the structural changes to the configuration definitions are 
reflected in the database. The values of new properties are initialized using 
the values hardcoded in the plugin descriptor.
This is obviously not optimal because the plugin developer has no ability to 
influence the values for individual resources (no way of initializing property 
lists with runtime detected values, no "smart" initialization of property 
values by actually looking at the managed resources, etc.), just the hardcoded 
defaults from the plugin descriptor.
Another problem that needs to be considered is the display of the 
configuration updates history. Currently we only ever store 1 "copy" of the 
configuration definitions and use it to "parse" the individual configuration 
updates. That is OK, because as mentioned earlier the configuration 
definitions are assumed to be backwards compatible. If we allow the plugin to 
perform more complicated structural changes, this might not be the case 
anymore.

So here's a first draft of the approach we could take to lift the backwards-
compatibility restriction and to enable the plugins to take part in the 
configuration upgrades.

1) When importing a plugin, we don't just merge in the changes to the 
configuration definitions, but we actually create whole new versions of them 
and make them the "current" ones by referencing the new config. def. versions 
from the resource type.

2) Make configuration upgrades reference not only the configuration objects 
but also the corresponding configuration definitions. With 1) this will make 
the historical entries use the correct config. definitions at a cost of one 
additional foreign key in RHQ_CONFIG_UPDATE table.

3) Allow plugins to upgrade the resource and plugin configurations during the 
normal upgrade workflow (by simply adding them as properties of the 
ResourceUpgradeRequest).

4) On merging the upgrade requests on the server side, create new entries in 
the config update tables for each plugin-driven upgrade.


The problem that I can see with this is the following scenario:

1) Both server and agent are running

2) RHQ admin updates a plugin on the server => the new config defs are 
persisted and referenced from the resource types

3) User edits a configuration of some resource (using the new config defs)

4) the update is sent to the agent

5) agent is still using the old plugins

This problem could be solved by somehow postponing the the "switch" to the new 
config defs of the resource types on the server side to the post-upgrade time, 
but that's quite hard, because different agents will upgrade at different 
times and so we had to keep 2 versions of a resource type (or at least 2 
versions of the config defs) "active" in the inventory until all the agents 
upgraded to the latest version of the plugins.

Now the questions :)

- Do you consider configuration upgrades important / useful (I do because of 
the above mentioned reasons)?

- What do you say about the approach and the problems outlined above?

Thanks,

Lukas




More information about the rhq-devel mailing list