August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-940) Update jenkins jobs to use new istio operator name

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-940?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-940. --------------------------------- Resolution: Done https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/commit/... > Update jenkins jobs to use new istio operator name > -------------------------------------------------- > > Key: SWSQE-940 > URL: https://issues.jboss.org/browse/SWSQE-940 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Istio operator image was renamed on quay from istio-operator-rhel8 to istio-rhel8-operator and from istio-operator-ubi8 to istio-ubi8-operator > We need to update jenkins jobs -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12407) Support for https in galleon layers

by Jean Francois Denise (Jira)

Jean Francois Denise created WFLY-12407: ------------------------------------------- Summary: Support for https in galleon layers Key: WFLY-12407 URL: https://issues.jboss.org/browse/WFLY-12407 Project: WildFly Issue Type: Enhancement Components: Build System Reporter: Jean Francois Denise Assignee: Jean Francois Denise When building a configuration with galleon layers we need a way to evolve undertow with a support for https. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-176) Pod restarted because of failing liveness/rediness Probe

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-176?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFWIP-176: ------------------------------- Affects: Documentation (Ref Guide, User Guide, etc.),Release Notes (was: Release Notes) > Pod restarted because of failing liveness/rediness Probe > -------------------------------------------------------- > > Key: WFWIP-176 > URL: https://issues.jboss.org/browse/WFWIP-176 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Ken Wills > Priority: Major > > During testing 73 image I came to case where really corner case is tested [0]. > Test is not using templates for deployment. > In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however, there was no liveness/rediness failures in events. Pod was not restarted. > I dont see differences in pod yaml for CD16 case > {code} > livenessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/livenessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > name: weirdusername > readinessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/readinessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > {code} > and CD 17 case > {code} > livenessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/livenessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > name: weirdusername > readinessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/readinessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > {code} > What could cause this behaviour change? > [0] https://issues.jboss.org/browse/CLOUD-1988 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-176) Pod restarted because of failing liveness/rediness Probe

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-176?page=com.atlassian.jira.plugin.... ] Martin Choma updated WFWIP-176: ------------------------------- Affects: Release Notes > Pod restarted because of failing liveness/rediness Probe > -------------------------------------------------------- > > Key: WFWIP-176 > URL: https://issues.jboss.org/browse/WFWIP-176 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Ken Wills > Priority: Major > > During testing 73 image I came to case where really corner case is tested [0]. > Test is not using templates for deployment. > In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however, there was no liveness/rediness failures in events. Pod was not restarted. > I dont see differences in pod yaml for CD16 case > {code} > livenessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/livenessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > name: weirdusername > readinessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/readinessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > {code} > and CD 17 case > {code} > livenessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/livenessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > name: weirdusername > readinessProbe: > exec: > command: > - /bin/bash > - '-c' > - /opt/eap/bin/readinessProbe.sh > failureThreshold: 3 > periodSeconds: 10 > successThreshold: 1 > timeoutSeconds: 1 > {code} > What could cause this behaviour change? > [0] https://issues.jboss.org/browse/CLOUD-1988 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12406) Unignore SharedStoreFailoverTestCase

by Emmanuel Hugonnet (Jira)

Emmanuel Hugonnet created WFLY-12406: ---------------------------------------- Summary: Unignore SharedStoreFailoverTestCase Key: WFLY-12406 URL: https://issues.jboss.org/browse/WFLY-12406 Project: WildFly Issue Type: Task Components: JMS Affects Versions: 18.0.0.Beta1 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4617) jboss-cli.sh does not error on invalid options such as --controler

by Bartosz Spyrko (Jira)

