[jboss-as7-dev] Management proposal for attribute mutability

[Brian Stansberry]

On 8/22/11 1:52 PM, Jason T. Greene wrote:
> On 8/22/11 1:48 PM, Brian Stansberry wrote:
>> On 8/22/11 1:42 PM, Jason T. Greene wrote:
>>> On 8/22/11 1:26 PM, Brian Stansberry wrote:
>>>> On 8/2/11 4:22 PM, Jason T. Greene wrote:
>>>>> Currently we have way too many read only attributes in our management
>>>>> model. This makes life harder for the management tools and/or makes
>>>>> the
>>>>> resulting UI a bit unwieldy.
>>>>>
>>>>> In some cases this is just because we haven't polished subsystem
>>>>> management (PLEASE all subsystem authors look at this!). In other
>>>>> cases
>>>>> though it's intentional because it is either difficult or currently
>>>>> impossible to make hot changes to a particular attribute. This
>>>>> should be
>>>>> exceedingly rare. Users love hot updates, and it's a competitive
>>>>> advantage. So first we should strive to make it hot in the first
>>>>> place.
>>>>>
>>>>> However in the case that the change is not hot, and a server reboot is
>>>>> too aggressive, we should still supporting making the changes by
>>>>> bouncing all services involved. After some debate on IRC we finally
>>>>> arrived at what is IMO a really good option for this problem:
>>>>>
>>>>> write-attribute (impact-services=true|false)
>>>>>
>>>>> The operation handler on such a non-hot attribute would then return an
>>>>> error
>>>>
>>>> A handler should not return an error if a change cannot be applied to
>>>> the runtime. An OperationStepHandler should use the relevant API on the
>>>> OperationContext. E.g. for a handler registered for Stage.RUNTIME:
>>>>
>>>> @Override
>>>> public void execute(OperationContext context, ModelNode operation) {
>>>>
>>>> context.runtimeUpdateSkipped();
>>>> context.reloadRequired(); // or context.restartRequired();
>>>> if (context.completeStep() ==
>>>> OperationContext.ResultAction.ROLLBACK)
>>>> {
>>>> context.revertReloadRequired();
>>>> // or context.revertRestartRequired();
>>>> }
>>>> }
>>>
>>> Well in my above comment I was referring to a problem where a full
>>> server reload and/or restart is too aggressive (i.e. why bounce the web
>>> server when all you want to do is bounce a datasource). So the issue is
>>> that these attributes don't fit that problem.
>>>
>>
>> Sure, what you propose is the right solution for only bouncing a
>> datasource. But, if the operation has "impact-services" --> false, I'm
>> just saying the handler should not "return an error" (i.e. throw an
>> exception or use context.getFailureDescription().set("blah blah")). It
>> should properly inform the context that restart or reload is required.
>
> That was originally what I was thinking as well. The issue is that once
> you set that it's sticky right? (All further operations return
> reload/restart/etc required). Then the problem becomes how do you reset
> that sticky flag, and once again guarantee you are in sync.
>

If you bounce the ApplicationServerService (what the reload op does), 
then the reload-required flag is cleared. Restart-require requires a 
restart. ;)

We could also allow it to be cleared via an op, for advanced users only. 
That gives me a queasy feeling. I'd be less queasy if we had an audit 
log visualization tool to help that advanced user see what's transpired 
since the process went into restart-required state.



-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat