November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-1018) Molecule Tests don't run on Jenkins Slaves

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-1018?page=com.atlassian.jira.plugin... ] Filip Brychta commented on SWSQE-1018: -------------------------------------- Is access to docker required? ansible jenkins slave does not have access to docker and never had? This looks like new requirement. Why is docker needed? > Molecule Tests don't run on Jenkins Slaves > ------------------------------------------ > > Key: SWSQE-1018 > URL: https://issues.jboss.org/browse/SWSQE-1018 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Major > Attachments: olm.log > > > Running a simple > {code:bash} > molecule test -s olm-test > {code} > inside kiali/operator/ folder doesn't work on Jenkins slaves. > Before updating from Ansible 2.8 to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... > After updating to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1018) Molecule Tests don't run on Jenkins Slaves

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-1018?page=com.atlassian.jira.plugin... ] Guilherme Baufaker Rêgo commented on SWSQE-1018: ------------------------------------------------ Running locally with docker, molecule, ansible, openshift pip modules worked. [^olm.log] > Molecule Tests don't run on Jenkins Slaves > ------------------------------------------ > > Key: SWSQE-1018 > URL: https://issues.jboss.org/browse/SWSQE-1018 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Major > Attachments: olm.log > > > Running a simple > {code:bash} > molecule test -s olm-test > {code} > inside kiali/operator/ folder doesn't work on Jenkins slaves. > Before updating from Ansible 2.8 to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... > After updating to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1018) Molecule Tests don't run on Jenkins Slaves

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-1018?page=com.atlassian.jira.plugin... ] Guilherme Baufaker Rêgo updated SWSQE-1018: ------------------------------------------- Attachment: olm.log > Molecule Tests don't run on Jenkins Slaves > ------------------------------------------ > > Key: SWSQE-1018 > URL: https://issues.jboss.org/browse/SWSQE-1018 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Major > Attachments: olm.log > > > Running a simple > {code:bash} > molecule test -s olm-test > {code} > inside kiali/operator/ folder doesn't work on Jenkins slaves. > Before updating from Ansible 2.8 to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... > After updating to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1018) Molecule Tests don't run on Jenkins Slaves

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-1018?page=com.atlassian.jira.plugin... ] Guilherme Baufaker Rêgo commented on SWSQE-1018: ------------------------------------------------ I recompiled the ansible slave and it didn't work. [31mERROR: Unable to contact the Docker daemon. Please refer to https://docs.docker.com/config/daemon/ for managing the daemon[0m https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... Running those tests locally they work as they expected. > Molecule Tests don't run on Jenkins Slaves > ------------------------------------------ > > Key: SWSQE-1018 > URL: https://issues.jboss.org/browse/SWSQE-1018 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Filip Brychta > Priority: Major > > Running a simple > {code:bash} > molecule test -s olm-test > {code} > inside kiali/operator/ folder doesn't work on Jenkins slaves. > Before updating from Ansible 2.8 to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... > After updating to Ansible 2.9: > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/test-molecule/1... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1890) Keep file permissions when modifying an existing credential store

by Ingo Weiss (Jira)

