Resource Type versioning

Jay Shaughnessy jshaughn at redhat.com
Fri Dec 19 15:36:13 UTC 2014


Why is it, "too late for writing the resourceUpgrade code"?   If I 
remember correctly the resource upgrade code gets executed on every 
agent startup.  So if you added code for the next release it could 
correct the situation, I think.  For example, "if (port == default) then 
update to real value if necessary".   I think this is roughly your 
option #1.  I don't think this is too bad, you really only have to do it 
if it's set to the default.  And upgrade logic only executes once per 
agent start.  We execute extra upgrade logic all over the place, it's 
not uncommon.

Option 2 is not great, we don't want to add an odd property just for our 
own use.  Option 3 is terrible.  Option 1 pretty much uses the resource 
upgrade as it is intended, I think.  A slight startup hit is not a big deal.


On 12/19/2014 9:25 AM, Libor Zoubek wrote:
> 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.
>
>



More information about the rhq-devel mailing list