Hi team,
This is to reignite the discussions we had before RHQ 3.0.0 release about the
proposed resource upgrade functionality. To refresh your memory, please read
through
http://www.rhq-project.org/display/RHQ/Design+-+Resource+Upgrade that
I updated to reflect the latest state of affairs.
If you remember the discussions we had before the 3.0.0 release, we agreed
that it would be good to provide version information to the upgrade methods
for individual resource types, so that it can be determined from what version
a resource is being upgraded to what version (a version being the plugin
version for simplicity). Now that the time pressure isn't that high, I think
it is a good time to start the discussion about this aspect of resource
upgrade so that it could be present in the next release.
Thinking about this today I found the implementation is going to be trickier
than I thought.
Originally I thought of this work-flow: When the agent receives the updated
plugins, it can determine what the two versions are and pass it down to the
plugin container so that it can then pass it down to the individual upgrade
methods. Done.
But what happens if the upgrade fails for some reason (bug in the upgrade()
method for example)?
Let me offer you some alternative ways of handling this on which I'll show
some of the problems that we'll have to deal with:
0) Just ignore the failure. If the plugin fails to upgrade a resource, tough
for it.
1) Upgrade failure = reject all the plugins and keep using the old versions.
This is obviously the easiest to implement but it just feels wrong. On upgrade
failure, we'd shutdown the PC without persisting the state and start it again
with the last known good state and old plugins. The server side would have to
be enhanced to tell the user what agent uses what version of the plugins and
why.
2) Upgrade failure = reject just the plugins from which the failing resources
come from.
Slightly better functionality wise, but this would mean that that we'd have to
perform some kind of partial revert of the resource contexts for the resources
that succeeded the upgrade but would come from the rogue plugins. Also, if
there are plugins dependent on the failed plugins we'd have to roll them back
(or rather their resources), too, because their new version might be
incompatible with the old version of the failed plugins. The server side would
like to know about this as well.
3) Upgrade failure = use the old plugins only for the failed resources, new
plugins for the upgraded resources.
The best functionality wise, but the bad points from above still apply.
Additionally, for this strategy we'd have to store the information on what
resource should use what plugin, but that's something we can't do on the agent
side because we have no authoritative store of information on the agent. The
info would have to be stored on the server side (we can store the plugin
version either at the resource, the resource type or create a new plugin
entity. I'm not sure about the effect of the latter two approaches because
because they would basically mean that we'd have more than one resource type
with the same name and plugin).
4) Demand that the plugins can handle resources of multiple versions.
That's fine, but then the plugins would need to know what version of the data
they are dealing with. Which brings us back to the problem of the server-side
storage.
5) Blacklist the resources that fail to upgrade. This is actually very similar
to 3 and 4, only rids the PC from running multiple version of the same plugin
or the plugin having to handle multiple versions of the resource data. The
server side storage might be slightly simpler than in the above 2 cases,
because we'd only need to store the "last known good plugin version" for the
blacklisted resources so that we can pass that info to the upgrade when the
plugins get updated next time.
I just can't make my mind up to pick one, the only ones I don't like from any
POV is (0,) 1 and 4.
What are your thoughts?
Thanks,
Lukas