[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) 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.)
2) More significantly, 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.
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:
* slave-api-major-version
* slave-api-minor-version
* slave-api-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 slave-api-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
* unignored-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 unignored-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.
Adding a new group to unignored-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.
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) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this.)
2) More significantly, 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.
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:
* slave-api-major-version
* slave-api-minor-version
* slave-api-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 slave-api-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
* unignored-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 unignored-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.
Adding a new group to unignored-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) 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.)
> 2) More significantly, 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.
> 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:
> * slave-api-major-version
> * slave-api-minor-version
> * slave-api-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 slave-api-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
> * unignored-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 unignored-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.
> Adding a new group to unignored-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.
--
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) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this.)
2) More significantly, 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.
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:
* slave-api-major-version
* slave-api-minor-version
* slave-api-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 slave-api-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
* unignored-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 unignored-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.
Adding a new group to unignored-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.
was:
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) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this.)
2) More significantly, 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.
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:
* slave-api-major-version
* slave-api-minor-version
* slave-api-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 slave-api-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
* unignored-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 unignored-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.
Adding a new group to unignored-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) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this.)
> 2) More significantly, 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.
> 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:
> * slave-api-major-version
> * slave-api-minor-version
> * slave-api-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 slave-api-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
> * unignored-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 unignored-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.
> Adding a new group to unignored-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.
--
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)
Brian Stansberry created WFCORE-1340:
----------------------------------------
Summary: 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
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) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this.)
2) More significantly, 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.
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:
* slave-api-major-version
* slave-api-minor-version
* slave-api-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 slave-api-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
* unignored-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 unignored-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.
Adding a new group to unignored-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.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-341) PEM file format support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-341?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-341:
--------------------------------------
Just put on the roadmap and increased the priority as I think this is achievable and in demand.
> PEM file format support
> -----------------------
>
> Key: ELY-341
> URL: https://issues.jboss.org/browse/ELY-341
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta4
>
>
> We should add support for PEM formats for formats including (but not limited to):
> * X.509 Certificate
> * CSRs
> * CRLs
> * RSA and DSA Public and Private Keys
> * PKCS8 format Private Keys
> * DH parameters
> * ECDSA Public Key
> * EC Private Key
> * EC Parameters
> This API could be consumed by various utilities or by custom credential storage implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-341) PEM file format support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-341?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-341:
---------------------------------
Component/s: KeyStores
(was: API / SPI)
> PEM file format support
> -----------------------
>
> Key: ELY-341
> URL: https://issues.jboss.org/browse/ELY-341
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 1.1.0.Beta4
>
>
> We should add support for PEM formats for formats including (but not limited to):
> * X.509 Certificate
> * CSRs
> * CRLs
> * RSA and DSA Public and Private Keys
> * PKCS8 format Private Keys
> * DH parameters
> * ECDSA Public Key
> * EC Private Key
> * EC Parameters
> This API could be consumed by various utilities or by custom credential storage implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-341) PEM file format support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-341?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-341:
---------------------------------
Fix Version/s: 1.1.0.Beta4
> PEM file format support
> -----------------------
>
> Key: ELY-341
> URL: https://issues.jboss.org/browse/ELY-341
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 1.1.0.Beta4
>
>
> We should add support for PEM formats for formats including (but not limited to):
> * X.509 Certificate
> * CSRs
> * CRLs
> * RSA and DSA Public and Private Keys
> * PKCS8 format Private Keys
> * DH parameters
> * ECDSA Public Key
> * EC Private Key
> * EC Parameters
> This API could be consumed by various utilities or by custom credential storage implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-341) PEM file format support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-341?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-341:
---------------------------------
Priority: Major (was: Minor)
> PEM file format support
> -----------------------
>
> Key: ELY-341
> URL: https://issues.jboss.org/browse/ELY-341
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta4
>
>
> We should add support for PEM formats for formats including (but not limited to):
> * X.509 Certificate
> * CSRs
> * CRLs
> * RSA and DSA Public and Private Keys
> * PKCS8 format Private Keys
> * DH parameters
> * ECDSA Public Key
> * EC Private Key
> * EC Parameters
> This API could be consumed by various utilities or by custom credential storage implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months