[JBoss JIRA] (WFCORE-1354) Cannot clone a profile with a remoting subsystem but no io subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1354?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1354:
------------------------------------------
WFCORE-1354 somewhat blocks WFCORE-1340 by making testing of profile cloning scenarios difficult.
> Cannot clone a profile with a remoting subsystem but no io subsystem
> --------------------------------------------------------------------
>
> Key: WFCORE-1354
> URL: https://issues.jboss.org/browse/WFCORE-1354
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 2.0.10.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.11.Final
>
>
> The remoting subsystem added a requirement for the new io subsystem's worker capability, but it has special logic such that the requirement is only added if an endpoint resource is configured. So, legacy configs (pre-io) won't have that resource, so there is no requirement.
> This breaks down in the case of the profile 'clone' op, as a placeholder resource we add for the endpoint (to allow reads of the default endpoint config data) ends up getting 'described' and added by the cloning process. So that added resource triggers an unmet requirement for the io worker:
> {code}
> [domain@localhost:9990 /] /profile=default:clone(to-profile=test)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
> org.wildfly.io.worker.default in context 'profile=test'; There are no known registration points which can provide this capability."},
> "rolled-back" => true
> }
> {code}
> I'm not sure how to deal with this; some sort of marker is needed to disable 'describing' that placeholder resource.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1354) Cannot clone a profile with a remoting subsystem but no io subsystem
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1354:
----------------------------------------
Summary: Cannot clone a profile with a remoting subsystem but no io subsystem
Key: WFCORE-1354
URL: https://issues.jboss.org/browse/WFCORE-1354
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Remoting
Affects Versions: 2.0.10.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.11.Final
The remoting subsystem added a requirement for the new io subsystem's worker capability, but it has special logic such that the requirement is only added if an endpoint resource is configured. So, legacy configs (pre-io) won't have that resource, so there is no requirement.
This breaks down in the case of the profile 'clone' op, as a placeholder resource we add for the endpoint (to allow reads of the default endpoint config data) ends up getting 'described' and added by the cloning process. So that added resource triggers an unmet requirement for the io worker:
{code}
[domain@localhost:9990 /] /profile=default:clone(to-profile=test)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
org.wildfly.io.worker.default in context 'profile=test'; There are no known registration points which can provide this capability."},
"rolled-back" => true
}
{code}
I'm not sure how to deal with this; some sort of marker is needed to disable 'describing' that placeholder resource.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6112) set javaagent
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6112?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6112.
----------------------------------
Resolution: Rejected
This looks like a bug in your agent. This method in question looks like:
static MavenResolver createDefaultResolver() {
return new DefaultMavenResolver();
}
This only way it will throw that exception is if the agent has instrumented it in some incorrect way.
> set javaagent
> -------------
>
> Key: WFLY-6112
> URL: https://issues.jboss.org/browse/WFLY-6112
> Project: WildFly
> Issue Type: Bug
> Environment: Window 7 , jdk1.8.0
> Reporter: veerendra shukla
> Assignee: Jason Greene
>
> getting below error when i am setting jacocoagent.jar as below in standalone.conf.bat file
> 1. made changes in standalone.conf.bat
> set "JAVA_OPTS=%JAVA_OPTS% -javaagent:D:\home\ubuntu\agent\webomates-cq-agent\jacoco\setup\lib\jacocoagent.jar=destfile=D:\home\ubuntu\agent\webomates-cq-agent\jacoco\setup\jacoco.exec,append=false,append=false"
> 2. run standalone.bat file
> Error log:
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: "D:\download\wildfly-10.0.0.CR5"
> JAVA: "C:\Program Files\Java\jdk1.8.0_66\bin\java"
> JAVA_OPTS: "-client -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -javaagent:D:\home\ubun
> tu\agent\webomates-cq-agent\jacoco\setup\lib\jacocoagent.jar=destfile=D:\home\ubuntu\agent\webomates-cq-agent\jacoco\setup\jacoco.exec,append=false,append=false"
> ===============================================================================
> Picked up _JAVA_OPTIONS: -Xmx512M
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
> at org.jboss.modules.maven.MavenResolver.createDefaultResolver(MavenResolver.java:78)
> at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204)
> at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170)
> at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144)
> at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439)
> at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342)
> at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:221)
> at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:88)
> at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:82)
> at __redirected.__DocumentBuilderFactory.changeDefaultFactory(__DocumentBuilderFactory.java:76)
> at __redirected.__JAXPRedirected.changeAll(__JAXPRedirected.java:39)
> at org.jboss.modules.Main.main(Main.java:391)
> Press any key to continue . . .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1340:
-------------------------------------
Description:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
Proposed structure:
Resources are at address /host-exclude=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* host-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* active-server-groups
* active-socket-binding-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'ignored-extensions' data *will* be used for the slave.
An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
was:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
Proposed structure:
Resources are at address /host-exclude=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* host-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* excluded-extensions
* active-server-groups
* active-socket-binding-groups
The excluded-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'excluded-extensions' data will be used for the slave.
An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
> Proposed structure:
> Resources are at address /host-exclude=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * host-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * ignored-extensions
> * active-server-groups
> * active-socket-binding-groups
> The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
>
> Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
> A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'ignored-extensions' data *will* be used for the slave.
> An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1340:
-------------------------------------
Description:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
Proposed structure:
Resources are at address /host-exclude=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* host-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* excluded-extensions
* active-server-groups
* active-socket-binding-groups
The excluded-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'excluded-extensions' data will be used for the slave.
An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
was:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
Proposed structure:
Resources are at address /host-exclude=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* host-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* active-server-groups
* active-socket-binding-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured.
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
> Proposed structure:
> Resources are at address /host-exclude=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * host-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * excluded-extensions
> * active-server-groups
> * active-socket-binding-groups
> The excluded-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
>
> Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "exclude" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
> A WildFly Core 2 or later slave will send its ignore-unused-configuration setting when it registers. If this is set to 'true', the DC will not use any of the domain wide active-server-groups and active-socket-binding-groups data in its handling of that slave. That setting means the slave is taking responsibility for informing the DC of what should server-groups, profiles and socket-binding-groups be ignored. Mixing this WFCORE-1340 functionality into that creates too much complication. However, the domain-wide 'excluded-extensions' data will be used for the slave.
> An EAP 6.x slave can't set ignore-unused-configuration, so there is no confusion for that use case, which is the primary one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1340:
-------------------------------------
Description:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
Proposed structure:
Resources are at address /host-exclude=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* host-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* active-server-groups
* active-socket-binding-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
was:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
Proposed structure:
Resources are at address /host-ignore=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* slave-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* active-server-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data. The concept will be referred to as a "host-exclude" because what is happening in this case is not the slave ignoring some resources, it's the DC excluding them from the slave's view.
> Proposed structure:
> Resources are at address /host-exclude=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * host-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4, WildFly10.0) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * ignored-extensions
> * active-server-groups
> * active-socket-binding-groups
> The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile and socket-binding-group resources will not be ignored; all others of these types will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> The active-socket-binding-groups attribute is only meaningful if active-server-groups is set, and it only needs to be set if the set of socket-binding-groups associated with the groups listed in active-socket-binding-groups is not the complete set of sbgs needed on server's running the legacy release. This can happen is the server-config element for some servers overrides the normal socket-binding-group specified in the server-group config and specifies some different sbg. This is expected to be an edge case.
>
> Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> Changing the profile or socket-binding-group associated with a group listed in active-server-groups will not cause existing slave HCs to get new data sent to them. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (LOGMGR-128) Create the ability to close or destroy a LogContext
by James Perkins (JIRA)
James Perkins created LOGMGR-128:
------------------------------------
Summary: Create the ability to close or destroy a LogContext
Key: LOGMGR-128
URL: https://issues.jboss.org/browse/LOGMGR-128
Project: JBoss Log Manager
Issue Type: Feature Request
Reporter: James Perkins
The {{org.jboss.logmanager.LogContext}} should have the ability to be closed or better put destroyed. Each logger, formatter, error-handler and handler would be removed and closed if required.
This is useful for things like the WildFly embedded CLI server when the embedded log context needs to be destroyed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months