Resource Type versioning
Libor Zoubek
lzoubek at redhat.com
Fri Dec 19 14:25:49 UTC 2014
Hello,
I'd like to ask for advice/recommendation. I am trying to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1173479 and sofar I came up
with 3 solutions - and I don't like any of those (what a bad day today).
https://bugzilla.redhat.com/show_bug.cgi?id=1173479 - we introduced 2 new
pluginConfiguration properties (which are required and have default
values), but we forgot to add code to resourceUpgrade facet
implementation, that detects those 2 props on existing resources. Now,
after upgrades to 4.13 it's too late for writing the resourceUpgrade code.
The code would have either to
1) try to detect those 2 properties on every agent start - because it is
not able to distinguish between older/newer resource. Resources imported
before upgrade have default values, and resources after upgrade have
correct values. Plugin code would have to literally detect both values at
agent start.
or
2) add another boolean property foo that would denote if a resource was
discovered before or after upgrade (those before will get upgraded and we
detect our 2 properties and foo is set to true (=upgraded))
3) introduce resource type version: extend plugin descriptor with optional
numeric attribute typeVersion. This typeVersion would help plugins in
resourceUpgrade code to know whether to run or not. typeVersion would have
to be stored in resource as well and upgradeCode would have to set the
version to latest and greatest in case the resource was upgraded (maybe
this could go to agent code)
I don't like any of above solutions
1) potential slowdown of agent start (especially if it is going to hit
resources being intentionally down)
2) stupid property
3) maybe an overhead to enrich all resources / resource types just because
of this type of bug. But this is my canditate.
I'd be thankful for any comments.
--
Libor Zoubek
More information about the rhq-devel
mailing list