[JBoss JIRA] (ELY-1554) Upgrade Apache DS in Elytron tests
by Jan Kalina (JIRA)
Jan Kalina created ELY-1554:
-------------------------------
Summary: Upgrade Apache DS in Elytron tests
Key: ELY-1554
URL: https://issues.jboss.org/browse/ELY-1554
Project: WildFly Elytron
Issue Type: Bug
Components: Testsuite
Affects Versions: 1.2.4.Final
Reporter: Jan Kalina
Assignee: Jan Kalina
Priority: Minor
In WFLY-10163 was Apache Directory upgraded for wildfly to 2.0.0-M24.
To be consistent, DS should be upgraded in elytron too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (SWSQE-110) Update OC on Ansible Image
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-110?page=com.atlassian.jira.plugin.... ]
Filip Brychta resolved SWSQE-110.
---------------------------------
Resolution: Done
+ which oc
/usr/bin/oc
+ oc version
oc v3.9.0-alpha.4+aea595c-474
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO
> Update OC on Ansible Image
> --------------------------
>
> Key: SWSQE-110
> URL: https://issues.jboss.org/browse/SWSQE-110
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Guilherme Baufaker Rêgo
> Assignee: Filip Brychta
>
> Started by user Guilherme Baufaker Rêgo
> Running in Durability level: MAX_SURVIVABILITY
> [Pipeline] node
> Still waiting to schedule task
> jenkins-slave-ansible-os-client-tools-kxpss is offline
> Running on jenkins-slave-ansible-os-client-tools-kxpss in /home/jenkins/workspace/Istio+Mesh+Ansible Pipeline
> [Pipeline] {
> [Pipeline] stage
> [Pipeline] { (Clone Istio Repository)
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository https://github.com/gbaufake/istio.git
> > git init /home/jenkins/workspace/Istio+Mesh+Ansible Pipeline/istio # timeout=10
> Fetching upstream changes from https://github.com/gbaufake/istio.git
> > git --version # timeout=10
> > git fetch --tags --progress https://github.com/gbaufake/istio.git +refs/heads/*:refs/remotes/origin/*
> > git config remote.origin.url https://github.com/gbaufake/istio.git # timeout=10
> > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
> > git config remote.origin.url https://github.com/gbaufake/istio.git # timeout=10
> Fetching upstream changes from https://github.com/gbaufake/istio.git
> > git fetch --tags --progress https://github.com/gbaufake/istio.git +refs/heads/*:refs/remotes/origin/*
> > git rev-parse refs/remotes/origin/kiali-addon^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/kiali-addon^{commit} # timeout=10
> Checking out Revision e5be3cd1b2acc60e3ce4ed798f91366947367e17 (refs/remotes/origin/kiali-addon)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f e5be3cd1b2acc60e3ce4ed798f91366947367e17
> Commit message: "Kiali as Istio Addon"
> > git rev-list --no-walk e5be3cd1b2acc60e3ce4ed798f91366947367e17 # timeout=10
> [Pipeline] }
> [Pipeline] // stage
> [Pipeline] stage
> [Pipeline] { (Ansible Playbook)
> [Pipeline] dir
> Running in /home/jenkins/workspace/Istio+Mesh+Ansible Pipeline/istio/install/ansible
> [Pipeline] {
> [Pipeline] sh
> [ansible] Running shell script
> + oc login https://osemaster.os37-gbaufake.osepool.centralci.eng.rdu2.redhat.com:8443 --token=cXd1vapqDSQbW3kWxg7qvuuGgKglMlxvQUaGzH4Mf5s --insecure-skip-tls-verify
> Logged into "https://osemaster.os37-gbaufake.osepool.centralci.eng.rdu2.redhat.com:8443" as "user1" using the token provided.
> You have access to the following projects and can switch between them with 'oc project <projectname>':
> bookinfo
> * default
> istio-system
> kiali-test-box
> kiali-test-breadth-sink
> kiali-test-breath
> kiali-test-circle
> kiali-test-circle-callback
> kiali-test-depth
> kiali-test-depth-sink
> kiali-test-hourglass
> kube-public
> kube-system
> logging
> management-infra
> openshift
> openshift-infra
> openshift-node
> samples
> Using project "default".
> Welcome! See 'oc help' to get started.
> [Pipeline] sh
> [ansible] Running shell script
> + oc version
> oc v1.5.0+031cbe4
> kubernetes v1.5.2+43a9be4
> features: Basic-Auth GSSAPI Kerberos SPNEGO
> [~fbrychta] can you update oc to 3.7?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2426) ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails with lower amount of processors
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2426?page=com.atlassian.jira.plugi... ]
Tibor Zimányi edited comment on DROOLS-2426 at 4/3/18 9:53 AM:
---------------------------------------------------------------
Ok nevermind, I'm blind, there is an inherited partitioned agenda with partitionId. So don't mind my previous comment.
However I think I found the problem (really this time:) ). The problem is that the master agenda expires fact handle before other agendas gets time to process propagations created based on this fact handle. When I comment this out [1], the test works.
I think there might be some sort of callback mechanism for fact handle expiration, because there must be guaranteed that each partitioned agenda have time to process all propagations related to a fact handle (a sort of synchronization on fact handle expiration).
[1] https://github.com/kiegroup/drools/blob/91cb991a4db283ac00eaa2e16d606d722...
was (Author: tzimanyi):
Ok nevermind, I'm blind, there is an inherited partitioned agenda with partitionId. So don't mind my previous comment.
However I think I found the problem (really this time:) ). The problem is that the master agenda expires fact handle before other agendas gets time to process activations created based on this fact handle. When I comment this out [1], the test works.
I think there might be some sort of callback mechanism for fact handle expiration, because there must be guaranteed that each partitioned agenda have time to process all propagations related to a fact handle (a sort of synchronization on fact handle expiration).
[1] https://github.com/kiegroup/drools/blob/91cb991a4db283ac00eaa2e16d606d722...
> ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails with lower amount of processors
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2426
> URL: https://issues.jboss.org/browse/DROOLS-2426
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
>
> The test ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails randomly, when the machine on which it is run has smaller amount of processors (tested with 2). It fails because the engine doesn't produce expected amount of rule fires, so the test waits on a CountDownLatch. One idea what happens is that one agenda thread expires events from second agenda on some race condition. But that is a first guess after looking at the code.
> Steps to reproduce:
> 1. Change the number of parallel partitions to 2 here [1]
> 2. Rebuild drools-core
> 3. Run the test from PR [2] few times.
> [1] https://github.com/kiegroup/drools/blob/63ea870c89591dfeae1276f582d825670...
> [2] https://github.com/kiegroup/drools/pull/1843
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (DROOLS-2426) ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails with lower amount of processors
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2426?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-2426:
---------------------------------------
Ok nevermind, I'm blind, there is an inherited partitioned agenda with partitionId. So don't mind my previous comment.
However I think I found the problem (really this time:) ). The problem is that the master agenda expires fact handle before other agendas gets time to process activations created based on this fact handle. When I comment this out [1], the test works.
I think there might be some sort of callback mechanism for fact handle expiration, because there must be guaranteed that each partitioned agenda have time to process all propagations related to a fact handle (a sort of synchronization on fact handle expiration).
[1] https://github.com/kiegroup/drools/blob/91cb991a4db283ac00eaa2e16d606d722...
> ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails with lower amount of processors
> ---------------------------------------------------------------------------------------------
>
> Key: DROOLS-2426
> URL: https://issues.jboss.org/browse/DROOLS-2426
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
>
> The test ParallelEvaluationTest.testFireUntilHaltWithExpiration2 fails randomly, when the machine on which it is run has smaller amount of processors (tested with 2). It fails because the engine doesn't produce expected amount of rule fires, so the test waits on a CountDownLatch. One idea what happens is that one agenda thread expires events from second agenda on some race condition. But that is a first guess after looking at the code.
> Steps to reproduce:
> 1. Change the number of parallel partitions to 2 here [1]
> 2. Rebuild drools-core
> 3. Run the test from PR [2] few times.
> [1] https://github.com/kiegroup/drools/blob/63ea870c89591dfeae1276f582d825670...
> [2] https://github.com/kiegroup/drools/pull/1843
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFCORE-3596) further improve the permissions mapping configuration model to be manageable to by a tool
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3596?page=com.atlassian.jira.plugi... ]
Farah Juma reassigned WFCORE-3596:
----------------------------------
Assignee: Farah Juma
> further improve the permissions mapping configuration model to be manageable to by a tool
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-3596
> URL: https://issues.jboss.org/browse/WFCORE-3596
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Affects Versions: 4.0.0.Alpha10
> Reporter: Alexey Loubyansky
> Assignee: Farah Juma
> Priority: Critical
>
> The current configuration model for mapping permissions does not appear to be manageable by a tool that is trying to add/remove permissions based on the presence/absence of a specific subsystem.
> This is a critical issue for the provisioning mechanism which is not only producing the default configuration that could be simple enough but also allows the user to customize the default configuration and then preserve the user changes after applying a version update or a patch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (SWSQE-112) Document configuration of openshift production cluster
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-112?page=com.atlassian.jira.plugin.... ]
Filip Brychta updated SWSQE-112:
--------------------------------
Description:
We need mojo page with full description of our openshift production cluster which should include:
* used blades
* OS version
* description of all necessary accounts and permissions (for jenkins, jenkins slaves,...)
* description of persistence storage
* ...
was:
We need mojo page with full description of our openshift production cluster which should include:
* used blades
* OS version
* description of all necessary accounts and permissions (for jenkins, jenkins slaves,...)
* ...
> Document configuration of openshift production cluster
> ------------------------------------------------------
>
> Key: SWSQE-112
> URL: https://issues.jboss.org/browse/SWSQE-112
> Project: Kiali QE
> Issue Type: Task
> Reporter: Filip Brychta
> Assignee: Michael Foley
>
> We need mojo page with full description of our openshift production cluster which should include:
> * used blades
> * OS version
> * description of all necessary accounts and permissions (for jenkins, jenkins slaves,...)
> * description of persistence storage
> * ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFCORE-3725) further improve the permissions mapping configuration model to be manageable to by a tool
by Farah Juma (JIRA)
Farah Juma created WFCORE-3725:
----------------------------------
Summary: further improve the permissions mapping configuration model to be manageable to by a tool
Key: WFCORE-3725
URL: https://issues.jboss.org/browse/WFCORE-3725
Project: WildFly Core
Issue Type: Task
Components: Security
Affects Versions: 4.0.0.Alpha10
Reporter: Farah Juma
Priority: Critical
The current configuration model for mapping permissions does not appear to be manageable by a tool that is trying to add/remove permissions based on the presence/absence of a specific subsystem.
This is a critical issue for the provisioning mechanism which is not only producing the default configuration that could be simple enough but also allows the user to customize the default configuration and then preserve the user changes after applying a version update or a patch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFCORE-3722) WildFly Build Tools version properties is set in two different POMs
by Martin Stefanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3722?page=com.atlassian.jira.plugi... ]
Martin Stefanko reassigned WFCORE-3722:
---------------------------------------
Assignee: Martin Stefanko
> WildFly Build Tools version properties is set in two different POMs
> -------------------------------------------------------------------
>
> Key: WFCORE-3722
> URL: https://issues.jboss.org/browse/WFCORE-3722
> Project: WildFly Core
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Martin Stefanko
>
> {noformat}
> $ grep build-tools `find . -name pom.xml`
> ./component-matrix/pom.xml: <version.org.wildfly.build-tools>1.2.6.Final</version.org.wildfly.build-tools>
> ./pom.xml: <version.org.wildfly.build-tools>1.2.6.Final</version.org.wildfly.build-tools>
> ./pom.xml: <version>${version.org.wildfly.build-tools}</version>
> ./pom.xml: <version>${version.org.wildfly.build-tools}</version>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months