[JBoss JIRA] (WFCORE-3350) Elytron subsystem policy resource management API is incorrect
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3350?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3350:
-------------------------------------
Description:
This cloned from WFCORE-3041 but I'm redefining it from being an annoying symptom of a larger problem to being a general problem with an incorrect management API. I'm filing it as a Blocker as we do not want to ship a .GA release with a broken API that we can't readily fix.
Here's my analysis of what's wrong with this API from WFCORE-3041:
tl;dr; skip to #5.
1) This resource is an effective singleton, because creating more than one will result in a failure due to trying to register POLICY_RUNTIME_CAPABILITY more than once.
a) The resource description doesn't state the max occurrences of the resource type is 1. The fact that's missing is a Major at worst.
b) If the resource type isn't meant to be a singleton, we have at least a Critical, because the POLICY_RUNTIME_CAPABILITY handling is preventing more than one.
2) Despite being an effective singleton, the resource can have a dynamic name. That's odd. Now we're starting to approach Blocker territory because this is odd, we want API to be correct in WildFly .Final releases, and we can't change things incompatibly thereafter.
3) The reason the resource can have a dynamic name is there has to be a "default policy" and instead of making the resource a singleton with a static name and making the default-policy attribute required, instead there's this weird thing where if default-policy is not configured we use the resource name instead. Not a clear Blocker in and of itself, but again getting into blocker territory because we want our API right in WildFly .Final releases, and we can't change things incompatibly thereafter.
4) The 'default-policy' attribute is actually a model reference, referring to one of the elements in the sibling jacc-policy or custom-policy lists. Typically we would want to use a capability reference for this kind of model ref, but we can't here:
a) Doing so would require unique names for the elements across the 2 lists. Which doesn't sound like much of a problem, but isn't something we can't impose after WF 11 Final.
b) This business of the value of the last attribute of the resource name being the capability ref isn't something describable. I do not want to support that kind of thing in our management model and our provisioning tooling; i.e. if we have this kind of usage it likely precludes using a capability reference for it.
5) Digging more after writing all the above, I can't see what the point of the jacc-policy and custom-policy lists is anyway. The code is going to work out the default policy, either from the attribute or the resource name. Then it is going to search the jacc-policy list and then the custom-policy list looking for an element whose name matches. As soon as it finds a match it stops. All other elements are irrelevant. So what's the point of these lists? Why doesn't jacc-policy just store a single item, and custom-policy stores a single item, with both attributes required but are alternatives to each other? And then since only one policy can be declared the whole default-policy business goes away.
All of the above sounds complicated, but in the end I think the simplest fix is #5 which is fairly easy. We can also decide about #2 (giving the resource a fixed name) but given where we are in the release cycle I think not changing that makes sense. It's not a major flaw to allow a user to provide part of the name of a singleton resource.
============================
Here's the original report from [~claudio4j] of *a* specific problem this introduces:
subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
{code}
/profile=full/subsystem=elytron/policy=policy_test:add
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
"rolled-back" => true,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "failed",
"failure-description" => "Could find policy provider with name [policy_test]",
"rolled-back" => true
}}}}}}
}
{code}
To add is necessary to inform either custom-policy or jacc-policy
{code}
/profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
{
"outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}}}}}}
}
{code}
There is also a problem related to "default-policy" being set to a non existent policy.
was:
subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
{code}
/profile=full/subsystem=elytron/policy=policy_test:add
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
"rolled-back" => true,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "failed",
"failure-description" => "Could find policy provider with name [policy_test]",
"rolled-back" => true
}}}}}}
}
{code}
To add is necessary to inform either custom-policy or jacc-policy
{code}
/profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
{
"outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}}}}}}
}
{code}
There is also a problem related to "default-policy" being set to a non existent policy.
> Elytron subsystem policy resource management API is incorrect
> -------------------------------------------------------------
>
> Key: WFCORE-3350
> URL: https://issues.jboss.org/browse/WFCORE-3350
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Brian Stansberry
> Assignee: Michal Petrov
> Priority: Blocker
>
> This cloned from WFCORE-3041 but I'm redefining it from being an annoying symptom of a larger problem to being a general problem with an incorrect management API. I'm filing it as a Blocker as we do not want to ship a .GA release with a broken API that we can't readily fix.
> Here's my analysis of what's wrong with this API from WFCORE-3041:
> tl;dr; skip to #5.
> 1) This resource is an effective singleton, because creating more than one will result in a failure due to trying to register POLICY_RUNTIME_CAPABILITY more than once.
> a) The resource description doesn't state the max occurrences of the resource type is 1. The fact that's missing is a Major at worst.
> b) If the resource type isn't meant to be a singleton, we have at least a Critical, because the POLICY_RUNTIME_CAPABILITY handling is preventing more than one.
> 2) Despite being an effective singleton, the resource can have a dynamic name. That's odd. Now we're starting to approach Blocker territory because this is odd, we want API to be correct in WildFly .Final releases, and we can't change things incompatibly thereafter.
> 3) The reason the resource can have a dynamic name is there has to be a "default policy" and instead of making the resource a singleton with a static name and making the default-policy attribute required, instead there's this weird thing where if default-policy is not configured we use the resource name instead. Not a clear Blocker in and of itself, but again getting into blocker territory because we want our API right in WildFly .Final releases, and we can't change things incompatibly thereafter.
> 4) The 'default-policy' attribute is actually a model reference, referring to one of the elements in the sibling jacc-policy or custom-policy lists. Typically we would want to use a capability reference for this kind of model ref, but we can't here:
> a) Doing so would require unique names for the elements across the 2 lists. Which doesn't sound like much of a problem, but isn't something we can't impose after WF 11 Final.
> b) This business of the value of the last attribute of the resource name being the capability ref isn't something describable. I do not want to support that kind of thing in our management model and our provisioning tooling; i.e. if we have this kind of usage it likely precludes using a capability reference for it.
> 5) Digging more after writing all the above, I can't see what the point of the jacc-policy and custom-policy lists is anyway. The code is going to work out the default policy, either from the attribute or the resource name. Then it is going to search the jacc-policy list and then the custom-policy list looking for an element whose name matches. As soon as it finds a match it stops. All other elements are irrelevant. So what's the point of these lists? Why doesn't jacc-policy just store a single item, and custom-policy stores a single item, with both attributes required but are alternatives to each other? And then since only one policy can be declared the whole default-policy business goes away.
> All of the above sounds complicated, but in the end I think the simplest fix is #5 which is fairly easy. We can also decide about #2 (giving the resource a fixed name) but given where we are in the release cycle I think not changing that makes sense. It's not a major flaw to allow a user to provide part of the name of a singleton resource.
> ============================
> Here's the original report from [~claudio4j] of *a* specific problem this introduces:
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "Could find policy provider with name [policy_test]",
> "rolled-back" => true
> }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3350) Elytron subsystem policy resource management API is incorrect
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3350?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3350:
-------------------------------------
Reporter: Brian Stansberry (was: Claudio Miranda)
> Elytron subsystem policy resource management API is incorrect
> -------------------------------------------------------------
>
> Key: WFCORE-3350
> URL: https://issues.jboss.org/browse/WFCORE-3350
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Brian Stansberry
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 3.0.5.Final
>
>
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "Could find policy provider with name [policy_test]",
> "rolled-back" => true
> }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3350) Elytron subsystem policy resource management API is incorrect
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3350:
----------------------------------------
Summary: Elytron subsystem policy resource management API is incorrect
Key: WFCORE-3350
URL: https://issues.jboss.org/browse/WFCORE-3350
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Claudio Miranda
Assignee: Michal Petrov
Priority: Blocker
Fix For: 3.0.5.Final
subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
{code}
/profile=full/subsystem=elytron/policy=policy_test:add
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
"rolled-back" => true,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "failed",
"failure-description" => "Could find policy provider with name [policy_test]",
"rolled-back" => true
}}}}}}
}
{code}
To add is necessary to inform either custom-policy or jacc-policy
{code}
/profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
{
"outcome" => "success",
"result" => undefined,
"server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}}}}}}
}
{code}
There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3041) Cannot add policy resource with no parameter
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3041?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3041:
-------------------------------------
Fix Version/s: 3.0.5.Final
Priority: Blocker (was: Major)
> Cannot add policy resource with no parameter
> --------------------------------------------
>
> Key: WFCORE-3041
> URL: https://issues.jboss.org/browse/WFCORE-3041
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 3.0.5.Final
>
>
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "Could find policy provider with name [policy_test]",
> "rolled-back" => true
> }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3041) Cannot add policy resource with no parameter
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3041?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3041:
------------------------------------------
I'm poking at this because I'm concerned that correcting this general area should be a Blocker for WF 11.
tl;dr; skip to #5.
1) This resource is an effective singleton, because creating more than one will result in a failure due to trying to register POLICY_RUNTIME_CAPABILITY more than once.
a) The resource description doesn't state the max occurrences of the resource type is 1. The fact that's missing is a Major at worst.
b) If the resource type isn't meant to be a singleton, we have at least a Critical, because the POLICY_RUNTIME_CAPABILITY handling is preventing more than one.
2) Despite being an effective singleton, the resource can have a dynamic name. That's odd. Now we're starting to approach Blocker territory because this is odd, we want API to be correct in WildFly .Final releases, and we can't change things incompatibly thereafter.
3) The reason the resource can have a dynamic name is there has to be a "default policy" and instead of making the resource a singleton with a static name and making the default-policy attribute required, instead there's this weird thing where if default-policy is not configured we use the resource name instead. Not a clear Blocker in and of itself, but again getting into blocker territory because we want our API right in WildFly .Final releases, and we can't change things incompatibly thereafter.
4) The 'default-policy' attribute is actually a model reference, referring to one of the elements in the sibling jacc-policy or custom-policy lists. Typically we would want to use a capability reference for this kind of model ref, but we can't here:
a) Doing so would require unique names for the elements across the 2 lists. Which doesn't sound like much of a problem, but isn't something we can't impose after WF 11 Final.
b) This business of the value of the last attribute of the resource name being the capability ref isn't something describable. I do not want to support that kind of thing in our management model and our provisioning tooling; i.e. if we have this kind of usage it likely precludes using a capability reference for it.
5) Digging more after writing all the above, I can't see what the point of the jacc-policy and custom-policy lists is anyway. The code is going to work out the default policy, either from the attribute or the resource name. Then it is going to search the jacc-policy *list* and then the custom-policy *list* looking for an element whose name matches. As soon as it finds a match it stops. All other elements are irrelevant. So what's the point of these lists? Why doesn't jacc-policy just store a single item, and custom-policy stores a single item, with both attributes required but are alternatives to each other? And then since only one policy can be declared the whole default-policy business goes away.
I'm going to raise sorting this to Blocker because unless I've missed something this is complex to the point of just being broken and it can't be readily fixed in a later release.
> Cannot add policy resource with no parameter
> --------------------------------------------
>
> Key: WFCORE-3041
> URL: https://issues.jboss.org/browse/WFCORE-3041
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Michal Petrov
> Fix For: 3.0.5.Final
>
>
> subsystem=elytron/policy resources has no required attributes, but it fails to add a resource with no parameters.
> {code}
> /profile=full/subsystem=elytron/policy=policy_test:add
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {"server-one" => "Could find policy provider with name [policy_test]"}}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "Could find policy provider with name [policy_test]",
> "rolled-back" => true
> }}}}}}
> }
> {code}
> To add is necessary to inform either custom-policy or jacc-policy
> {code}
> /profile=full/subsystem=elytron/policy=policy2:add(jacc-policy=[{name=policy2}])
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }}}}}}
> }
> {code}
> There is also a problem related to "default-policy" being set to a non existent policy.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
Claudio Miranda updated WFLY-7418:
----------------------------------
Labels: move_to_halnext (was: )
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
> Labels: move_to_halnext
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months