[JBoss JIRA] (WFCORE-368) Ability for processes to be placed in a state rejecting config changes and requiring a restart
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-368?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-368:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Ability for processes to be placed in a state rejecting config changes and requiring a restart
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-368
> URL: https://issues.jboss.org/browse/WFCORE-368
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> If a condition occurs whereby a managed process is in an unknown and inconsistent state, we need the ability to mark the process as being unsafe to modify in terms of configuration and requiring restart.
> Examples of this kind of situation in a standalone server would include:
> 1) timeouts waiting for MSC stability as envisioned in WFLY-2741.
> 2) failures that occur in operation rollback.
> In these cases, it is no longer practical to determine how internal service state relates to configuration state. Allowing further configuration changes will exacerbate the situation. The process should be restarted in order to restore consistency before allowing further config changes.
> In a domain environment this can also include servers that are inconsistent with respect to the domain model because some update has failed on that server but the rollout plan allowed the update to commit on other servers.
> In this case, the server config is inconsistent with the domain and subsequent changes to the domain will not make it consistent, so they should not be propagated to the server. The server needs to be restarted in order to get a complete configuration.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-380) Operations to read content from the content repository
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-380?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-380:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Operations to read content from the content repository
> ------------------------------------------------------
>
> Key: WFCORE-380
> URL: https://issues.jboss.org/browse/WFCORE-380
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Minor
> Fix For: 1.0.0.CR1
>
>
> Ability to pull data out of the content repository. We can do that with rollout plans, but not for deployments or if we add deployment content overlays.
> Basically, if the user loses the original of the deployment, let's let them get it back via the management API and remove the temptation for them to hack into the repository.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-379) Give option to make the content repository browsable
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-379?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-379:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Give option to make the content repository browsable
> ----------------------------------------------------
>
> Key: WFCORE-379
> URL: https://issues.jboss.org/browse/WFCORE-379
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Schofield
> Fix For: 1.0.0.CR1
>
>
> JBoss admins regularly need to view the application content that is deployed to a server. On previous versions of JBoss this was easy to do with the deploy directory. When using the new API to install applications the contents of applications are not easily browsable or searchable.
> Would like to have a setting that enables all content to be stored in exploded format in the content repository.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-378) Domain rollout operation timeouts
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-378?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-378:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Domain rollout operation timeouts
> ---------------------------------
>
> Key: WFCORE-378
> URL: https://issues.jboss.org/browse/WFCORE-378
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> Portion of the parent task related to rolling out changes to a domain.
> The expectation is that single process timeouts (WFLY-2741) will handle most failure conditions related to domain rollouts (e.g. if a single server hangs, preventing completion of the rollout, eventually that server will time out, allowing the domain wide rollout to continue.) Timeouts in the domain rollout code serve as a second line of defense:
> 1) In case of protocol or other problems that prevent the calling process learning about the timeout on the remote process
> 2) In case of bugs in the single process timeout handling on the remote process
> 3) In mixed domain cases where remote hosts are running previous versions and do not have the timeout function
> Potential places to add timeouts:
> DomainSlaveHandler->HostControllerUpdateTask.ProxyOperationListener.retrievePreparedOperation()
> -- where the master HC waits for responses from slaves
> RollingServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
> -- timeout here means 1 server didn't respond, but need to move on to next
> ConcurrentServerGroupUpdateTask.run() -> ServerTaskExecutor.ServerOperationListener.retrievePreparedOperation()
> -- timeout here means none of the remaining servers have responded w/in the timeout
> DomainRolloutStepHandler.finalizeOp() -> future.get()
> ---- the ServerGroupUpdateTask should fail in the normal phase, so any timeout here would indicate a problem committing the tx or a comms problem getting back the response
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-377) The management API should provide a command to restart only all servers that are in state 'reload-required'
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-377:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> The management API should provide a command to restart only all servers that are in state 'reload-required'
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-377
> URL: https://issues.jboss.org/browse/WFCORE-377
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Wolf-Dieter Fink
> Labels: cli, domain, management
> Fix For: 1.0.0.CR1
>
>
> After configuration changes via CLI batch it might be that different processes needs to be restarted.
> It is possible to iterate over all servers and check it.
> But I think it would be easier to have a command that restart all controllers and servers conditional to the 'relod required' state
> - at domain level
> - at host level
> - at server level
> command example :
> :restart(ifRequired=true)
> :reload(ifRequired=true)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-374) Rethink OperationContextImpl.getBasicAuthorizationResponse
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-374?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-374:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Rethink OperationContextImpl.getBasicAuthorizationResponse
> ----------------------------------------------------------
>
> Key: WFCORE-374
> URL: https://issues.jboss.org/browse/WFCORE-374
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> OperationContextImpl.getBasicAuthorizationResponse is designed around the "pass" case. It tests all action effects but discards data if any fail. This is ok in the normal case where things will pass. But in the read-resource-description and recursive read-resource cases, where things may often fail with the failure being recorded as expected (i.e. non-failure) output, this approach is inefficient, because the caller is forced to re-authorize to get the discarded data.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-381) xinclude support in the management model
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-381?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-381:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> xinclude support in the management model
> ----------------------------------------
>
> Key: WFCORE-381
> URL: https://issues.jboss.org/browse/WFCORE-381
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Jason Greene
> Fix For: 1.0.0.CR1
>
>
> Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-387) Describe inheritance relationships in the resource description metadata
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-387?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-387:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Describe inheritance relationships in the resource description metadata
> -----------------------------------------------------------------------
>
> Key: WFCORE-387
> URL: https://issues.jboss.org/browse/WFCORE-387
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 1.0.0.CR1
>
>
> Some elements in the management model have an inheritance relationship with other elements located elsewhere. For example, system properties can be defined as a child of the root domain resource, as a child of a server-group resource, as a child of the root host resource, and as a child of the server-config resource.
> The resource description metadata for a resource needs to describe these relationships. It needs to cover the inheritance hierarchy, as well as how any conflicts are resolved (i.e. does the child win, as is the case with system properties and interfaces, or is some sort of merging strategy employed, as is the case with profiles and socket-binding-groups, where the sets of child resources (subsystems and socket-bindings) are merged, provided that the two sets are disjoint.
> A factor to include in this metadata is whether the relationship is fixed (i.e. host system-property inherits from server-group) or whether there is some attribute that defines the inheritance (e.g. a profile's that "includes" another profile has an attribute that defines the name of the included profile.)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months