[ https://issues.jboss.org/browse/ELY-1890?page=com.atlassian.jira.plugin.s... ] Ingo Weiss updated ELY-1890: ---------------------------- Issue Type: Bug (was: Feature Request) > Keep file permissions when modifying an existing credential store > ----------------------------------------------------------------- > > Key: ELY-1890 > URL: https://issues.jboss.org/browse/ELY-1890 > Project: WildFly Elytron > Issue Type: Bug > Components: Command-Line Tool > Affects Versions: 1.11.0.CR1 > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Priority: Major > > Using the offline elytron.sh tool, after creating the credential store I changed the mode to 600. Using the elytron.sh tool to add credentials changes the mode back to 644. Is that intentional for it to automatically do that? I would either expect it to not change and update or not change and error out. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugi... ] Scott Marlow commented on WFCORE-3948: -------------------------------------- {quote}All of my above discussion is wrong; all that's needed is for AttachmentList to be thread safe.{quote} Do we need the AttachementList to be iteration (thread) safe as well? As in [CopyOnWriteArrayList|https://docs.oracle.com/javase/8/docs/api/java/util/... Or is [SynchronizedList|https://docs.oracle.com/javase/8/docs/api/java/util/Coll...] (not iteration thread safe) enough? > Potential race condition on deployment of EAR when Class-Path manifest entry is in use > -------------------------------------------------------------------------------------- > > Key: WFCORE-3948 > URL: https://issues.jboss.org/browse/WFCORE-3948 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Stuart Douglas > Assignee: Brian Stansberry > Priority: Major > > Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFCORE-3948?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-3948 at 11/27/19 10:21 AM: --------------------------------------------------------------------- All of my above discussion is wrong; all that's needed is for AttachmentList to be thread safe. Why? All writes occur in Phase STRUCTURE. The DeploymentUnitPhaseService for the STRUCTURE Phase for the top level deployment installs all the SubDeploymentUnitService instances. It's a general rule that any service has a dep on the service that installed it, so that means any SubDeploymentUnitService will not start until the top level deployment has completed STRUCTURE phase and thus will see all its data. Within the STRUCTURE phase, the subdeployments don't care about the data from other subdeployments. SubDeploymentProcessor adds a dep on the STRUCTURE phase for each subdeployment to the top level deployment's PARSE phase. So all the subdeployments will have completed STRUCTURE before the top begins PARSE work. All the writes happen in STRUCTURE so they will be complete. All the reads after STRUCTURE are either by the top level deployment, which waits for the writes, or by subdeployments which are not concerned with any writes by other subdeployments. was (Author: brian.stansberry): All of my above discussion is wrong; all that's needed is for AttachmentList to be thread safe. Why? The DeploymentUnitPhaseService for the STRUCTURE Phase for the top level deployment installs all the SubDeploymentUnitService instances. It's a general rule that any service has a dep on the service that installed it, so that means any SubDeploymentUnitService will not start until the top level deployment has completed STRUCTURE phase and will see all its data. Within the STRUCTURE phase, the subdeployments don't care about the data from other subdeployments. SubDeploymentProcessor adds a dep on the STRUCTURE phase for each subdeployment to the top level deployment's PARSE phase. So all the subdeployments will have completed STRUCTURE before the top begins PARSE work. All the writes happen in STRUCTURE so they will be complete. All the reads after STRUCTURE are either by the top level deployment, which waits for the writes, or by subdeployments which are not concerned with any writes by other subdeployments. > Potential race condition on deployment of EAR when Class-Path manifest entry is in use > -------------------------------------------------------------------------------------- > > Key: WFCORE-3948 > URL: https://issues.jboss.org/browse/WFCORE-3948 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Stuart Douglas > Assignee: Brian Stansberry > Priority: Major > > Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4817) Raise the timeout for generated tests

by Daniel Rosa (Jira)

Daniel Rosa created DROOLS-4817: ----------------------------------- Summary: Raise the timeout for generated tests Key: DROOLS-4817 URL: https://issues.jboss.org/browse/DROOLS-4817 Project: Drools Issue Type: Bug Reporter: Daniel Rosa Assignee: Daniel Rosa On Jenkins the generated tests are slower so we need to raise the timeout. If this doesn't help we need to investigate more. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4763) interface "any" tag not working as expected

by Yann Le Tallec (Jira)

[ https://issues.jboss.org/browse/WFCORE-4763?page=com.atlassian.jira.plugi... ] Yann Le Tallec edited comment on WFCORE-4763 at 11/27/19 10:11 AM: ------------------------------------------------------------------- Thank you for your comment. The doc says "Attribute indicating that part of the selection criteria for choosing an IP address for this interface should be that *the IP address meets at least one of a nested set of criteria, but not necessarily all of the nested criteria*." So it seems to me that connections from any of the addresses inside any should be accepted. In the end my goal is simple: I want the management interface to be accessible from localhost and the local network. So I tried: <any> <inet-address value="127.0.0.1"> <subnet-match value="10.20.0.0/16"> </any> but that doesn't work as explained in the issue. If you have a workaround I'm happy to try it. was (Author: assylias): Thank you for your comment. The doc says "Attribute indicating that part of the selection criteria for choosing an IP address for this interface should be that ***the IP address meets at least one of a nested set of criteria, but not necessarily all of the nested criteria***." So it seems to me that connections from any of the addresses inside any should be accepted. In the end my goal is simple: I want the management interface to be accessible from localhost and the local network. So I tried: <any> <inet-address value="127.0.0.1"> <subnet-match value="10.20.0.0/16"> </any> but that doesn't work as explained in the issue. If you have a workaround I'm happy to try it. > interface "any" tag not working as expected > ------------------------------------------- > > Key: WFCORE-4763 > URL: https://issues.jboss.org/browse/WFCORE-4763 > Project: WildFly Core > Issue Type: Bug > Components: Management > Environment: Ubuntu 18.02 > Reporter: Yann Le Tallec > Priority: Major > > The {{<any>}} tag in the {{interface}} configuration of {{standalone.xml}} should accept any connection that matches ANY of the provided rules. This is not the case as demonstrated by the example below. > This configuration allows to run {{jboss-cli.sh -c}} from the machine where wildfly is running as expected: > {code:xml} > <interfaces> > <interface name="management"> > <any> > <inet-address value="127.0.0.1"/> > </any> > </interface> > </interfaces> > {code} > But if I add another (VALID) IP address inside the any tag, I can't connect any more: > {code:xml} > <interfaces> > <interface name="management"> > <any> > <inet-address value="127.0.0.1"/> > <inet-address value="10.20.230.26"/> > </any> > </interface> > </interfaces> > {code} > With the latter configuration, {{connect}} fails with the following error: > {noformat} > >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 > {noformat} > Note: to easily reproduce the problem from the cli, starting from a fresh standalone install: > {code:bash} > connect > /interface=management:undefine-attribute(name=inet-address) > /interface=management:undefine-attribute(name=any) > /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1]}) > reload > /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1,10.20.230.26]}) > reload > {code} > Notes: > - 10.20.230.26 must be a reachable IP - if I use a random one I can connect normally. > - if I use {{subnet-match}} I get the same issue -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4763) interface "any" tag not working as expected

by Yann Le Tallec (Jira)

[ https://issues.jboss.org/browse/WFCORE-4763?page=com.atlassian.jira.plugi... ] Yann Le Tallec commented on WFCORE-4763: ---------------------------------------- Thank you for your comment. The doc says "Attribute indicating that part of the selection criteria for choosing an IP address for this interface should be that ***the IP address meets at least one of a nested set of criteria, but not necessarily all of the nested criteria***." So it seems to me that connections from any of the addresses inside any should be accepted. In the end my goal is simple: I want the management interface to be accessible from localhost and the local network. So I tried: <any> <inet-address value="127.0.0.1"> <subnet-match value="10.20.0.0/16"> </any> but that doesn't work as explained in the issue. If you have a workaround I'm happy to try it. > interface "any" tag not working as expected > ------------------------------------------- > > Key: WFCORE-4763 > URL: https://issues.jboss.org/browse/WFCORE-4763 > Project: WildFly Core > Issue Type: Bug > Components: Management > Environment: Ubuntu 18.02 > Reporter: Yann Le Tallec > Priority: Major > > The {{<any>}} tag in the {{interface}} configuration of {{standalone.xml}} should accept any connection that matches ANY of the provided rules. This is not the case as demonstrated by the example below. > This configuration allows to run {{jboss-cli.sh -c}} from the machine where wildfly is running as expected: > {code:xml} > <interfaces> > <interface name="management"> > <any> > <inet-address value="127.0.0.1"/> > </any> > </interface> > </interfaces> > {code} > But if I add another (VALID) IP address inside the any tag, I can't connect any more: > {code:xml} > <interfaces> > <interface name="management"> > <any> > <inet-address value="127.0.0.1"/> > <inet-address value="10.20.230.26"/> > </any> > </interface> > </interfaces> > {code} > With the latter configuration, {{connect}} fails with the following error: > {noformat} > >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 > {noformat} > Note: to easily reproduce the problem from the cli, starting from a fresh standalone install: > {code:bash} > connect > /interface=management:undefine-attribute(name=inet-address) > /interface=management:undefine-attribute(name=any) > /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1]}) > reload > /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1,10.20.230.26]}) > reload > {code} > Notes: > - 10.20.230.26 must be a reachable IP - if I use a random one I can connect normally. > - if I use {{subnet-match}} I get the same issue -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2019