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

[Brian Stansberry]

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();
   }
}

If your handler subclasses AbstractBoottimeAddStepHandler or 
ServerWriteAttributeOperationHandler the base classes handle this for you.

if false (the default), but would continue and bounce everything
> needed if the value is true.

The default is a bit tricky. This operation and hence this parameter 
applies to every attribute, and a default of 'false' basically means 
don't bounce services that normally could be bounced. A default of 
'true' is more aggressive than I think users would want.

It could be metadata-dependent, i.e. if the metadata for the attribute 
has "restart-required" --> true then the default is false, otherwise 
true. That's complex.

I'll think about another name for the parameter that removes the 
ambiguity (not hopeful.)

In addition we would add some simple
> description metadata that would allow tools to handle it right away
> instead of reacting to the error response.
>

Yes, this is a must-have that's been hanging out there for a while and 
we have to resolve it now.

I propose a simple "restart-required" key with a true|false value be 
added to the "Description of an Attribute" and "Description of an 
Operation" sections of 
http://community.jboss.org/wiki/DetypedDescriptionOfTheAS7ManagementModel . 
If not present, the default value is "false".

A more complex scheme would have legal values of "yes|no|maybe", with a 
"restart-required-description" key providing a text explanation of the 
"maybe". But that seems like overkill.

> For a practical example look at datasources. Due to limitations in JCA
> we have to restart the resource adapter if the jdbc connection url
> changes. While it should be possible to one day make this change hot, we
> can for the time being still allow the user to type in a value. They
> would however be prompted with some kind of dialogue that would confirm
> the impact of this change.
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat