[JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2
by viet nguyen (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plu... ]
viet nguyen updated HAWKULARQE-73:
----------------------------------
Description:
Use cluster2 (JON BC hardware) for a larger set up than OS1.
- Rebuild cluster. Both master and node are on bare metal
- 30 metrics per pod
- -how many pods- 239 promgen pods (prometheus generator)
- verify metrics definition count
- verify metrics data
was:
Use cluster2 (JON BC hardware) for a larger set up than OS1.
- Rebuild cluster. Both master and node are on bare metal
- 30 metrics per pod
- -how many pods- 239 promgen (prometheus generator)
- verify metrics definition count
- verify metrics data
> Rebuild internal cluster 2
> ---------------------------
>
> Key: HAWKULARQE-73
> URL: https://issues.jboss.org/browse/HAWKULARQE-73
> Project: Hawkular QE
> Issue Type: Sub-task
> Reporter: viet nguyen
> Assignee: viet nguyen
>
> Use cluster2 (JON BC hardware) for a larger set up than OS1.
> - Rebuild cluster. Both master and node are on bare metal
> - 30 metrics per pod
> - -how many pods- 239 promgen pods (prometheus generator)
> - verify metrics definition count
> - verify metrics data
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (HAWKULARQE-73) Rebuild internal cluster 2
by viet nguyen (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-73?page=com.atlassian.jira.plu... ]
viet nguyen updated HAWKULARQE-73:
----------------------------------
Description:
Use cluster2 (JON BC hardware) for a larger set up than OS1.
- Rebuild cluster. Both master and node are on bare metal
- 30 metrics per pod
- -how many pods- 239 promgen (prometheus generator)
- verify metrics definition count
- verify metrics data
was:
Use cluster2 (JON BC hardware) for a larger set up than OS1.
- Rebuild cluster. Both master and node are on bare metal
- 30 metrics per pod
- how many pods
- verify metrics definition count
- verify metrics data
> Rebuild internal cluster 2
> ---------------------------
>
> Key: HAWKULARQE-73
> URL: https://issues.jboss.org/browse/HAWKULARQE-73
> Project: Hawkular QE
> Issue Type: Sub-task
> Reporter: viet nguyen
> Assignee: viet nguyen
>
> Use cluster2 (JON BC hardware) for a larger set up than OS1.
> - Rebuild cluster. Both master and node are on bare metal
> - 30 metrics per pod
> - -how many pods- 239 promgen (prometheus generator)
> - verify metrics definition count
> - verify metrics data
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1031) Make the CredentialStore class final
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1031:
-------------------------------------
Summary: Make the CredentialStore class final
Key: ELY-1031
URL: https://issues.jboss.org/browse/ELY-1031
Project: WildFly Elytron
Issue Type: Enhancement
Components: Credential Store
Reporter: Darran Lofthouse
Assignee: Peter Skopek
Priority: Critical
Fix For: 1.1.0.Beta34
Unless there is a reason this has not already be done the class should probably be made final to be sure extension is not possible.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1030:
-------------------------------------
Summary: Move TokenSecurityRealm to org.wildfly.security.auth.realm package
Key: ELY-1030
URL: https://issues.jboss.org/browse/ELY-1030
Project: WildFly Elytron
Issue Type: Enhancement
Components: Realms
Reporter: Darran Lofthouse
Assignee: Pedro Igor
Priority: Critical
Fix For: 1.1.0.Beta34
The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1030) Move TokenSecurityRealm to org.wildfly.security.auth.realm package
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1030?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1030:
---------------------------------------
[~pcraveiro] Could you please take a look at this one? As the realm is simple I am not sure it required it's own package.
> Move TokenSecurityRealm to org.wildfly.security.auth.realm package
> ------------------------------------------------------------------
>
> Key: ELY-1030
> URL: https://issues.jboss.org/browse/ELY-1030
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Realms
> Reporter: Darran Lofthouse
> Assignee: Pedro Igor
> Priority: Critical
> Fix For: 1.1.0.Beta34
>
>
> The LDAP and JDBC realms have their own package as they have quite a few utility and configuration classes, the token realm only has one so I don't think we really need this one to be in it'own realm.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1029) Support clients that provide an optional CallbackHandler
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1029:
-------------------------------------
Summary: Support clients that provide an optional CallbackHandler
Key: ELY-1029
URL: https://issues.jboss.org/browse/ELY-1029
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Client
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 1.1.0.Beta34
Clients such as the WildFly CLI provide a CallbackHandler implementation in case it is needed and not as a sign that it must be used, i.e. the desired outcome is that if the information required can be obtained from the configuration then authentication proceeds without interaction with the end user.
Neither the CLI or the end user should be required to be fully aware of the underlying security configuration.
This is similar to web browser HTTP authentication where there is only an interaction with the user if actually required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code
by István Tóth (JIRA)
[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ]
István Tóth commented on WFLY-8431:
-----------------------------------
I have sent a PR for the JBossAuthConfigFactory problem as well.
https://github.com/picketbox/picketbox/pull/68
> Race conditions in JASPIC registration code
> -------------------------------------------
>
> Key: WFLY-8431
> URL: https://issues.jboss.org/browse/WFLY-8431
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Centos 7 x86_64, with the included Java 8 environment
> Reporter: István Tóth
> Assignee: Darran Lofthouse
> Attachments: GetFactoryTestCase.java
>
>
> javax.security.auth.message.config.AuthConfigFactory and
> org.jboss.security.auth.message.config.JBossAuthConfigFactory
> have race conditions.
> 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic.
> I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized)
> 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe.
> Nearly all methods of this class manipulate these, without any synchronization.
> In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty.
> The methods that modify the maps should also be made synchronized, or rewritten to use the
> atomic ConcurrentHashMaps operations.
> A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month