Update resources that depend on others fails about puppet-wildfly HOT 4 CLOSED

Important information extracted from a comment in PR #79.

• Unfortunately only a few subsystems have update-properties (e.g. /subsystem=logging/periodic-rotating-file-handler=FILE:update-properties(...)) and a composite operation of write-attribute is indeed a more generic solution.
• My main concern is more related to the case above (you need to disable a resource in order to change it) and deployments dependencies on resources, so if you have, for example, an EAR that depends on a datasource, a queue and a remoting connector, you won't be able to perform some changes in theses resources while the deployment is up (even with write-attribute). [1]

[1] In practice I've seen two ways to realize this: (1) change configuration XML (i.e. offline changes) or (2) disable deployment, change resources and enable it again. Both alternatives imply in a small downtime, and it might be related to JBoss AS 7+ architecture (subsystems are lazily loaded).

• I still can't see how we are going to implement more complex scenarios using just Puppet. Lately I've been thinking that you should use an orchestration tool (MCollective, Capistrano, Fabric, CFEngine) in conjunction with Puppet to perform operations that will put you in the desired state. What do you think? Are we able to put this dependency resolution intelligence in our custom types or is it too application-specific?

from puppet-wildfly.

Ok,

I think some things are not possible or can make the code/procedure pretty complex. So it keep it simple and off course it should be supported by the jboss core ( we don't want to do their work).

but if you want to do manually what are the steps you should do and do you also have some downtime of the resource.

Just brainstorming ( maybe I think to simple ), maybe the administrator should say on the datasource that a particular resource is dependent, check if there is a change on the datasource, we will try to disable the resource, do the datasource change and enable it again.

from puppet-wildfly.

Most of the time this has been handled by building the new resource beside the old resource with a different name. It's dirty, but it's a good way to keep track of your changes.

Another effective strategy is to rollback standalone.xml to it's initial state and reapply all resources. It could be possible to make Puppet work in conjunction with configuration history[1] to accomplish this seamlessly. (i.e. pass some sort of flag to build your new configuration on top of initial configuration)

Another update: Offline changes is not a constraint anymore since we have Offline CLI [2] in EAP 7+ / Wildfly 9+.

[1] https://docs.jboss.org/author/display/AS71/Configuration+file+history?_sscc=t
[2] https://developer.jboss.org/wiki/OfflineCLIWork

from puppet-wildfly.

operation-headers with ordering looks promising. Will create a separate issue for OfflineCLI and --server-config parameter.

from puppet-wildfly.