[JBoss JIRA] (WFCORE-1881) Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1881?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1881:
-------------------------------------
Labels: domain-mode (was: )
> Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1881
> URL: https://issues.jboss.org/browse/WFCORE-1881
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Labels: domain-mode
>
> The WFCORE-338 work is going to add the notion of an HC being configured as a Candidate Domain Controller, which is a separate thing from being "master". There are a number of places where LocalHostControllerInfo.isMaster() is being called to make decisions that with WFCORE-338 should really depend on whether the HC is a CDC, not whether it is master. So, we want LHCI to expose whether the HC is a CDC.
> I think initially we can have isCandidateDomainController() just return the result of isMaster(). We can add a setter to LocalHostControllerInfoImpl later when we actually make the CDC status independently configurable.
> Places that should be updated as part of this task to use isCandidateDomainController() instead of isMaster():
> 1) ProfileCloneHandler
> 2) IgnoredDomainResourceRegistry
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1940) Propagate a persistent domain config revision number and time stamp around the domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1940?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1940:
-------------------------------------
Labels: domain-mode (was: )
> Propagate a persistent domain config revision number and time stamp around the domain
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-1940
> URL: https://issues.jboss.org/browse/WFCORE-1940
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> This is a subtask of WFCORE-338 and should not be done independent of that overall work.
> The election algorithm we are planning for WFCORE-338 depends on tracking the revision number for changes to the persistent domain-wide model (i.e. what gets written to domain.xml). The revision number will be a simple counter, but we will also track a revision timestamp. The timestamp is solely meant to be an aid to users in understanding when a revision occurred and is not itself relevant to the election algorithm
> Task here is to
> 1) Read the revision # and timestamp from domain.xml when it is parsed
> 2) Increment it locally on any HC when an operation updates the domain-wide persistent config.
> 3) Persist the local values in domain.xml whenever an operation updates the domain-wide persistent config.
> 4) For the master HC, propagate its current revision # and timestamp along with any multistep write operations pushed to slave HCs.
> 5) For the master HC, propagate its current revision # and timestamp along with the resource model data provided to newly connected HCs.
> 6) For slave HCs, use the revision # and timestamp provided by the master via 4) and 5) as the base value before incrementing in 2).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1883) Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1883?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1883:
-------------------------------------
Labels: domain-mode (was: )
> Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1883
> URL: https://issues.jboss.org/browse/WFCORE-1883
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> As part of WFCORE-338, a Candidate Domain Controller can shift between acting a master or acting as slave without requiring a reload or reboot.
> However, after initial boot, a DCC can be handling management requests. Any transition between acting as a master or slave to the other role must ensure that in-process management requests are not disrupted and that no new management requests are able to access the management model or runtime services until the transition is complete. As a practical matter this likely means that the transition task(s) must acquire the exclusive management lock and hold it until the transition is complete.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-91:
----------------------------------------
git grep "toLowerCase()" shows this in non-test code:
cli/src/main/java/org/jboss/as/cli/handlers/CommandTimeoutHandler.java: VALUES.add(tr.name().toLowerCase());
cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to match on the current local.
host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLowerCase()) : null;
host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk = hashKey.toLowerCase();
server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
server/src/main/java/org/jboss/as/server/operations/AbstractInstallationReporter.java: if (osName != null && osName.toLowerCase().contains("linux")) {
> Review use of Locale in toLowerCase() calls
> -------------------------------------------
>
> Key: WFCORE-91
> URL: https://issues.jboss.org/browse/WFCORE-91
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
>
> There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed:
> {code}
> $ git grep "toLowerCase()"
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress
> domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc
> domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor
> host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo
> host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase();
> server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + "
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow
> testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2073) Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2073?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2073:
-------------------------------------
Labels: domain-mode (was: )
> Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2073
> URL: https://issues.jboss.org/browse/WFCORE-2073
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: domain-mode
> Fix For: 4.0.0.Alpha1
>
>
> The ManagedProcess kill() method relies on a scan of running processes that have a command line with -D[<processname>] in the command line, refusing to do the OS kill if > 1 such process is found.
> This is troublesome if you have > 1 HC on the machine, as they are likely to use the same process names (e.g. "Server:server-one"). So the 'kill' doesn't happen, and destroy() gets used instead. Destroy doesn't seem as strong, as it seems to not prevent shutdown hook execution, leaving open the possibility of hangs.
> Perhaps the PC could generate a random int or even a short and include that as a param on the command line as well, then use that as part of the discrimination check.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2073) Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2073?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2073:
-------------------------------------
Fix Version/s: 4.0.0.Alpha1
> Increase the likelihood of ManagedProcess kill invoking the OS kill command when multiple HCs are on the system
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2073
> URL: https://issues.jboss.org/browse/WFCORE-2073
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: domain-mode
> Fix For: 4.0.0.Alpha1
>
>
> The ManagedProcess kill() method relies on a scan of running processes that have a command line with -D[<processname>] in the command line, refusing to do the OS kill if > 1 such process is found.
> This is troublesome if you have > 1 HC on the machine, as they are likely to use the same process names (e.g. "Server:server-one"). So the 'kill' doesn't happen, and destroy() gets used instead. Destroy doesn't seem as strong, as it seems to not prevent shutdown hook execution, leaving open the possibility of hangs.
> Perhaps the PC could generate a random int or even a short and include that as a param on the command line as well, then use that as part of the discrimination check.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2519) Upgrade jboss-logmanager from 2.0.5.Final to 2.0.6.Final
by James Perkins (JIRA)
James Perkins created WFCORE-2519:
-------------------------------------
Summary: Upgrade jboss-logmanager from 2.0.5.Final to 2.0.6.Final
Key: WFCORE-2519
URL: https://issues.jboss.org/browse/WFCORE-2519
Project: WildFly Core
Issue Type: Component Upgrade
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
An upgrade to the log manager will be required to resolve WFCORE-1585. An enhancement was made as part of LOGMGR-147 to allow child handlers to not be closed when the parent handler is closed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1923) Add configuration option to make the HTTP management interface unavailable on non-master HCs
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1923?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1923:
-------------------------------------
Labels: domain-mode (was: )
> Add configuration option to make the HTTP management interface unavailable on non-master HCs
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-1923
> URL: https://issues.jboss.org/browse/WFCORE-1923
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> This is a sub-requirement of WFCORE-338 and shouldn't be included independent of that without prior discussion.
> If a user has a group of candidate domain controllers, a classic way of providing a consistent URL for management clients in the face of changes in the elected DC is to front the set of candidates with a reverse proxy. But for that to work well, the proxy should only see one working HC at a time. For that to happen, we need the non-elected HCs to not open a listener on the HTTP management interface unless they are elected.
> Since users may not want this behavior (e.g. if they don't have a reverse proxy set up and thus will get no benefit), this needs to be configurable.
> Note that if users elect to use this function they will need to set up a native-management interface to handle the intra-domain traffic.
> An open question is whether the interface should not be available at all or whether it should just be that certain contexts are not available.
> Also worth some thought before proceeding with this is thinking about how a mod_cluster proxy would be integrated. Doing the mod_cluster integration is out of scope for this task, but it makes sense to think about it a bit so we don't go down a path that will make later mod_cluster work harder.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1879) Master HC should reject registration attempts by slaves that have any management API version greater than its own
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1879?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1879:
-------------------------------------
Labels: domain-mode (was: )
> Master HC should reject registration attempts by slaves that have any management API version greater than its own
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1879
> URL: https://issues.jboss.org/browse/WFCORE-1879
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Labels: domain-mode
>
> (Note: It's possible we already do this, or that somehow we effectively do due to things blowing up if the rule is broken.)
> We have always had a rule that the DC must be running the latest version of the software. If it isn't it can't reliably manage slaves as it cannot know how the slaves will interpret the operations it sends to them, and slaves will assume that the master is sending operations that are tailored to the management API versions it sent when it registered.
> I do not believe the software actually enforces this requirement though. With the more complex use cases that WFCORE-338 will introduce we need to make this more formal.
> When a slave first contacts a master it provides its kernel API version with the HostInfo data it sends over and then later in the registration process it provides the subsystem API versions for all the extensions the master provided. Both of these points provide an opportunity for version comparison.
> When an HC rejects registration by a slave, we have a mechanism for propogating an error code to the slave to help it understand and report the problem (e.g. the remote HC is not master or it is running in admin-only mode.) We should try to expand that mechanism to include this case, rather than failing with a general unspecified error.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1880) Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1880?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1880:
-------------------------------------
Labels: domain-mode (was: )
> Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1880
> URL: https://issues.jboss.org/browse/WFCORE-1880
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Labels: domain-mode
>
> Conceptually related to WFCORE-1879, but here the case is a slave that is already registered handling an /extension=foo:add operation sent by the master. It's theoretically possible that the slave might be running an earlier or equal version of all extensions that were configured when it registered, but for this new "foo" extension it has a newer version. If this happens the add operation should fail. The extension cannot be configured while the domain topology is like this.
> Note if the slave is ignoring the extension add op, that is fine.
> It's possible this is already somewhat handled. If an extension is added, for transformation to work properly the slave has to send back management API information that the master can use going forward. It's possible though that even that is not being done, which would be a bug.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months