March 2020 - jboss-jira - Jboss List Archives

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

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1089: ------------------------------------ Summary: 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 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)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1088) Reinstallation of SM 1.0/1.1 fails with failed calling webhook "smcp.mutation.maistra.io

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1088?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1088. ---------------------------------- Resolution: Done SM 1.1 introduced mutatingwebhookconfiguration. It must be cleaned before reinstalling older SM version. https://gitlab.cee.redhat.com/istio/kiali-qe/kiali-qe-jenkins-dsl/commit/... > Reinstallation of SM 1.0/1.1 fails with failed calling webhook "smcp.mutation.maistra.io > ---------------------------------------------------------------------------------------- > > Key: SWSQE-1088 > URL: https://issues.redhat.com/browse/SWSQE-1088 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > Following errors are visible when trying to re-install SM 1.0 or 1.1: > Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "smcp.mutation.maistra.io": Post https://admission-controller.openshift-operators.svc:443/mutate-smcp?time...: no endpoints available for service "admission-controller" > Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "smcp.mutation.maistra.io": Post https://admission-controller.istio-operator.svc:443/mutate-smcp?timeout=30s: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "webhook-cert-ca") -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1088) Reinstallation of SM 1.0/1.1 fails with failed calling webhook "smcp.mutation.maistra.io

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1088: ------------------------------------ Summary: Reinstallation of SM 1.0/1.1 fails with failed calling webhook "smcp.mutation.maistra.io Key: SWSQE-1088 URL: https://issues.redhat.com/browse/SWSQE-1088 Project: Kiali QE Issue Type: Bug Reporter: Filip Brychta Assignee: Filip Brychta Following errors are visible when trying to re-install SM 1.0 or 1.1: Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "smcp.mutation.maistra.io": Post https://admission-controller.openshift-operators.svc:443/mutate-smcp?time...: no endpoints available for service "admission-controller" Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "smcp.mutation.maistra.io": Post https://admission-controller.istio-operator.svc:443/mutate-smcp?timeout=30s: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "webhook-cert-ca") -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13147) Deployment slowdown after WFLY upgrade (DeploymentArchive handling)

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-13147?page=com.atlassian.jira.plugi... ] Matěj Novotný edited comment on WFLY-13147 at 3/10/20 11:06 AM: ---------------------------------------------------------------- Sorry, didn't get to this earlier. So, looking at the code in {{BeanDeploymentArchiveImpl}} - the idea here is pretty clear, avoid loading the module until you really have to. However, the other bit in {{ExternalBeanArchiveProcessor}} isn't so clear to me.The {{instanceof}} check I get, but then you compare the names of the currently inspected dependency to the names of any of the deployment units. I guess the idea here is that any dependency that is in fact another deployment unit will get (or already got) processed eventually, right? I think in this case it might be better to instead build a list (essentially a cache) of already processed dependencies in order to avoid duplicating work. I am also running WFLY tests with some changes along the lines of what you proposed, but thats just functional/integration testing, not throughput ATM. EDIT: just FTR, WFLY testsuite passes with these changes. was (Author: manovotn): Sorry, didn't get to this earlier. So, looking at the code in {{BeanDeploymentArchiveImpl}} - the idea here is pretty clear, avoid loading the module until you really have to. However, the other bit in {{ExternalBeanArchiveProcessor}} isn't so clear to me.The {{instanceof}} check I get, but then you compare the names of the currently inspected dependency to the names of any of the deployment units. I guess the idea here is that any dependency that is in fact another deployment unit will get (or already got) processed eventually, right? I think in this case it might be better to instead build a list (essentially a cache) of already processed dependencies in order to avoid duplicating work. I am also running WFLY tests with some changes along the lines of what you proposed, but thats just functional/integration testing, not throughput ATM. > Deployment slowdown after WFLY upgrade (DeploymentArchive handling) > ------------------------------------------------------------------- > > Key: WFLY-13147 > URL: https://issues.redhat.com/browse/WFLY-13147 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 17.0.1.Final > Reporter: Christoph Winter > Assignee: Matěj Novotný > Priority: Major > Attachments: Screenshot from 2020-02-24 16-23-53.png, Screenshot from 2020-02-24 16-24-32.png > > > Our team upgraded our application (>205 modules) from WFLY 8.2.1 to WFLY 17.0.1 we experienced a noticeable slowdown during the deployment process (3min vs. 6min) > A colleague found out that the following classes seem to cause the lag during dependency resolution since dependencies are processed multiple times: > * weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java > * weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java > and came up with the following workarounds that should fix the issues > {noformat} > diff --git a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java > index 521f47cc7d..1b4d7e8b4c 100644 > --- a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java > +++ b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/BeanDeploymentArchiveImpl.java > @@ -246,7 +246,12 @@ public class BeanDeploymentArchiveImpl implements WildFlyBeanDeploymentArchive { > if (moduleDependency.getIdentifier().equals(that.getModule().getIdentifier())) { > return true; > } > + } > + } > + for (DependencySpec dependency : module.getDependencies()) { > + if (dependency instanceof ModuleDependencySpec) { > + ModuleDependencySpec moduleDependency = (ModuleDependencySpec) dependency; > // moduleDependency might be an alias - try to load it to get lined module > Module module = loadModule(moduleDependency); > if (module != null && module.getIdentifier().equals(that.getModule().getIdentifier())) { > {noformat} > as well as > {noformat} > diff --git a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java > index da6e0bfcaf..1b539bba4e 100644 > --- a/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java > +++ b/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java > @@ -162,6 +162,12 @@ public class ExternalBeanArchiveProcessor implements DeploymentUnitProcessor { > return; > } > for (DependencySpec dep : module.getDependencies()) { > + if (!(dep instanceof ModuleDependencySpec)) { > + continue; > + } > + if (deploymentUnits.stream().anyMatch(d -> (((ModuleDependencySpec)dep).getName()).endsWith(d.getName()))) { > + continue; > + } > final Module dependency = loadModuleDependency(dep); > if (dependency == null) { > continue;{noformat} > The fixes should prevent dependencies from being processed multiple times, however, the latter should be improved. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3339) Refactor the PMML Regression

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-3339?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-3339: --------------------------------- Labels: PMMLRefactor TrustyAI drools-tools (was: PMMLRefactor TrustyAI) > Refactor the PMML Regression > ---------------------------- > > Key: DROOLS-3339 > URL: https://issues.redhat.com/browse/DROOLS-3339 > Project: Drools > Issue Type: Task > Components: PMML > Affects Versions: 7.14.0.Final > Reporter: Michael McCune > Assignee: Gabriele Cardosi > Priority: Critical > Labels: PMMLRefactor, TrustyAI, drools-tools > > Replace the current DRL generation for regression calculation by a specialized regression library, in order to simplify the code and improve compilation and runtime performance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5143) Refactor PMML Mining Model

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-5143?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-5143: --------------------------------- Labels: CustomerFocus TrustyAI drools-tools (was: CustomerFocus TrustyAI) > Refactor PMML Mining Model > -------------------------- > > Key: DROOLS-5143 > URL: https://issues.redhat.com/browse/DROOLS-5143 > Project: Drools > Issue Type: Task > Components: PMML > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: CustomerFocus, TrustyAI, drools-tools > > Refactor the PMML Mining Model with new implementation -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4589) Refactor of Scorecards

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-4589?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-4589: --------------------------------- Labels: CustomerFocusTeam TrustyAI drools-tools (was: CustomerFocusTeam TrustyAI) > Refactor of Scorecards > ---------------------- > > Key: DROOLS-4589 > URL: https://issues.redhat.com/browse/DROOLS-4589 > Project: Drools > Issue Type: Task > Components: PMML > Reporter: Lance Leverich > Assignee: Gabriele Cardosi > Priority: Major > Labels: CustomerFocusTeam, TrustyAI, drools-tools > > Re-design and refactoring of Scorecard model in kie-pmml module. The result of which should be... > * Scorecard models uses a standardized "pipeline" for processing requests to apply a model to input data > * Scorecard models use the "re-usable alpha network" approach when possible, minimizing the use of KieSessions and rete. > * Scorecard models use a minimal amount of rules when applying the model to input data, and any generated rules should be in executable model form/format > * Scorecard models are applied via a service interface > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5103) Implement PMML model archetype

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-5103?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-5103: --------------------------------- Labels: PMMLRefactor TrustyAI drools-tools (was: PMMLRefactor TrustyAI) > Implement PMML model archetype > ------------------------------ > > Key: DROOLS-5103 > URL: https://issues.redhat.com/browse/DROOLS-5103 > Project: Drools > Issue Type: Task > Components: PMML > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: PMMLRefactor, TrustyAI, drools-tools > > Create a maven archetype to auomatically generate stub modele-specific module inside new pmml implementation -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5144) Refactor PMML Decision Tree

