October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-972) Install maistra job fails because of existing resources for registry puller

by Filip Brychta (Jira)

Filip Brychta created SWSQE-972: ----------------------------------- Summary: Install maistra job fails because of existing resources for registry puller Key: SWSQE-972 URL: https://issues.jboss.org/browse/SWSQE-972 Project: Kiali QE Issue Type: Bug Reporter: Filip Brychta Assignee: Filip Brychta Error from server (AlreadyExists): error when creating "src/****files/templates/olm/custom/registryPuller.yaml": clusterroles.rbac.authorization.k8s.io "registry-puller" already exists Error from server (AlreadyExists): error when creating "src/****files/templates/olm/custom/registryPuller.yaml": clusterrolebindings.rbac.authorization.k8s.io "registry-puller" already -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-241) scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable

by Martin Simka (Jira)

[ https://issues.jboss.org/browse/WFWIP-241?page=com.atlassian.jira.plugin.... ] Martin Simka updated WFWIP-241: ------------------------------- Description: While testing tx recovery in OpenShift I see that scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction *testTxStatelessServerSecondPrepareJvmHaltScaleDownClient* Test workflow: - ejb server XA resource crashes JVM on tx-server pod - label "{{wildfly.org/operated-by-headless}}" of server pod is changed, which causes that server isn't reachable - tx-server pod is scaled down - tx-client pod is scaled down *scale down of client pod hangs* {noformat} {"level":"info","ts":1570636701.0314589,"logger":"wildflyserver_controller","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} {"level":"info","ts":1570636701.0314867,"logger":"wildflyserver_controller","msg":"Statefulset was not scaled to the desired replica size 0 (current StatefulSet size: 1). Transaction recovery scaledown process has not cleaned all pods. Please, check status of the WildflyServer tx-client","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} {"level":"info","ts":1570636703.5918324,"logger":"wildflyserver_controller","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-client"} {"level":"info","ts":1570636703.5919785,"logger":"wildlfyserver_resources","msg":"Getting resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} {"level":"info","ts":1570636703.5920458,"logger":"wildlfyserver_resources","msg":"Got resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} {"level":"info","ts":1570636703.5921679,"logger":"wildflyserver_controller","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","IP Address":"10.128.1.34","Pod State":"SCALING_DOWN_RECOVERY_DIRTY","Pod Phase":"Running"} {"level":"info","ts":1570636703.5922475,"logger":"wildflyserver_controller","msg":"Recovery properties at pod were already defined. Skipping server restart.","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0"} {"level":"info","ts":1570636703.5971646,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} {"level":"info","ts":1570636709.162107,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} {"level":"info","ts":1570636714.7187033,"logger":"wildflyserver_controller","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","Message":"WildFly Transaction Client data dir is not empty and scaling down of the pod 'tx-client-0' will be retried.Wildfly Transacton Client data dir path '/opt/eap/standalone/data/ejb-xa-recovery', output listing: 20005_00000000000000000000ffff0a80012251f788695d9e026b0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n"} {noformat} was: While testing tx recovery in OpenShift I see that scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction *testTxStatelessServerSecondPrepareJvmHaltScaleDownClient* What test does is: - ejb server XA resource crashes JVM on tx-server pod - label "{{wildfly.org/operated-by-headless}}" of server pod is changed, which causes that server isn't reachable - tx-server pod is scaled down - tx-client pod is scaled down *scale down of client pod hangs* {noformat} {"level":"info","ts":1570636701.0314589,"logger":"wildflyserver_controller","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} {"level":"info","ts":1570636701.0314867,"logger":"wildflyserver_controller","msg":"Statefulset was not scaled to the desired replica size 0 (current StatefulSet size: 1). Transaction recovery scaledown process has not cleaned all pods. Please, check status of the WildflyServer tx-client","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} {"level":"info","ts":1570636703.5918324,"logger":"wildflyserver_controller","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-client"} {"level":"info","ts":1570636703.5919785,"logger":"wildlfyserver_resources","msg":"Getting resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} {"level":"info","ts":1570636703.5920458,"logger":"wildlfyserver_resources","msg":"Got resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} {"level":"info","ts":1570636703.5921679,"logger":"wildflyserver_controller","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","IP Address":"10.128.1.34","Pod State":"SCALING_DOWN_RECOVERY_DIRTY","Pod Phase":"Running"} {"level":"info","ts":1570636703.5922475,"logger":"wildflyserver_controller","msg":"Recovery properties at pod were already defined. Skipping server restart.","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0"} {"level":"info","ts":1570636703.5971646,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} {"level":"info","ts":1570636709.162107,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} {"level":"info","ts":1570636714.7187033,"logger":"wildflyserver_controller","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","Message":"WildFly Transaction Client data dir is not empty and scaling down of the pod 'tx-client-0' will be retried.Wildfly Transacton Client data dir path '/opt/eap/standalone/data/ejb-xa-recovery', output listing: 20005_00000000000000000000ffff0a80012251f788695d9e026b0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n"} {noformat} > scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFWIP-241 > URL: https://issues.jboss.org/browse/WFWIP-241 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Major > Labels: operator > > While testing tx recovery in OpenShift I see that scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondPrepareJvmHaltScaleDownClient* > Test workflow: > - ejb server XA resource crashes JVM on tx-server pod > - label "{{wildfly.org/operated-by-headless}}" of server pod is changed, which causes that server isn't reachable > - tx-server pod is scaled down > - tx-client pod is scaled down > *scale down of client pod hangs* > {noformat} > {"level":"info","ts":1570636701.0314589,"logger":"wildflyserver_controller","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} > {"level":"info","ts":1570636701.0314867,"logger":"wildflyserver_controller","msg":"Statefulset was not scaled to the desired replica size 0 (current StatefulSet size: 1). Transaction recovery scaledown process has not cleaned all pods. Please, check status of the WildflyServer tx-client","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} > {"level":"info","ts":1570636703.5918324,"logger":"wildflyserver_controller","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-client"} > {"level":"info","ts":1570636703.5919785,"logger":"wildlfyserver_resources","msg":"Getting resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} > {"level":"info","ts":1570636703.5920458,"logger":"wildlfyserver_resources","msg":"Got resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} > {"level":"info","ts":1570636703.5921679,"logger":"wildflyserver_controller","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","IP Address":"10.128.1.34","Pod State":"SCALING_DOWN_RECOVERY_DIRTY","Pod Phase":"Running"} > {"level":"info","ts":1570636703.5922475,"logger":"wildflyserver_controller","msg":"Recovery properties at pod were already defined. Skipping server restart.","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0"} > {"level":"info","ts":1570636703.5971646,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} > {"level":"info","ts":1570636709.162107,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} > {"level":"info","ts":1570636714.7187033,"logger":"wildflyserver_controller","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","Message":"WildFly Transaction Client data dir is not empty and scaling down of the pod 'tx-client-0' will be retried.Wildfly Transacton Client data dir path '/opt/eap/standalone/data/ejb-xa-recovery', output listing: 20005_00000000000000000000ffff0a80012251f788695d9e026b0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n"} > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-241) scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable

by Martin Simka (Jira)

Martin Simka created WFWIP-241: ---------------------------------- Summary: scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable Key: WFWIP-241 URL: https://issues.jboss.org/browse/WFWIP-241 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Martin Simka Assignee: Ondrej Chaloupka While testing tx recovery in OpenShift I see that scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction *testTxStatelessServerSecondPrepareJvmHaltScaleDownClient* What test does is: - ejb server XA resource crashes JVM on tx-server pod - label "{{wildfly.org/operated-by-headless}}" of server pod is changed, which causes that server isn't reachable - tx-server pod is scaled down - tx-client pod is scaled down *scale down of client pod hangs* {noformat} {"level":"info","ts":1570636701.0314589,"logger":"wildflyserver_controller","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} {"level":"info","ts":1570636701.0314867,"logger":"wildflyserver_controller","msg":"Statefulset was not scaled to the desired replica size 0 (current StatefulSet size: 1). Transaction recovery scaledown process has not cleaned all pods. Please, check status of the WildflyServer tx-client","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"} {"level":"info","ts":1570636703.5918324,"logger":"wildflyserver_controller","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-client"} {"level":"info","ts":1570636703.5919785,"logger":"wildlfyserver_resources","msg":"Getting resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} {"level":"info","ts":1570636703.5920458,"logger":"wildlfyserver_resources","msg":"Got resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"} {"level":"info","ts":1570636703.5921679,"logger":"wildflyserver_controller","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","IP Address":"10.128.1.34","Pod State":"SCALING_DOWN_RECOVERY_DIRTY","Pod Phase":"Running"} {"level":"info","ts":1570636703.5922475,"logger":"wildflyserver_controller","msg":"Recovery properties at pod were already defined. Skipping server restart.","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0"} {"level":"info","ts":1570636703.5971646,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} {"level":"info","ts":1570636709.162107,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712} {"level":"info","ts":1570636714.7187033,"logger":"wildflyserver_controller","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","Message":"WildFly Transaction Client data dir is not empty and scaling down of the pod 'tx-client-0' will be retried.Wildfly Transacton Client data dir path '/opt/eap/standalone/data/ejb-xa-recovery', output listing: 20005_00000000000000000000ffff0a80012251f788695d9e026b0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n"} {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4603) Scenario test: CSS support for "add an expression-based value" design implementation.

by Sarah Rambacher (Jira)

[ https://issues.jboss.org/browse/DROOLS-4603?page=com.atlassian.jira.plugi... ] Sarah Rambacher updated DROOLS-4603: ------------------------------------ Story Points: 3 (was: 2) > Scenario test: CSS support for "add an expression-based value" design implementation. > -------------------------------------------------------------------------------------- > > Key: DROOLS-4603 > URL: https://issues.jboss.org/browse/DROOLS-4603 > Project: Drools > Issue Type: Story > Components: Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Sarah Rambacher > Priority: Major > Labels: UX, UXTeam > Attachments: Screen Shot 2019-10-01 at 8.27.30 AM.png, long_value.gif > > > Test scenario implementation needs updates to support this new design/feature. Changes are outlined at: https://docs.google.com/presentation/d/1bHs9ZAbHAnV-cK9LQE6uJ38ZEIHR_QrfV... and in the referenced click-thru. > User story: As a technical/advanced user (Cameron), I want to be able to input expression-based values in scenario given/expect row cells, so that I can define inputs for complex objects and logic. > Note: Syntax highlighting etc. and checkbox inputs are out of scope. Refer to: https://issues.jboss.org/browse/DROOLS-3514 > *Verification conditions* > Team would like CSS for the following: > - updated CSS for the right panel that reflects the changes in the document. ^^ > - updated List dialog CSS to reflect design additions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4603) Scenario test: CSS support for "add an expression-based value" design implementation.

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-4603?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-4603: -------------------------------------- Description: Test scenario implementation needs updates to support this new design/feature. Changes are outlined at: https://docs.google.com/presentation/d/1bHs9ZAbHAnV-cK9LQE6uJ38ZEIHR_QrfV... and in the referenced click-thru. User story: As a technical/advanced user (Cameron), I want to be able to input expression-based values in scenario given/expect row cells, so that I can define inputs for complex objects and logic. Note: Syntax highlighting etc. and checkbox inputs are out of scope. Refer to: https://issues.jboss.org/browse/DROOLS-3514 *Verification conditions* Team would like CSS for the following: - updated CSS for the right panel that reflects the changes in the document. ^^ - updated List dialog CSS to reflect design additions. was: Test scenario implementation needs updates to support this new design/feature. Changes are outlined at: https://docs.google.com/presentation/d/1bHs9ZAbHAnV-cK9LQE6uJ38ZEIHR_QrfV... and in the referenced click-thru. User story: As a technical/advanced user (Cameron), I want to be able to input expression-based values in scenario given/expect row cells, so that I can define inputs for complex objects and logic. Note: Syntax highlighting etc. and checkbox inputs are out of scope. Refer to: https://issues.jboss.org/browse/DROOLS-3514 > Scenario test: CSS support for "add an expression-based value" design implementation. > -------------------------------------------------------------------------------------- > > Key: DROOLS-4603 > URL: https://issues.jboss.org/browse/DROOLS-4603 > Project: Drools > Issue Type: Story > Components: Scenario Simulation and Testing > Reporter: Elizabeth Clayton > Assignee: Sarah Rambacher > Priority: Major > Labels: UX, UXTeam > Attachments: Screen Shot 2019-10-01 at 8.27.30 AM.png, long_value.gif > > > Test scenario implementation needs updates to support this new design/feature. Changes are outlined at: https://docs.google.com/presentation/d/1bHs9ZAbHAnV-cK9LQE6uJ38ZEIHR_QrfV... and in the referenced click-thru. > User story: As a technical/advanced user (Cameron), I want to be able to input expression-based values in scenario given/expect row cells, so that I can define inputs for complex objects and logic. > Note: Syntax highlighting etc. and checkbox inputs are out of scope. Refer to: https://issues.jboss.org/browse/DROOLS-3514 > *Verification conditions* > Team would like CSS for the following: > - updated CSS for the right panel that reflects the changes in the document. ^^ > - updated List dialog CSS to reflect design additions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-238) SSO support should have dual security

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-238?page=com.atlassian.jira.plugin.... ] Jean Francois Denise commented on WFWIP-238: -------------------------------------------- Ok, good point, I buy it. > SSO support should have dual security > ------------------------------------- > > Key: WFWIP-238 > URL: https://issues.jboss.org/browse/WFWIP-238 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Currently SSO configuration uses elytron, it is a change with prior configuration. > SSO support should detect if security subsystem is present and use it. Elytron being used only if legacy security subsystem is not there. > This offers a backward compatible configuration. > Obviously this should be tuned in order to "modernize" the configuration by using elytron in all cases. That is made possible using the SSO_FORCE_ELYTRON_SECURITY=true. > That is what WildFly s2i is using by default. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-971) Checker script is not checking istio pods correctly

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-971?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-971: ------------------------------------- https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/commit/... > Checker script is not checking istio pods correctly > --------------------------------------------------- > > Key: SWSQE-971 > URL: https://issues.jboss.org/browse/SWSQE-971 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Sometimes it just checks that 2 pods are running and continuing not waiting for all pods to be up: > Validating that Istio status in namespace "istio-system" > Verifying that "istio-system" namespace exists... > Istio "istio-system" namespace exists. > Now using project "istio-system" on server "https://api.ocp4-kqe-auto1.maistra.upshift.redhat.com:6443". > Verifying status of istio_installer pod in namespace "istio-system".. > Installer pod does not exist. > Varifying status of istio pods in namespace "istio-system".. > Pod: istio-citadel-77bbdd86d7-twvfc Status: ContainerCreating > Waiting for all pods to be in Running status.. > Pod: istio-citadel-77bbdd86d7-twvfc Status: Running > Pod: prometheus-76596b5c54-65cwq Status: ContainerCreating > Waiting for all pods to be in Running status.. > Pod: istio-citadel-77bbdd86d7-twvfc Status: Running > Pod: prometheus-76596b5c54-65cwq Status: ContainerCreating > Waiting for all pods to be in Running status.. > Pod: istio-citadel-77bbdd86d7-twvfc Status: Running > Pod: prometheus-76596b5c54-65cwq Status: Running > All Istio pods are in Running status.. Istio is deployed successfully.. > Validating that Kialki is up in namespace "istio-system" > Verifying that Kiali pod is running and Kiali is browsable in namespace "istio-system".. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4629) DMN heuristic for invocation name

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-4629?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-4629: ----------------------------------- Sprint: 2019 Week 41-43 (from Okt 7) > DMN heuristic for invocation name > --------------------------------- > > Key: DROOLS-4629 > URL: https://issues.jboss.org/browse/DROOLS-4629 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Minor > > Ref https://issues.jboss.org/browse/RHDM-980?focusedCommentId=13796841&page=c... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-238) SSO support should have dual security

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFWIP-238?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFWIP-238: ---------------------------------------- Wouldn't it be better to have the configuration option the other way round i.e. SSO_FORCE_LEGACY_SECURITY=true with this present by default? In the future once legacy security is removed the only real step required will be removing this option. > SSO support should have dual security > ------------------------------------- > > Key: WFWIP-238 > URL: https://issues.jboss.org/browse/WFWIP-238 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Currently SSO configuration uses elytron, it is a change with prior configuration. > SSO support should detect if security subsystem is present and use it. Elytron being used only if legacy security subsystem is not there. > This offers a backward compatible configuration. > Obviously this should be tuned in order to "modernize" the configuration by using elytron in all cases. That is made possible using the SSO_FORCE_ELYTRON_SECURITY=true. > That is what WildFly s2i is using by default. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-971) Checker script is not checking istio pods correctly

by Filip Brychta (Jira)

Filip Brychta created SWSQE-971: ----------------------------------- Summary: Checker script is not checking istio pods correctly Key: SWSQE-971 URL: https://issues.jboss.org/browse/SWSQE-971 Project: Kiali QE Issue Type: Bug Reporter: Filip Brychta Assignee: Filip Brychta Sometimes it just checks that 2 pods are running and continuing not waiting for all pods to be up: Validating that Istio status in namespace "istio-system" Verifying that "istio-system" namespace exists... Istio "istio-system" namespace exists. Now using project "istio-system" on server "https://api.ocp4-kqe-auto1.maistra.upshift.redhat.com:6443". Verifying status of istio_installer pod in namespace "istio-system".. Installer pod does not exist. Varifying status of istio pods in namespace "istio-system".. Pod: istio-citadel-77bbdd86d7-twvfc Status: ContainerCreating Waiting for all pods to be in Running status.. Pod: istio-citadel-77bbdd86d7-twvfc Status: Running Pod: prometheus-76596b5c54-65cwq Status: ContainerCreating Waiting for all pods to be in Running status.. Pod: istio-citadel-77bbdd86d7-twvfc Status: Running Pod: prometheus-76596b5c54-65cwq Status: ContainerCreating Waiting for all pods to be in Running status.. Pod: istio-citadel-77bbdd86d7-twvfc Status: Running Pod: prometheus-76596b5c54-65cwq Status: Running All Istio pods are in Running status.. Istio is deployed successfully.. Validating that Kialki is up in namespace "istio-system" Verifying that Kiali pod is running and Kiali is browsable in namespace "istio-system".. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019