September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-932) Install Maistra: Kiali and Kiali-Operator default version to 1.0.5

by Matthew Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-932?page=com.atlassian.jira.plugin.... ] Matthew Mahoney closed SWSQE-932. --------------------------------- Resolution: Done No longer relevant. > Install Maistra: Kiali and Kiali-Operator default version to 1.0.5 > ------------------------------------------------------------------ > > Key: SWSQE-932 > URL: https://issues.jboss.org/browse/SWSQE-932 > Project: Kiali QE > Issue Type: Task > Reporter: Matthew Mahoney > Assignee: Matthew Mahoney > Priority: Minor > Labels: infrastructure > > RC1 Kiali version is now 1.0.5 - updaste install-maistr default to reflect such. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-910) Jaeger - Create RC1 Polarion PQI reports

by Matthew Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-910?page=com.atlassian.jira.plugin.... ] Matthew Mahoney resolved SWSQE-910. ----------------------------------- Resolution: Done RC PQI reports generated for GA. Closing. > Jaeger - Create RC1 Polarion PQI reports > ---------------------------------------- > > Key: SWSQE-910 > URL: https://issues.jboss.org/browse/SWSQE-910 > Project: Kiali QE > Issue Type: QE Task > Reporter: Sunil Kondkar > Assignee: Sunil Kondkar > Priority: Major > Labels: pqi > > Get PQI reports for Jaeger: > 1) Check Test case Quality Audit report(No missing data) > 2) PQI reports - Create RC1 test iteration, link this iteration to Jaeger RC1 test runs -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-909) Kiali - Create RC1 Polarion PQI reports

by Matthew Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-909?page=com.atlassian.jira.plugin.... ] Matthew Mahoney resolved SWSQE-909. ----------------------------------- Resolution: Done RC PQI reports generated for GA. Closing. > Kiali - Create RC1 Polarion PQI reports > --------------------------------------- > > Key: SWSQE-909 > URL: https://issues.jboss.org/browse/SWSQE-909 > Project: Kiali QE > Issue Type: QE Task > Reporter: Sunil Kondkar > Assignee: Sunil Kondkar > Priority: Major > Labels: pqi > > Get PQI reports for Kiali: > 1) Check Test case Quality Audit report(No missing data) > 2) PQI reports - Create RC1 test iteration, link this iteration to Kiali RC1 test runs -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-951) Fix certificates for RH update center in jenkins2

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-951?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-951: ------------------------------------- We need to use one of following versions: http://ci-ops-jenkins-update-site.rhev-ci-vms.eng.rdu2.redhat.com/update-... https://docs.engineering.redhat.com/display/CentralCI/Installing+and+Upda... The first link you tried[1] seems to make the assumption that you are running a supported Jenkins CSB master. From the error that you copied it looks like you are running Jenkins 2.193, which is not a version that we support. For this reason manually specifying a version in the update center url is necessary. > Fix certificates for RH update center in jenkins2 > ------------------------------------------------- > > Key: SWSQE-951 > URL: https://issues.jboss.org/browse/SWSQE-951 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Checking for updates fails with: > There were errors checking the update sites: IOException: Server returned HTTP response code: 403 for URL: http://ci-ops-jenkins-update-site.rhev-ci-vms.eng.rdu2.redhat.com/update-... > Probably because of incorrect certificates. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-951) Fix certificates for RH update center in jenkins2

by Filip Brychta (Jira)

