Management proposal for attribute mutability

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Management proposal for attribute mutability

jtgreene
Administrator
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 if false (the default), but would continue and bounce everything
needed if the value is true. 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.

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.

--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

jtgreene
Administrator
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.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

jtgreene
Administrator
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.

To further clarify the reason to return the error is that the change to
the configuration model is NOT APPLIED. If you touch the config without
the runtime, then you are out of sync and the only reasonable action to
take from that point on is to restart the server. In this case we are
saying that changing an attribute could have hostile consequences
(bouncing a connection pool therby affecting inbound transactions), and
so we need some sort of confirmation by the admin that they really
intend to do this.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

Brian Stansberry
In reply to this post by jtgreene
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.

--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

jtgreene
Administrator
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.


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

Brian Stansberry
In reply to this post by jtgreene
On 8/22/11 1:47 PM, Jason T. Greene 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.
>
> To further clarify the reason to return the error is that the change to
> the configuration model is NOT APPLIED. If you touch the config without
> the runtime, then you are out of sync and the only reasonable action to
> take from that point on is to restart the server. In this case we are
> saying that changing an attribute could have hostile consequences
> (bouncing a connection pool therby affecting inbound transactions), and
> so we need some sort of confirmation by the admin that they really
> intend to do this.
>

I see. Seems this eliminates the ability to make a bunch of config
changes without affecting the runtime and then bouncing the server to
have them take effect.

It sounds like you are looking for 3 possible values for this attribute

true -- bounce the affected services
false -- apply to config, put server in restart-required state
undefined??? -- user made a mistake, return an error


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

jtgreene
Administrator
On 8/22/11 1:53 PM, Brian Stansberry wrote:

> On 8/22/11 1:47 PM, Jason T. Greene 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.
>>
>> To further clarify the reason to return the error is that the change to
>> the configuration model is NOT APPLIED. If you touch the config without
>> the runtime, then you are out of sync and the only reasonable action to
>> take from that point on is to restart the server. In this case we are
>> saying that changing an attribute could have hostile consequences
>> (bouncing a connection pool therby affecting inbound transactions), and
>> so we need some sort of confirmation by the admin that they really
>> intend to do this.
>>
>
> I see. Seems this eliminates the ability to make a bunch of config
> changes without affecting the runtime and then bouncing the server to
> have them take effect.

Yeah that's a good point. I didn't think of that.

>
> It sounds like you are looking for 3 possible values for this attribute
>
> true -- bounce the affected services
> false -- apply to config, put server in restart-required state
> undefined??? -- user made a mistake, return an error

Hmmm, yes I guess you could say there are three states:

ALLOW_SERVICE_RESTART (affects in-flight transactions)
DELAY_RESTART_UNTIL_NEXT_BOOT
REJECT_SERVICE_RESTART

On the other hand REJECT_SERVICE_RESTART is really a form of safety
checking / "babying" that could be pushed to the client, as long as we
had some kind of metadata to tell them the change affects in-flight
transactions.



--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

Brian Stansberry
On 8/22/11 2:05 PM, Jason T. Greene wrote:

> On 8/22/11 1:53 PM, Brian Stansberry wrote:
>> On 8/22/11 1:47 PM, Jason T. Greene 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.
>>>
>>> To further clarify the reason to return the error is that the change to
>>> the configuration model is NOT APPLIED. If you touch the config without
>>> the runtime, then you are out of sync and the only reasonable action to
>>> take from that point on is to restart the server. In this case we are
>>> saying that changing an attribute could have hostile consequences
>>> (bouncing a connection pool therby affecting inbound transactions), and
>>> so we need some sort of confirmation by the admin that they really
>>> intend to do this.
>>>
>>
>> I see. Seems this eliminates the ability to make a bunch of config
>> changes without affecting the runtime and then bouncing the server to
>> have them take effect.
>
> Yeah that's a good point. I didn't think of that.
>
>>
>> It sounds like you are looking for 3 possible values for this attribute
>>
>> true -- bounce the affected services
>> false -- apply to config, put server in restart-required state
>> undefined??? -- user made a mistake, return an error
>
> Hmmm, yes I guess you could say there are three states:
>
> ALLOW_SERVICE_RESTART (affects in-flight transactions)
> DELAY_RESTART_UNTIL_NEXT_BOOT
> REJECT_SERVICE_RESTART
>
> On the other hand REJECT_SERVICE_RESTART is really a form of safety
> checking / "babying" that could be pushed to the client, as long as we
> had some kind of metadata to tell them the change affects in-flight
> transactions.
>

It could, although true "babying" is only possible for a console or the
interactive CLI. A custom client or someone scripting CLI calls couldn't
be babied.

OT: this discussion implies that a simple "restart-required" ->
true|false is insufficient metadata for an operation or writable
attribute. Some ops simply cannot just bounce a service, they must have
a restart (e.g. those that add/remove DUPs). Some can bounce the
service. And some don't need to.

--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

Brian Stansberry
In reply to this post by jtgreene
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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management proposal for attribute mutability

jtgreene
Administrator
In reply to this post by Brian Stansberry
On 8/23/11 2:19 PM, Brian Stansberry wrote:

>> On the other hand REJECT_SERVICE_RESTART is really a form of safety
>> checking / "babying" that could be pushed to the client, as long as we
>> had some kind of metadata to tell them the change affects in-flight
>> transactions.
>>
>
> It could, although true "babying" is only possible for a console or the
> interactive CLI. A custom client or someone scripting CLI calls couldn't
> be babied.

IMO really we should decide whether we protection like this first. If we
don't the problem disappears. Do we want some kind of gaurantee that
modifications do not (by default) affect in-flight transactions?

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev