8:34 a.m.
any reason for this?
[localhost:9999 /]
/host=local/server-config=test-server:write-attribute(name=group,value=main-server-group)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" =>
"Attribute group is not writeable"}
}
Ike
9:18 a.m.
same thing for server-group/profile
bug or feature?
On Apr 26, 2011, at 2:34 PM, Heiko Braun wrote:
any reason for this?
[localhost:9999 /]
/host=local/server-config=test-server:write-attribute(name=group,value=main-server-group)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" =>
"Attribute group is not writeable"}
}
Ike
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:20 a.m.
Am 26.04.2011 um 15:18 schrieb Heiko Braun:
same thing for server-group/profile
bug or feature?
I think that makes some sense. Changing the server-group or profile for a
managed instance would be a major reconfiguration of it. Deleting and creating
a new instance is probably much easier to handle and to get right.
Heiko
9:27 a.m.
I know. All I am asking for is some clarification how to move forward.
On Apr 26, 2011, at 3:20 PM, Heiko W.Rupp wrote:
Am 26.04.2011 um 15:18 schrieb Heiko Braun:
> same thing for server-group/profile
>
> bug or feature?
I think that makes some sense. Changing the server-group or profile for a
managed instance would be a major reconfiguration of it. Deleting and creating
a new instance is probably much easier to handle and to get right.
Heiko
10:32 a.m.
Yes, what Heiko describes was the rationale. It's not very satisfying
though. To switch a set of servers from one profile to another you have
to create a new server group, then delete the old servers and create new
matching ones that reference the new group.
There are plenty of config changes that can't be applied immediately to
a server runtime (e.g. adding or removing a subsystem that handles
deployment processing.) Those put the server in a "restart required"
state. We could handle these in the same manner. It requires a little
bit of extra work to implement, but I don't think it would be a big
deal. WDYT?
On 4/26/11 8:27 AM, Heiko Braun wrote:
I know. All I am asking for is some clarification how to move forward.
On Apr 26, 2011, at 3:20 PM, Heiko W.Rupp wrote:
>
> Am 26.04.2011 um 15:18 schrieb Heiko Braun:
>> same thing for server-group/profile
>>
>> bug or feature?
>
> I think that makes some sense. Changing the server-group or profile for a
> managed instance would be a major reconfiguration of it. Deleting and creating
> a new instance is probably much easier to handle and to get right.
>
> Heiko
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
5:26 a.m.
On Apr 26, 2011, at 4:32 PM, Brian Stansberry wrote:
There are plenty of config changes that can't be applied
immediately to
a server runtime (e.g. adding or removing a subsystem that handles
deployment processing.) Those put the server in a "restart required"
state. We could handle these in the same manner. It requires a little
bit of extra work to implement, but I don't think it would be a big
deal. WDYT?
It would be convenient to allow runtime changes the way you describe it.
IMO we should put it on the roadmap and figure out a milestone when we are going to apply
them.
But the current conceptual model (create new instead of modify/restart) works and is easy
to understand.
Somehow we would need to properly indicate the "restart required" state.
I get the feeling we are not fully aware of all implications at this point.
I.e. what happens when "restart is required" and some of the changes are
undone/replaced?
How do you properly (error handling, explaining to the user) distinguish
attributes/operations that
lead to this state?
As for the UI side of things, I would require the domain controller to tell when this is
the case.
It cannot be distinguished by client itself. Maybe this requires a proper state model for
resources?
I.e. server-config resource state transition:
[S1: applied] -> [S2: pending] -> [S3: applied]
Some questions that jump to my mind:
- Will a resource be "locked" for changes when in state "pending"?
- Can I revert from S2 to S1?
Ike
4744
days inactive
4747
days old
5 comments
3 participants
participants (3)
-
Brian Stansberry -
Heiko Braun -
Heiko W.Rupp