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
Show replies by date