by Anna Dupliak (Jira)

[ https://issues.redhat.com/browse/DROOLS-5144?page=com.atlassian.jira.plug... ] Anna Dupliak updated DROOLS-5144: --------------------------------- Labels: CustomerFocus TrustyAI drools-tools (was: CustomerFocus TrustyAI) > Refactor PMML Decision Tree > --------------------------- > > Key: DROOLS-5144 > URL: https://issues.redhat.com/browse/DROOLS-5144 > Project: Drools > Issue Type: Task > Components: PMML > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: CustomerFocus, TrustyAI, drools-tools > > Refactor Decision Tree with new implementation -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2416) Native image: test IPv6 addresses

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2416?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2416. ---------------------------- Resolution: Done Tested with GraalVM-11-20.0.0. {{ProgrammaticUPerf}} worked fine, I never managed to create a native image for {{ProgrammaticUperf2}}... > Native image: test IPv6 addresses > --------------------------------- > > Key: JGRP-2416 > URL: https://issues.redhat.com/browse/JGRP-2416 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0, 4.2.1 > > > Currently, we're using IPv4 because of flag {{-J-Djava.net.preferIPv4Stack=true}} in the generation of the native image with GraalVM. > Remove this flag and test IPv6 addresses with UDP, TCP and TCP_NIO2. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 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 March 2020