Resource Type versioning

Jay Shaughnessy jshaughn at redhat.com
Fri Dec 19 16:39:48 UTC 2014


I don't think hitting all managed resources is too big a deal, you're 
just talking about the top level AS servers, and only at agent startup.  
If you think it's a problem to change the default setting to a different 
value, based on the port discovery, then I guess I'm not sure what 
you're trying to do.  I thought that was the point of the upgrade code 
that was mistakenly omitted.  I'm not actually sure the server knows 
best the plugin configuration for properties that are set during 
discovery.  Those values are best determined by the plugin, I think.   
This approach  has a problem only if there is a use case such that the 
default port, if set, should not be changed to whatever the discovery 
code thinks it should be.

If that is a problem then we'd have to do something more hacky, like 
only perform this upgrade if the value is not set, or is set to some 
special value.  And then users would have to unset the property on 
servers they want upgraded.  That could be done via a group config update.


On 12/19/2014 11:05 AM, Libor Zoubek wrote:
> Yes, that is option #1, but unfortunately that would hit all managed 
> resources with default values whenever agent starts and this code 
> could become a half-working re-discovery (in case user reconfigures 
> his native host/port from default to something else and then restarts 
> agent, we'll detect it) - which goes against a rule "server knows the 
> best how pluginConfig looks like".
>
> Maybe my thoughts are very hypothetic and far from reality.
>
> Dne Fri, 19 Dec 2014 16:36:13 +0100 Jay Shaughnessy 
> <jshaughn at redhat.com> napsal(a):
>
>>
>> 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.
>>>
>>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
>



More information about the rhq-devel mailing list