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