[JBoss JIRA] (ELY-1953) Elytron tool command execution fails with java.nio.file.NoSuchFileException
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1953?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated ELY-1953:
----------------------------------
Fix Version/s: 1.12.0.CR1
> Elytron tool command execution fails with java.nio.file.NoSuchFileException
> ----------------------------------------------------------------------------
>
> Key: ELY-1953
> URL: https://issues.redhat.com/browse/ELY-1953
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool
> Affects Versions: 1.11.3.Final
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Blocker
> Labels: regression
> Fix For: 1.12.0.CR1
>
>
> This is a regression in behavior of *elytron-tool.sh* with respect to 7.3.0.GA-CR4.
> Basically, it was noticed that some commands involving a custom credential store returned a exit code of *0* and no error when executed against 7.3.0.GA-CR4 distribution, while the same commands are failing with various error codes against 7.4.0.CD19-CR1.
> See _Steps to Reproduce_ for an example.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ELY-1945) Authentication vulnerable to session fixation attacks
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1945?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on ELY-1945:
---------------------------------------
[~mark.banierink] Would you like to be acknowledged on the CVE raised as a result of this issue? If so can you please confirm how you would like your name represented and any relevant affiliation.
> Authentication vulnerable to session fixation attacks
> -----------------------------------------------------
>
> Key: ELY-1945
> URL: https://issues.redhat.com/browse/ELY-1945
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Mark Banierink
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.6.7.Final, 1.11.4.Final
>
>
> The session id is not changed upon authentication. This creates a vulnerability to session fixation attacks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFCORE-4951) (7.3.z) Regression: Legacy Ldap Realm securing EJB with JDK8 not working
by Ilia Vassilev (Jira)
Ilia Vassilev created WFCORE-4951:
-------------------------------------
Summary: (7.3.z) Regression: Legacy Ldap Realm securing EJB with JDK8 not working
Key: WFCORE-4951
URL: https://issues.redhat.com/browse/WFCORE-4951
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 12.0.0.Beta1
Reporter: Ilia Vassilev
Assignee: Ricardo Martin Camarero
WFCORE issue related to JBEAP-19195. The root exception is the following:
{noformat}
javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]]
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:272)
at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:184)
at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:180)
at org.jboss.as.domain.management.security.LdapConnectionHandler.getConnection(LdapConnectionHandler.java:78)
at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:232)
at org.jboss.as.domain.management.security.UserLdapCallbackHandler$SecurityRealmImpl.getRealmIdentity(UserLdapCallbackHandler.java:339)
at org.jboss.as.domain.management.security.SecurityRealmService$SharedStateSecurityRealm.getRealmIdentity(SecurityRealmService.java:776)
at org.wildfly.security.auth.server.ServerAuthenticationContext.assignName(ServerAuthenticationContext.java:1197)
at org.wildfly.security.auth.server.ServerAuthenticationContext$UnassignedState.setPrincipal(ServerAuthenticationContext.java:1726)
at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationPrincipal(ServerAuthenticationContext.java:410)
at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:384)
at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:368)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:912)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:853)
at org.wildfly.security.auth.callback.SocketAddressQueryCallbackHandler.handle(SocketAddressQueryCallbackHandler.java:57)
at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:105)
at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:118)
at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:110)
at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:484)
at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115)
... 40 more
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5280:
----------------------------------------
Side note: the "Add" expression as originally expressed might have worked on our DMN engine in version v1.2 and priors, because the DMN specification was very vague in the scenario for which singleton list was to be automatically converted, and we made our engine very flexible to accomodate several possible cases. However, with DMN v1.3 the DMN specification clarified explicitly the context were automatic coercion of singleton list can happen, and our engine with regards to ambiguities follows the latest DMN specification releases.
> List Filter expression returning single item and nested within arithmetic expression fails to evaluate
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5280
> URL: https://issues.redhat.com/browse/DROOLS-5280
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.34.0.Final, 7.36.0.Final
> Reporter: Tracy Hires
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Description:
We are experiencing cluster is not formed in one of our tests [1] with XP image [2]. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
was:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image [2]. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Description:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} this log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
was:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} this log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-not-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} this log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Steps to Reproduce: (was: {code}mvn test -Pxp,operator -Dxtf.test_properties.path=test.properties.os-ocp42 -Dtest=OperatorKubePingTest{code})
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} this log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months