Plugin versioning for resource upgrade

John Mazzitelli mazz at redhat.com
Thu Aug 12 18:53:00 UTC 2010


what's the bugzilla link for this? I had some notes in there.

On 08/12/2010 02:39 PM, Lukas Krejci wrote:
> 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
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list