[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-5103:
-------------------------------------
Fix Version/s: 13.0.0.Beta6
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-5103:
-------------------------------------
Priority: Blocker (was: Critical)
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Jean Francois Denise (Jira)
Jean Francois Denise created WFCORE-5103:
--------------------------------------------
Summary: Adding non existent and not required keystore fails
Key: WFCORE-5103
URL: https://issues.redhat.com/browse/WFCORE-5103
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Jean Francois Denise
Assignee: Darran Lofthouse
We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
/subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
Error:
"failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
[ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13759) Intermittent failure in ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13759?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13759:
------------------------------
Description:
According to [https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...] in the last month there have been 9 failures of ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement with this failure:
{code:java}
java.lang.AssertionError
at deployment.arquillian-service//org.junit.Assert.fail(Assert.java:86)
at deployment.arquillian-service//org.junit.Assert.assertTrue(Assert.java:41)
at deployment.arquillian-service//org.junit.Assert.assertTrue(Assert.java:52)
at deployment.ManagedExecutorServiceMetricsTestCase.jar//org.jboss.as.test.integration.ee.concurrent.ManagedExecutorServiceMetricsTestCase.testRuntimeStats(ManagedExecutorServiceMetricsTestCase.java:238)
at deployment.ManagedExecutorServiceMetricsTestCase.jar//org.jboss.as.test.integration.ee.concurrent.ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement(ManagedExecutorServiceMetricsTestCase.java:108)
{code}
First failure was reported against [https://github.com/wildfly/wildfly/pull/13414] but that was a docs only change so not relevant. It occurred on July 17 but there weren't any merge commits to master in the period between Jul 12 and Jul 20 so any change in master causing this isn't obvious.
The failure is because the test checks that the # of active threads is 0 immediately after it does some activity, so it may just be a timing issue that's always been possible and just started happening recently for env reason on ci.wildfly.org.
A general comment is this test would be better if its asserts reported more info about what it read from the server. Use assertEquals and report the expected and wrong value.
was:
According to https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=... in the last month there have been 5 failures of ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement with this failure:
{code}
java.lang.AssertionError
at deployment.arquillian-service//org.junit.Assert.fail(Assert.java:86)
at deployment.arquillian-service//org.junit.Assert.assertTrue(Assert.java:41)
at deployment.arquillian-service//org.junit.Assert.assertTrue(Assert.java:52)
at deployment.ManagedExecutorServiceMetricsTestCase.jar//org.jboss.as.test.integration.ee.concurrent.ManagedExecutorServiceMetricsTestCase.testRuntimeStats(ManagedExecutorServiceMetricsTestCase.java:238)
at deployment.ManagedExecutorServiceMetricsTestCase.jar//org.jboss.as.test.integration.ee.concurrent.ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement(ManagedExecutorServiceMetricsTestCase.java:108)
{code}
First failure was reported against https://github.com/wildfly/wildfly/pull/13414 but that was a docs only change so not relevant. It occurred on July 17 but there weren't any merge commits to master in the period between Jul 12 and Jul 20 so any change in master causing this isn't obvious.
The failure is because the test checks that the # of active threads is 0 immediately after it does some activity, so it may just be a timing issue that's always been possible and just started happening recently for env reason on ci.wildfly.org.
A general comment is this test would be better if its asserts reported more info about what it read from the server. Use assertEquals and report the expected and wrong value.
> Intermittent failure in ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-13759
> URL: https://issues.redhat.com/browse/WFLY-13759
> Project: WildFly
> Issue Type: Bug
> Components: Concurrency Utilities
> Reporter: Brian Stansberry
> Assignee: Eduardo Martins
> Priority: Minor
>
> According to [https://ci.wildfly.org/project.html?projectId=WF_PullRequest&buildTypeId=...] in the last month there have been 9 failures of ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement with this failure:
> {code:java}
> java.lang.AssertionError
> at deployment.arquillian-service//org.junit.Assert.fail(Assert.java:86)
> at deployment.arquillian-service//org.junit.Assert.assertTrue(Assert.java:41)
> at deployment.arquillian-service//org.junit.Assert.assertTrue(Assert.java:52)
> at deployment.ManagedExecutorServiceMetricsTestCase.jar//org.jboss.as.test.integration.ee.concurrent.ManagedExecutorServiceMetricsTestCase.testRuntimeStats(ManagedExecutorServiceMetricsTestCase.java:238)
> at deployment.ManagedExecutorServiceMetricsTestCase.jar//org.jboss.as.test.integration.ee.concurrent.ManagedExecutorServiceMetricsTestCase.testManagedExecutorServiceManagement(ManagedExecutorServiceMetricsTestCase.java:108)
> {code}
> First failure was reported against [https://github.com/wildfly/wildfly/pull/13414] but that was a docs only change so not relevant. It occurred on July 17 but there weren't any merge commits to master in the period between Jul 12 and Jul 20 so any change in master causing this isn't obvious.
> The failure is because the test checks that the # of active threads is 0 immediately after it does some activity, so it may just be a timing issue that's always been possible and just started happening recently for env reason on ci.wildfly.org.
> A general comment is this test would be better if its asserts reported more info about what it read from the server. Use assertEquals and report the expected and wrong value.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (SWSQE-1207) UI Automations - Fix failure tests because of filter
by Hayk Hovsepyan (Jira)
Hayk Hovsepyan created SWSQE-1207:
-------------------------------------
Summary: UI Automations - Fix failure tests because of filter
Key: SWSQE-1207
URL: https://issues.redhat.com/browse/SWSQE-1207
Project: Kiali QE
Issue Type: QE Task
Reporter: Hayk Hovsepyan
Assignee: Hayk Hovsepyan
kiali_qe.tests.test_services_page.test_filter_service_by_or_label kiali_qe.tests.test_services_page.test_filter_service_by_and_label kiali_qe.tests.test_applications_page.test_filter_applications_by_and_label
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-12356) remoting subsystem's http-connector is missing capability reference
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-12356?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty updated WFLY-12356:
---------------------------------------
Comment: was deleted
(was: A comment with security level 'Red Hat Employee' was removed.)
> remoting subsystem's http-connector is missing capability reference
> -------------------------------------------------------------------
>
> Key: WFLY-12356
> URL: https://issues.redhat.com/browse/WFLY-12356
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 17.0.1.Final
> Reporter: Radoslav Husar
> Assignee: Ranabir Chakraborty
> Priority: Major
> Labels: ux
>
> http-remoting-connector is missing capability reference to the undertow connector.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=connector-ref,value=foo)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
> results in a cryptic error
> {noformat}
> 11:33:01,792 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings, service org.wildfly.ejb.remote]
> WFLYCTL0448: 5 additional services are down due to their dependencies being missing or failed
> 11:33:15,334 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
> WFLYCTL0185: Newly corrected services:
> service jboss.ejb.association (new available)
> service jboss.ejb.remoting.connector.client-mappings (new available)
> service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (no longer required)
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (new available)
> service org.wildfly.clustering.cache.registry-factory.ejb.client-mappings (new available)
> service org.wildfly.clustering.group.ejb (new available)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFWIP-334) Bootable JAR - Cloud - Support for dns.DNS_PING
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-334?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-334:
--------------------------------------------
[~mchoma], that could be a first step. User would enable cloud that enables KUBE_PING and apply this kind of script:
if (outcome == success) of /subsystem=jgroups/stack=tcp/protocol=kubernetes.KUBE_PING:read-resource
/subsystem=jgroups/stack=tcp/protocol=kubernetes.KUBE_PING:remove
end-if
if (outcome == success) of /subsystem=jgroups/stack=tcp:read-resource
/subsystem=jgroups/stack=tcp/protocol=dns.DNS_PING:add(add-index=0)
/subsystem=jgroups/stack=tcp/protocol=dns.DNS_PING/property=dns_query:add(value=${env.DNS_PING_SERVICE_NAME})
/subsystem=jgroups/stack=tcp/protocol=dns.DNS_PING/property=async_discovery_use_separate_thread_per_request:add(value=true)
end-if
The user would name the env variable to set the ping service freely (eg: DNS_PING_SERVICE_NAME).
> Bootable JAR - Cloud - Support for dns.DNS_PING
> -----------------------------------------------
>
> Key: WFWIP-334
> URL: https://issues.redhat.com/browse/WFWIP-334
> Project: WildFly WIP
> Issue Type: Feature Request
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> Currently kubernetes.KUBE_PING is the protocol in use when cloud is enabled.
> KUBE_PING, although requiring an Openshift permission, is the simpler configuration wise (just need KUBERNETES namespace and your are done).
> DNS_PING doesn't require the extra permission but requires a new service (to expose the port 8888 in the pod) to be created.
> I propose that we keep KUBE_PING as the default protocol and extend the cloud element with a <ping-protocol>kubernetes.KUBE_PING|dns.DNS_PING</ping-protocol> element.
> The env variable used to set the service name is the same as EAP/XP S2I builder image: OPENSHIFT_DNS_PING_SERVICE_NAME
> web-clustering example will be evolved with a profile to support DNS_PING (and also to contain a yaml example file of the ping service).
> [~luck3y], [~mchoma], [~brian.stansberry] [~fburzigo] that is the proposal to also cover DNS_PING.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFWIP-334) Bootable JAR - Cloud - Support for dns.DNS_PING
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-334?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFWIP-334:
------------------------------------
There is lot of environment properties in s2i which are related to configuring clustering (~10) . [1]
If I understand correctly what you are suggesting here is add support for one of them {{JGROUPS_PING_PROTOCOL}}. But that leaves us with 10 other properties where customer need to leverage custom CLI anyway. My point is if it so helpful for user - I assume it is just changing one value in model?
{code}
OPENSHIFT_KUBE_PING_*
OPENSHIFT_DNS_PING_*
JGROUPS_*
{code}
My feeling from yesterdays meeting was design purpose is to keep <cloud> logic as small as possible.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
> Bootable JAR - Cloud - Support for dns.DNS_PING
> -----------------------------------------------
>
> Key: WFWIP-334
> URL: https://issues.redhat.com/browse/WFWIP-334
> Project: WildFly WIP
> Issue Type: Feature Request
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> Currently kubernetes.KUBE_PING is the protocol in use when cloud is enabled.
> KUBE_PING, although requiring an Openshift permission, is the simpler configuration wise (just need KUBERNETES namespace and your are done).
> DNS_PING doesn't require the extra permission but requires a new service (to expose the port 8888 in the pod) to be created.
> I propose that we keep KUBE_PING as the default protocol and extend the cloud element with a <ping-protocol>kubernetes.KUBE_PING|dns.DNS_PING</ping-protocol> element.
> The env variable used to set the service name is the same as EAP/XP S2I builder image: OPENSHIFT_DNS_PING_SERVICE_NAME
> web-clustering example will be evolved with a profile to support DNS_PING (and also to contain a yaml example file of the ping service).
> [~luck3y], [~mchoma], [~brian.stansberry] [~fburzigo] that is the proposal to also cover DNS_PING.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months