On 09/14/2010 12:04 PM, Lukas Krejci wrote:
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).
Keep in mind if you piggy-back on the resource error
conceobject will
only contain pt for upgrade errors, that this state can be
lost/overridden by future plugin configuration update - whether it
originated from the resource or the group. If the future plugin
configuration update is successful, the previous message about the
upgrade failure is lost; but even if the plugin config update fails, the
error (since it only represents the most recent issue) will override the
information about the upgrade failure. So if the plugin configuration
update is kicked off from the group-level, the user/operator might not
even see the error at all.
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.
So logically
equivalent, but with differing resource keys, right? One
has the resource key from the old plugin, and one has the resource key
from the new plugin?
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).
First, what are the expected
failure scenarios here? Are we presuming
that we can't change the value of a string (in this case representing
the resource key) to some new value?
Although the above suggestion seems like a possible catch-all routine,
I'd like to understand the precise failure conditions we anticipate
here, so we can investigate whether there are more reasonable ways of
handling those specific types of failures.
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.
Is it possible to ignore the new version of plugin A if there
are
upgrade errors...and just use the existing (a.k.a "old") version of
plugin A, which is presumed to have been working? This, understandably,
becomes more complicated because of dependencies between plugins, which
may require all plugins in the connected dependency graph to be rolled
back as well...and is that even possible if some resources have already
been upgraded?
What are your thoughts?
Thanks,
Lukas
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel