Resource upgrade once more

Lukas Krejci lkrejci at redhat.com
Tue Sep 14 16:04:24 UTC 2010


Hi team,

there is an unfortunate one last issue with the resource upgrade functionality 
that I'd like to get a common agreement on.

But first let me recap the state of resource upgrade functionality as we 
decided to implement it.

1) It will only be possible to upgrade resource key, name and description, 
with the latter two being disabled on the server side (it'd be easy to add a 
GUI switch to switch it on if we see the demand in the community).

2) An upgrade error isn't considered fatal, it is assumed that plugin is 
either programmed to handle multiple versions of resource data or that the 
failure to upgrade isn't detrimental to the plugin functionality (too much).

3) An upgrade error is going to be merely reported using the resource errors 
facility on the server side similarly to how 
InvalidPluginConfigurationExceptions are/were reported (some kind of warning 
icon and explanatory text).

So now let me explain the issue. The original intention of the whole resource 
upgrade effort was to be able to transform an "old" resource with a "new" 
resource (transform only means to change its resource key for now).

Now that we have that functionality, let's examine what happens if the upgrade 
fails for some reason (a logic error in the plugin code being hopefully the 
only possibility here).

1) There is the old resource in the inventory and a new plugin has been 
deployed to the server.

2) Agent downloads the new plugin and reinitializes the plugin container.

3) The resource upgrade kicks in, upgrade of the old resource fails, an error 
is reported on that resource on the server side.

4) A discovery using the new plugin code is executed on the agent.

5) A new resource is discovered that should have really been the transformed 
old resource if the upgrade succeeded.

6) We end up with two logically equal resources in the inventory.

The only way how to prevent this from happening that I can see is to disallow 
the discovery for that certain resource type under the old resource's parent 
for the lifetime of plugin container (that is until the next upgrade attempt 
is made with the next start of plugin container).

But is that acceptable? This way we would basically "conserve" parts of the 
inventory in the old state until a new version of the plugin with the fixed 
upgrade code would be deployed, which can mean a substantial amount of time 
with possibly non-functional resources.

Another way how to fix this would of course be the plugin versioning and 
multiple versions of the same plugin being deployed on the agent serving 
different resources, but that's a very complicated issue that we agreed to 
avoid at all cost.

What are your thoughts?

Thanks,

Lukas


More information about the rhq-devel mailing list