June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1156) Automate PeerAuth validations

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1156?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1156: ---------------------------------- Sprint: Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #40) > Automate PeerAuth validations > ----------------------------- > > Key: SWSQE-1156 > URL: https://issues.redhat.com/browse/SWSQE-1156 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > https://github.com/kiali/kiali/issues/2086 > https://github.com/kiali/kiali/pull/2808 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1150) Overview - Idle status automation

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1150?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1150: ---------------------------------- Sprint: Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #40) > Overview - Idle status automation > --------------------------------- > > Key: SWSQE-1150 > URL: https://issues.redhat.com/browse/SWSQE-1150 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1170) Workload logs - Hide lines

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1170?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1170: ---------------------------------- Sprint: Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #40) > Workload logs - Hide lines > -------------------------- > > Key: SWSQE-1170 > URL: https://issues.redhat.com/browse/SWSQE-1170 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1132) Automate OCP disconnected testing

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1132?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1132: ---------------------------------- Sprint: Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40) > Automate OCP disconnected testing > --------------------------------- > > Key: SWSQE-1132 > URL: https://issues.redhat.com/browse/SWSQE-1132 > Project: Kiali QE > Issue Type: Story > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > SM on disconnected OCP cluster will be the main feature of SM 1.1.1 > We need to automate testing of that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1089) Remove hardcoded waiting for webhook "smcp.validation.maistra.io"

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1089?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1089: ---------------------------------- Sprint: Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40) > Remove hardcoded waiting for webhook "smcp.validation.maistra.io" > ----------------------------------------------------------------- > > Key: SWSQE-1089 > URL: https://issues.redhat.com/browse/SWSQE-1089 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Optional > Labels: infrastructure > > https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/blob/ma... > There is no need to wait that long. We need some dynamic check. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1077) Kiali Test For Istio.io

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1077?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1077: ---------------------------------- Sprint: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40) > Kiali Test For Istio.io > ----------------------- > > Key: SWSQE-1077 > URL: https://issues.redhat.com/browse/SWSQE-1077 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matthew Mahoney > Priority: Major > Labels: infrastructure > > The Istio.io team is requesting a Kiali test case that can be run on each submitted PR. The purpose of this test case is to validate that Kiali is not broken upon a PR submittal. > Meeting with [~brian.avery] [~gbaufake]: > 1) BrianA to port existing Kiali test case that was developed in old Istio.io test framework to new istiso.io framework > https://github.com/istio/istio/blob/master/tests/e2e/tests/kiali/kiali_te... > 2) Kiali team then to add an api test case(s) via 'curl' to validate the Istio/Kiali integration is properly functioning. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1056) Try OCP 4.4 on IPv6 in PSI

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1056?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1056: ---------------------------------- Sprint: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #32, Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40) > Try OCP 4.4 on IPv6 in PSI > -------------------------- > > Key: SWSQE-1056 > URL: https://issues.redhat.com/browse/SWSQE-1056 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-612) QE CI/CP Integration, best practices - stage 2

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-612?page=com.atlassian.jira.plugin... ] Hayk Hovsepyan updated SWSQE-612: --------------------------------- Sprint: Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41 (was: Kiali Sprint #36, Kiali Sprint #37, Kiali Sprint #38, Kiali Sprint #39, Kiali Sprint #40) > QE CI/CP Integration, best practices - stage 2 > ---------------------------------------------- > > Key: SWSQE-612 > URL: https://issues.redhat.com/browse/SWSQE-612 > Project: Kiali QE > Issue Type: Story > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > This story is to track future tasks when the stage 1 is finished. > Tasks from this story might be worked simultaneously with stage 1 tasks but with lower priority. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13508) Incorrect layer name for 'naming' layer on the layer specification file

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13508?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13508: ---------------------------------------- Summary: Incorrect layer name for 'naming' layer on the layer specification file (was: Incorrect layer name for 'naming' layer on the ayer specification file) > Incorrect layer name for 'naming' layer on the layer specification file > ----------------------------------------------------------------------- > > Key: WFLY-13508 > URL: https://issues.redhat.com/browse/WFLY-13508 > Project: WildFly > Issue Type: Bug > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Minor > > Galleon layer name for "naming" layer should be "naming" instead of "ee". > This is not a problem at all since currently layers names are discovered by the directory name it resides, however, the wrong name here could lead to confusion. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5372) Implement PMML coexistence

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi edited comment on DROOLS-5372 at 6/8/20 6:05 AM: ------------------------------------------------------------------ Most cost-effective solution could be: # verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath ( "openshift/docker" images): ## only one is invoked; evaluate how this may be managed when both modules are expected to be present in the classpath # different issue for the PMMLRuntime, since it is defined and used in the new kie-pmml but not in the old one # Create a "NO_OP" resourcetype # Define an _environmental_ variable used to choose the implementation *but only if both are presents* (this variable is ignored if only one implementation is present) # Inside both PMMLRuntimes.getResourceType, add a verification snippet that *if both implementations are present*, consider the variable - return "NO_OP" resource type from the PMMLAssembler that has to be excluded # inside DMN: ## Create `DMNKiePMMLNewInvocationEvaluator` ## Put common code with `DMNKiePMMLInvocationEvaluator` inside `AbstractDMNKiePMMLInvocationEvaluator` ## inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich `AbstractDMNKiePMMLInvocationEvaluator` implementation (old or new) is to be used when the jpmml one is not in the classpath # Code written for *old* kie-pmml will be incompatible for new one (and the other way around) was (Author: gabriolo): Most cost-effective solution could be: # verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath ( "openshift/docker" images): ## only one is invoked; evaluate how this may be managed when both modules are expected to be present in the classpath # different issue for the PMMLRuntime, since it is defined and used in the new kie-pmml but not in the old one # Create a "NO_OP" resourcetype # Define an _environmental_ variable used to choose the implementation *but only if both are presents* (this variable is ignored if only one implementation is present) # Inside both PMMLRuntimes.getResourceType, add a verification snippet that *if both implementations are present*, consider the variable - return "NO_OP" resource type from the PMMLAssembler that has to be excluded # inside DMN: ## inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath # Code written for *old* kie-pmml will be incompatible for new one (and the other way around) > Implement PMML coexistence > --------------------------- > > Key: DROOLS-5372 > URL: https://issues.redhat.com/browse/DROOLS-5372 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > New and old PMML implementations should live together for some time. > See comment -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 June 2020