Filip Brychta created SWSQE-951: ----------------------------------- Summary: Fix certificates for RH update center in jenkins2 Key: SWSQE-951 URL: https://issues.jboss.org/browse/SWSQE-951 Project: Kiali QE Issue Type: Bug Reporter: Filip Brychta Assignee: Filip Brychta Checking for updates fails with: There were errors checking the update sites: IOException: Server returned HTTP response code: 403 for URL: http://ci-ops-jenkins-update-site.rhev-ci-vms.eng.rdu2.redhat.com/update-... Probably because of incorrect certificates. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4668) Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created WFCORE-4668: ---------------------------------------- Summary: Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext Key: WFCORE-4668 URL: https://issues.jboss.org/browse/WFCORE-4668 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 10.0.0.Beta9 Reporter: Ondrej Chaloupka Assignee: Darran Lofthouse The issue WFCORE-4599 removed the `AuthenticationContext` would be static. This started to cause troubles for transaction recovery processing when remote ejb calls are invoked. The configuration that was used earlier for server to server ejb calls[1] (used with `-Dwildfly.config.url`) stopped working. It was possible to configure the default authentication context in the `standalone.xml` for the whole elytron subsystem (in way like [2]). But this change started to cause threads being stuck on execution of remote ejb calls in WFTC (somewhere here [3]). Because of that the WFCORE-4659 reverted back the functionality of static global authentication context. This was rather a bit workaround as the functionality should be rather working as Stuart pointed out {quote} - Add an explicit config to specify the authentication context used by transaction recovery - If this is not set fall back to the default authentication context that is used by deployments - If none of the above are set then the auth context should be empty {quote} [1] {code} <configuration> <authentication-client xmlns="urn:elytron:1.0"> <authentication-rules> <rule use-configuration="jta"> <match-abstract-type name="jta" authority="jboss"/> </rule> </authentication-rules> <authentication-configurations> <configuration name="jta"> <sasl-mechanism-selector selector="DIGEST-MD5"/> <providers> <use-service-loader /> </providers> <set-user-name name="ejb"/> <credentials> <clear-password password="ejb"/> </credentials> <set-mechanism-realm name="ApplicationRealm" /> </configuration> </authentication-configurations> </authentication-client> </configuration> {code} [2] {code} <subsystem xmlns="urn:wildfly:elytron:8.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto" default-authentication-context="jta"> <authentication-client> <authentication-configuration name="jta" authentication-name="ejb" realm="ApplicationRealm" sasl-mechanism-selector="DIGEST-MD5"> <credential-reference clear-text="ejb"/> </authentication-configuration> <authentication-context name="jta"> <match-rule match-abstract-type-authority="jboss" authentication-configuration="jta"/> </authentication-context> </authentication-client> {code} [3] https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai... -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4536) Test scenarios fails with default values

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4536?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-4536: ------------------------------------- [~Rikkola] Ok, I used `Integer` and `Double`, question is now if it should be fixed as part of this ticket or a new one. > Test scenarios fails with default values > ---------------------------------------- > > Key: DROOLS-4536 > URL: https://issues.jboss.org/browse/DROOLS-4536 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Affects Versions: 7.25.0.Final > Reporter: Sudhish Nair > Assignee: Toni Rikkola > Priority: Minor > Labels: drools-tools, support > Attachments: Screenshot from 2019-09-16 12-34-12.png, latestjbpmfailed.png, latestjbpmpassed.png, sample.drl > > > In test scenarios (Legacy test scenario) expect section, if we don't edit the default numeric values in expect section then test scenario fails, but if we edit and enter the same value it passes, sometimes we have to type a different value, run the test, then retype 0/0.0 for it to pass. > The issue is always reproducible. > h2. Acceptance test > - Default empty text (/) > - Default int zero (x) > - Default double zero (x) > - Default boolean true (/) -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3957) Make verifier panel use docks

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3957?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-3957: ------------------------------------- [~Rikkola] hello, please what is status of this jira, should I recheck the PRs? > Make verifier panel use docks > ----------------------------- > > Key: DROOLS-3957 > URL: https://issues.jboss.org/browse/DROOLS-3957 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > Attachments: v&v.webm > > > Pretty sure we had a ticket for this, but could not find it. Here it is. > h3. Acceptance test > On both Firefox and Chrome (x) > - Opening multiple decision tables, switching between them > - Repeated reopening of guided decision table > - Opening other asset that uses docks - scenario, data object -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-201) incomplete tx recovery on openshift

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFWIP-201?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka commented on WFWIP-201: ---------------------------------------- The issue with the authentication was resolved by applying the fix of https://issues.jboss.org/browse/WFCORE-4659 (merged for WFCORE 10.0.0.Beta9) . Confirmed by testing and with [~simkam]. Resolving this issue. > incomplete tx recovery on openshift > ----------------------------------- > > Key: WFWIP-201 > URL: https://issues.jboss.org/browse/WFWIP-201 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: auth_fail.txt, tx-client-0.txt, tx-server-0.txt > > > While testing tx recovery in OpenShift I see that recovery doesn't completely finish in some tests. > 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 > ejb server XA resource 2 crashes JVM in commit method phase. (the same outcome client crashes at commit phase) > Test waits until crashed pod is restarted, then forces periodic recovery twice and then checks that transaction log store is empty. But it is not empty, however it looks like all XA resources were commited. > Attached are logs from client and server pods. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-201) incomplete tx recovery on openshift

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFWIP-201?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka resolved WFWIP-201. ------------------------------------ Resolution: Done > incomplete tx recovery on openshift > ----------------------------------- > > Key: WFWIP-201 > URL: https://issues.jboss.org/browse/WFWIP-201 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: auth_fail.txt, tx-client-0.txt, tx-server-0.txt > > > While testing tx recovery in OpenShift I see that recovery doesn't completely finish in some tests. > 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 > ejb server XA resource 2 crashes JVM in commit method phase. (the same outcome client crashes at commit phase) > Test waits until crashed pod is restarted, then forces periodic recovery twice and then checks that transaction log store is empty. But it is not empty, however it looks like all XA resources were commited. > Attached are logs from client and server pods. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 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 September 2019