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(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel