Recursive management resource removes

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

Recursive management resource removes

Brian Stansberry
tl;dr

We're going to start ensuring that any time a resource is removed, all
it's children are properly removed too.

This will let users remove an entire profile from the domain config in
one op, which in important now that we make it easier to clone an entire
profile or include one profile in another. These features should mean
people will be more likely to perform major configuration surgery via
the management API instead of xml editing, and surgeons need to 'remove'
large chunks.

Long version

Just an FYI on pending changes in how 'remove' management operations are
handled in WildFly 10.

First, any resource that represents persistent configuration must expose
a no-arg 'remove' operation. This was an informal requirement before;
now it's formal.

Second, you'd think that if a resource is removed via a 'remove' op that
we'd *always* ensure that all child resources are properly removed as
well. "Properly" meaning necessary runtime changes are made (e.g.
services removed), not just that the resource is dropped from the
configuration model.

But this isn't the case. There are a couple resources that explicitly
reject the 'remove' request if their children haven't been removed
first. There are others where the Stage.RUNTIME logic handling the
removal of the child assumes the parent model is still present, which is
an invalid assumption if the parent is removed in the same op. And there
are *may* be some where the child resource is just dropped ignoring the
need to clean up child services.

With https://github.com/wildfly/wildfly-core/pull/880 and
https://github.com/wildfly/wildfly/pull/7734 I'm changing this. Now the
base handler class for 'remove' ops (AbstractRemoveStepHandler) will by
default add steps to recursively remove any child resources before
executing a step to remove the target resource.

If for some reason you don't want a step added to remove a particular
child, override the
AbstractRemoveStepHandler.removeChildRecursively(PathElement child)
method. For example, see [1]. This is expected to be a quite unusual
thing to do.

If your resource doesn't use AbstractRemoveStepHandler for implementing
'remove':

1) Why not?
2) You're responsible for implementing the same semantic.

Note there are a couple remove handler impls that have implemented
similar logic in a custom manner. Once a core release with WFCORE-808 in
it is in full, that custom logic can be dropped.

[1]
https://github.com/bstansberry/wildfly/commit/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33
[2]
https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recursive management resource removes

Heiko Braun
+1

On 13 Jul 2015, at 18:11, Brian Stansberry <[hidden email]> wrote:

tl;dr

We're going to start ensuring that any time a resource is removed, all 
it's children are properly removed too.

This will let users remove an entire profile from the domain config in 
one op, which in important now that we make it easier to clone an entire 
profile or include one profile in another. These features should mean 
people will be more likely to perform major configuration surgery via 
the management API instead of xml editing, and surgeons need to 'remove' 
large chunks.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recursive management resource removes

Paul Ferraro
In reply to this post by Brian Stansberry
This is great.  I had already proposed making this the default remove behavior for all clustering resources in https://github.com/wildfly/wildfly/pull/7407 via:
https://github.com/pferraro/wildfly/blob/infinispan/clustering/common/src/main/java/org/jboss/as/clustering/controller/RemoveStepHandler.java

Paul

----- Original Message -----

> From: "Brian Stansberry" <[hidden email]>
> To: [hidden email]
> Sent: Monday, July 13, 2015 12:11:22 PM
> Subject: [wildfly-dev] Recursive management resource removes
>
> tl;dr
>
> We're going to start ensuring that any time a resource is removed, all
> it's children are properly removed too.
>
> This will let users remove an entire profile from the domain config in
> one op, which in important now that we make it easier to clone an entire
> profile or include one profile in another. These features should mean
> people will be more likely to perform major configuration surgery via
> the management API instead of xml editing, and surgeons need to 'remove'
> large chunks.
>
> Long version
>
> Just an FYI on pending changes in how 'remove' management operations are
> handled in WildFly 10.
>
> First, any resource that represents persistent configuration must expose
> a no-arg 'remove' operation. This was an informal requirement before;
> now it's formal.
>
> Second, you'd think that if a resource is removed via a 'remove' op that
> we'd *always* ensure that all child resources are properly removed as
> well. "Properly" meaning necessary runtime changes are made (e.g.
> services removed), not just that the resource is dropped from the
> configuration model.
>
> But this isn't the case. There are a couple resources that explicitly
> reject the 'remove' request if their children haven't been removed
> first. There are others where the Stage.RUNTIME logic handling the
> removal of the child assumes the parent model is still present, which is
> an invalid assumption if the parent is removed in the same op. And there
> are *may* be some where the child resource is just dropped ignoring the
> need to clean up child services.
>
> With https://github.com/wildfly/wildfly-core/pull/880 and
> https://github.com/wildfly/wildfly/pull/7734 I'm changing this. Now the
> base handler class for 'remove' ops (AbstractRemoveStepHandler) will by
> default add steps to recursively remove any child resources before
> executing a step to remove the target resource.
>
> If for some reason you don't want a step added to remove a particular
> child, override the
> AbstractRemoveStepHandler.removeChildRecursively(PathElement child)
> method. For example, see [1]. This is expected to be a quite unusual
> thing to do.
>
> If your resource doesn't use AbstractRemoveStepHandler for implementing
> 'remove':
>
> 1) Why not?
> 2) You're responsible for implementing the same semantic.
>
> Note there are a couple remove handler impls that have implemented
> similar logic in a custom manner. Once a core release with WFCORE-808 in
> it is in full, that custom logic can be dropped.
>
> [1]
> https://github.com/bstansberry/wildfly/commit/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33
> [2]
> https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recursive management resource removes

