[jboss-jira] [JBoss JIRA] (WFLY-11860) Persistent deployments are lost on restart with '--read-only-server-config'

[ https://issues.jboss.org/browse/WFLY-11860?page=com.atlassian.jira.plugin... ] Maxim Sermin commented on WFLY-11860: ------------------------------------- Thanks a lot for your elaborate explanation. So it looks like: - we didn't fully understand the original intention behind `--read-only-server-config` - we're still looking for a way to solve our problem, which we believe should be rather common nowadays in config management driven environments The basic outline of what we're trying to achieve is: - control a basic/general set of configuration options of WFLY through an external configuration management application - control which artefacts should be deployed through an external configuration management application - make the deployments persistent, so a restart of the WFLY service outside of the configuration management scope is possible Initially, we faced the issue of flip-flopping the state of `standalone.xml` as its content was one the one hand controlled through config management tools, on the other hand, it was modified at runtime by WFLY. So we figured, `--read-only-server-config` was meant to provide a read-only configuration for exactly this scenario, while WFLY continues to write its runtime modifications as before to the read-write `standalone.xml`. This ended up resulting in the reported issue of deployments not surviving a restart of the WFLY service. In general, this situation violates the separation of the "configuration" and "runtime" domains, as the runtime leaks into the configuration domain which is a undesirable situation from a systems design PoV. Right now, it looks like we might be able to temporarily work around this issue by only controlling specific XML attributes through Augeas, while letting WFLY handle its `standalone.xml` as it used to. In the end, we believe a RFE to introduce the behavior of having a separated "read-only" and "runtime-modified" configuration to allow for the separation of those domains should be considered. -- This message was sent by Atlassian Jira (v7.12.1#712002)