[ https://issues.jboss.org/browse/WFCORE-4617?page=com.atlassian.jira.plugi... ] Bartosz Spyrko commented on WFCORE-4617: ---------------------------------------- Currently any argument that doesn't match accepted parameters is treated as a CLI command. I think it should be safe to assume that an argument that starts with "--" might be a misspelled parameter and display an "Unsupported parameter" error or at least a warning. [~jfdenise] WDYT? > jboss-cli.sh does not error on invalid options such as --controler > ------------------------------------------------------------------ > > Key: WFCORE-4617 > URL: https://issues.jboss.org/browse/WFCORE-4617 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Bartosz Spyrko > Assignee: Bartosz Spyrko > Priority: Minor > > If the --controller is not spelled correctly, the CLI is ignoring it and then trying to connect to the default localhost:9990 in from the jboss-cli.xml. This makes it look like there is a connection error when the actual issue is the option passed to the CLI is not a valid option. > {code} > ./bin/standalone.sh -Djboss.socket.binding.port-offset=9 > {code} > {code} > /bin/jboss-cli.sh --controler=myhost:9999 --connect > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4617) jboss-cli.sh does not error on invalid options such as --controler

by Bartosz Spyrko (Jira)

[ https://issues.jboss.org/browse/WFCORE-4617?page=com.atlassian.jira.plugi... ] Bartosz Spyrko updated WFCORE-4617: ----------------------------------- Component/s: CLI > jboss-cli.sh does not error on invalid options such as --controler > ------------------------------------------------------------------ > > Key: WFCORE-4617 > URL: https://issues.jboss.org/browse/WFCORE-4617 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Bartosz Spyrko > Assignee: Bartosz Spyrko > Priority: Minor > > If the --controller is not spelled correctly, the CLI is ignoring it and then trying to connect to the default localhost:9990 in from the jboss-cli.xml. This makes it look like there is a connection error when the actual issue is the option passed to the CLI is not a valid option. > {code} > ./bin/standalone.sh -Djboss.socket.binding.port-offset=9 > {code} > {code} > /bin/jboss-cli.sh --controler=myhost:9999 --connect > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4617) jboss-cli.sh does not error on invalid options such as --controler

by Bartosz Spyrko (Jira)

[ https://issues.jboss.org/browse/WFCORE-4617?page=com.atlassian.jira.plugi... ] Bartosz Spyrko moved JBEAP-17461 to WFCORE-4617: ------------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4617 (was: JBEAP-17461) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > jboss-cli.sh does not error on invalid options such as --controler > ------------------------------------------------------------------ > > Key: WFCORE-4617 > URL: https://issues.jboss.org/browse/WFCORE-4617 > Project: WildFly Core > Issue Type: Bug > Reporter: Bartosz Spyrko > Assignee: Bartosz Spyrko > Priority: Minor > > If the --controller is not spelled correctly, the CLI is ignoring it and then trying to connect to the default localhost:9990 in from the jboss-cli.xml. This makes it look like there is a connection error when the actual issue is the option passed to the CLI is not a valid option. > {code} > ./bin/standalone.sh -Djboss.socket.binding.port-offset=9 > {code} > {code} > /bin/jboss-cli.sh --controler=myhost:9999 --connect > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4616) Layer for core security-realms and management layer update

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFCORE-4616?page=com.atlassian.jira.plugi... ] Jean Francois Denise updated WFCORE-4616: ----------------------------------------- Description: Such layer would be helpful to extend existing layers with ability to be secured using core security realms. In addition, the management layer should make use of it. secure-management being already secured using elytron. So we should: - define core-security-realms layer - define legacy-management layer secured with security-realms was: Such layer would be helpful to extend existing layers with ability to be secured using core security realms. In addition, the management layer should make use of it. secure-management being already secured using elytron. So we should: - define core-security-realms layer - secure management layer with security-realms - rename management layer to be legacy-management - rename secure-management to be management > Layer for core security-realms and management layer update > ---------------------------------------------------------- > > Key: WFCORE-4616 > URL: https://issues.jboss.org/browse/WFCORE-4616 > Project: WildFly Core > Issue Type: Enhancement > Components: Build System > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > > Such layer would be helpful to extend existing layers with ability to be secured using core security realms. In addition, the management layer should make use of it. secure-management being already secured using elytron. > So we should: > - define core-security-realms layer > - define legacy-management layer secured with security-realms -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4457) Can not use classes with same name from different packages in the same rule package

by Toni Rikkola (Jira)

[ https://issues.jboss.org/browse/DROOLS-4457?page=com.atlassian.jira.plugi... ] Toni Rikkola updated DROOLS-4457: --------------------------------- Description: If you have fact types: * org.Person * org.test.Person It will not be possible to use these in the same rule package even if they are used in different guided assets. This is since the package imports both and the compiler does not know what is the one that is referenced in the generated DRL code. The fix requires: * to update the exiting fact type selectors so that they show what the package of the fact that is used is. * to use the FQCN in the DRL source. * add the support for asset visitors * add the support for DMO was: If you have fact types: * org.Person * org.test.Person It will not be possible to use these in the same rule package even if they are used in different guided assets. This is since the package imports both and the compiler does not know what is the one that is referenced in the generated DRL code. The fix requires: * to update the exiting fact type selectors so that they show what the package of the fact that is used is. * to use the FQCN in the DRL source. > Can not use classes with same name from different packages in the same rule package > ----------------------------------------------------------------------------------- > > Key: DROOLS-4457 > URL: https://issues.jboss.org/browse/DROOLS-4457 > Project: Drools > Issue Type: Bug > Components: Enumerations Editor, Guided Decision Table Editor, Guided Decision Tree Editor, Guided Rule Editor, Guided Score Card Editor, Guided Template Editor, Scenario Simulation and Testing, Test Scenarios Editor > Affects Versions: 7.26.0.Final > Reporter: Jozef Marko > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > If you have fact types: > * org.Person > * org.test.Person > It will not be possible to use these in the same rule package even if they are used in different guided assets. This is since the package imports both and the compiler does not know what is the one that is referenced in the generated DRL code. > The fix requires: > * to update the exiting fact type selectors so that they show what the package of the fact that is used is. > * to use the FQCN in the DRL source. > * add the support for asset visitors > * add the support for DMO -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 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 August 2019