Brian Stansberry
Yep. Those are the "couple remove handler impls that have implemented
similar logic in a custom manner" I mentioned. Thanks for those; I saw
them again when looking at the HASingleton stuff and that was the
impetus to get this cleared up. I also shamelessly stole your approach
of adding steps.

On 7/14/15 6:54 AM, Paul Ferraro wrote:

> This is great.  I had already proposed making this the default remove behavior for all clustering resources in https://github.com/wildfly/wildfly/pull/7407 via:
> https://github.com/pferraro/wildfly/blob/infinispan/clustering/common/src/main/java/org/jboss/as/clustering/controller/RemoveStepHandler.java
>
> Paul
>
> ----- Original Message -----
>> From: "Brian Stansberry" <[hidden email]>
>> To: [hidden email]
>> Sent: Monday, July 13, 2015 12:11:22 PM
>> Subject: [wildfly-dev] Recursive management resource removes
>>
>> tl;dr
>>
>> We're going to start ensuring that any time a resource is removed, all
>> it's children are properly removed too.
>>
>> This will let users remove an entire profile from the domain config in
>> one op, which in important now that we make it easier to clone an entire
>> profile or include one profile in another. These features should mean
>> people will be more likely to perform major configuration surgery via
>> the management API instead of xml editing, and surgeons need to 'remove'
>> large chunks.
>>
>> Long version
>>
>> Just an FYI on pending changes in how 'remove' management operations are
>> handled in WildFly 10.
>>
>> First, any resource that represents persistent configuration must expose
>> a no-arg 'remove' operation. This was an informal requirement before;
>> now it's formal.
>>
>> Second, you'd think that if a resource is removed via a 'remove' op that
>> we'd *always* ensure that all child resources are properly removed as
>> well. "Properly" meaning necessary runtime changes are made (e.g.
>> services removed), not just that the resource is dropped from the
>> configuration model.
>>
>> But this isn't the case. There are a couple resources that explicitly
>> reject the 'remove' request if their children haven't been removed
>> first. There are others where the Stage.RUNTIME logic handling the
>> removal of the child assumes the parent model is still present, which is
>> an invalid assumption if the parent is removed in the same op. And there
>> are *may* be some where the child resource is just dropped ignoring the
>> need to clean up child services.
>>
>> With https://github.com/wildfly/wildfly-core/pull/880 and
>> https://github.com/wildfly/wildfly/pull/7734 I'm changing this. Now the
>> base handler class for 'remove' ops (AbstractRemoveStepHandler) will by
>> default add steps to recursively remove any child resources before
>> executing a step to remove the target resource.
>>
>> If for some reason you don't want a step added to remove a particular
>> child, override the
>> AbstractRemoveStepHandler.removeChildRecursively(PathElement child)
>> method. For example, see [1]. This is expected to be a quite unusual
>> thing to do.
>>
>> If your resource doesn't use AbstractRemoveStepHandler for implementing
>> 'remove':
>>
>> 1) Why not?
>> 2) You're responsible for implementing the same semantic.
>>
>> Note there are a couple remove handler impls that have implemented
>> similar logic in a custom manner. Once a core release with WFCORE-808 in
>> it is in full, that custom logic can be dropped.
>>
>> [1]
>> https://github.com/bstansberry/wildfly/commit/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33
>> [2]
>> https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev