March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-536) [RS] Prototype Automation Test Runs Into Polarion

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-536?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-536: ------------------------------- Attachment: junit-output.xml > [RS] Prototype Automation Test Runs Into Polarion > ------------------------------------------------- > > Key: SWSQE-536 > URL: https://issues.jboss.org/browse/SWSQE-536 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Major > Attachments: junit-output.xml, kiali-0.15.0_signed-output.xml > > > What is the mechanism to import automation runs into Polarion. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-536) [RS] Prototype Automation Test Runs Into Polarion

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-536?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-536: ------------------------------- Attachment: kiali-0.15.0_signed-output.xml > [RS] Prototype Automation Test Runs Into Polarion > ------------------------------------------------- > > Key: SWSQE-536 > URL: https://issues.jboss.org/browse/SWSQE-536 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Major > Attachments: kiali-0.15.0_signed-output.xml > > > What is the mechanism to import automation runs into Polarion. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-536) [RS] Prototype Automation Test Runs Into Polarion

by Yuanlin Xu (Jira)

[ https://issues.jboss.org/browse/SWSQE-536?page=com.atlassian.jira.plugin.... ] Yuanlin Xu commented on SWSQE-536: ---------------------------------- [~mmahoney] Hi Matt, do we have one sample junitxml test output ? we can work from one sample to prove an importer is working and then process the rest of the junitxml suites. > [RS] Prototype Automation Test Runs Into Polarion > ------------------------------------------------- > > Key: SWSQE-536 > URL: https://issues.jboss.org/browse/SWSQE-536 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > What is the mechanism to import automation runs into Polarion. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-536) [RS] Prototype Automation Test Runs Into Polarion

by Matt Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-536?page=com.atlassian.jira.plugin.... ] Matt Mahoney commented on SWSQE-536: ------------------------------------ [~yuaxu] Kiali UI and E2E (REST) suites are Python and thus have the option of using Pytest --junitxml, which in the past is what was used for importing automation runs into Polarion. Instead of modifying our automation scripts, an option may be to write a Pylarion importer (of sorts) that will leverage the Pytest --junitxml suite run output. > [RS] Prototype Automation Test Runs Into Polarion > ------------------------------------------------- > > Key: SWSQE-536 > URL: https://issues.jboss.org/browse/SWSQE-536 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > What is the mechanism to import automation runs into Polarion. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-163) Hibernate: hibernate.hbm2ddl.auto = validate is very slow

by Laurent Grangier (Jira)

[ https://issues.jboss.org/browse/HIBERNATE-163?page=com.atlassian.jira.plu... ] Laurent Grangier closed HIBERNATE-163. -------------------------------------- Resolution: Migrated to another ITS > Hibernate: hibernate.hbm2ddl.auto = validate is very slow > --------------------------------------------------------- > > Key: HIBERNATE-163 > URL: https://issues.jboss.org/browse/HIBERNATE-163 > Project: Hibernate Integration > Issue Type: Enhancement > Reporter: Laurent Grangier > Assignee: Steve Ebersole > Priority: Major > > I tried to activate the validate mode for project. With a remote database (but within same enterprise network), it needs more than 15 minutes to validate all the entities (I have about 200 entities). > If the DB is running on the same computer, it still needs about 2 minutes to run the validate. > The difference between local and remote DB let me think, the validation process is not performant design and perhaps make way too much DB round-trips. > I would expect the validation process run within seconds or a few minutes (1-2 minutes) even if the DB is remote. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (HIBERNATE-163) Hibernate: hibernate.hbm2ddl.auto = validate is very slow

by Laurent Grangier (Jira)

[ https://issues.jboss.org/browse/HIBERNATE-163?page=com.atlassian.jira.plu... ] Laurent Grangier commented on HIBERNATE-163: -------------------------------------------- Sorry I create the issue in the wrong JIRA domain. Please see https://hibernate.atlassian.net/browse/HHH-13328 > Hibernate: hibernate.hbm2ddl.auto = validate is very slow > --------------------------------------------------------- > > Key: HIBERNATE-163 > URL: https://issues.jboss.org/browse/HIBERNATE-163 > Project: Hibernate Integration > Issue Type: Enhancement > Reporter: Laurent Grangier > Assignee: Steve Ebersole > Priority: Major > > I tried to activate the validate mode for project. With a remote database (but within same enterprise network), it needs more than 15 minutes to validate all the entities (I have about 200 entities). > If the DB is running on the same computer, it still needs about 2 minutes to run the validate. > The difference between local and remote DB let me think, the validation process is not performant design and perhaps make way too much DB round-trips. > I would expect the validation process run within seconds or a few minutes (1-2 minutes) even if the DB is remote. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-536) [RS] Prototype Automation Test Runs Into Polarion

by Yuanlin Xu (Jira)

[ https://issues.jboss.org/browse/SWSQE-536?page=com.atlassian.jira.plugin.... ] Yuanlin Xu commented on SWSQE-536: ---------------------------------- [~gbaufake][~pyadav] It depends on what kind of test automation script we have now. At least, we need a data file(xml, json, yaml or whatever format) which includes each test case name, description, type, priority and other required attributes. And then we can parse those test case attributes from the data file to Pylarion. Pylarion calls will create test cases in Polarion automatically. If this kind of POC works, we can then modify the existing test automation scripts to export those attributes to a data file and trigger the Pylarion call in the end. I will try to prepare a test case creation POC demo from istio side in TP10. I am not sure about test execution results automation. That is still under investigation. > [RS] Prototype Automation Test Runs Into Polarion > ------------------------------------------------- > > Key: SWSQE-536 > URL: https://issues.jboss.org/browse/SWSQE-536 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > What is the mechanism to import automation runs into Polarion. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-536) [RS] Prototype Automation Test Runs Into Polarion

by Guilherme Baufaker Rêgo (Jira)

[ https://issues.jboss.org/browse/SWSQE-536?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-536: ----------------------------------------------- [~yuaxu] Pylarion would be ok for that task > [RS] Prototype Automation Test Runs Into Polarion > ------------------------------------------------- > > Key: SWSQE-536 > URL: https://issues.jboss.org/browse/SWSQE-536 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > Priority: Major > > What is the mechanism to import automation runs into Polarion. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11750) Allow cluster to use DNS addresses instead of IP addresses

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11750?page=com.atlassian.jira.plugin... ] Paul Ferraro closed WFLY-11750. ------------------------------- Resolution: Explained > Allow cluster to use DNS addresses instead of IP addresses > ---------------------------------------------------------- > > Key: WFLY-11750 > URL: https://issues.jboss.org/browse/WFLY-11750 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 16.0.0.Beta1 > Reporter: Tomasz Adamski > Assignee: Paul Ferraro > Priority: Major > > We would need a configuration that would allow for the cluster to use DNS addresses instead of IP addresses. The reason is that OpenShift guarantees the node identity under DNS address and not under IP address. > Sample scenario that may currently fail when application are deployed in OpenShift: > A (application) > B (clustered application) > 1. A calls transactional invocation on B > 2. as a result of discovery process A obtains a cluster topology from B and uses one of obtained IP addresses for the connection > 3. as the invocation is transactional the object-store records are written in A's persistent object store; those records are based on the data obtained from the cluster => subordinate node is identified by the IP address from point two > 4. B node fails > 5. OpenShift restarts node B on another IP address > 6. A attempts recovery and persistently fails > OTOH OpenShift guarantees node identity under DNS address. As a result, at point 5 node is guaranteed to restart on established DNS address so if the cluster used this address instead of physical addresses the scenario above will finish with A being able to recover the transaction. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11860) Persistent deployments are lost on restart with '--read-only-server-config'

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11860?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-11860: ----------------------------------------- You can do a reload but not a restart. The point of --read-only-server-config is the configuration you want is locked down, e.g. you have some 'approved' configuration that is controlled by whoever in your org does such approvals and that is what you are meant to use. You're not meant to try and persist changes and have them apply after restart, at least not without effort like starting pointing at a different config file. We do allow you to make config change to a server started with --read-only-server-config. Arguably we should not, but we do. The reason for that is it's reasonable to want to do something that affects config that is operational but not needing permanence, like changing a log level on a running server to get some diagnostic data. If you make other changes that are something you'd want persisted, then that's not an intended use of --read-only-server-config. (There's no practical way to discriminate between changes that are likely something you'd want persisted versus those that are not.) If you do make changes, we persist them in history. The point of that is to allow reload. Arguably we should not support that, but we do. Mostly we do because if you invoke an op that requires reload, the response will state that it requires reload. So then it seemed strange to not allow the reload. An alternative would have been to fail the op if it required reload. Adding a flag to enable that alternative behavior would be a reasonable RFE, as would be a setting to disallow any config changes at all. But those are RFEs as the current behavior is intentional. > Persistent deployments are lost on restart with '--read-only-server-config' > --------------------------------------------------------------------------- > > Key: WFLY-11860 > URL: https://issues.jboss.org/browse/WFLY-11860 > Project: WildFly > Issue Type: Bug > Affects Versions: 13.0.0.Final > Reporter: Maxim Sermin > Assignee: Brian Stansberry > Priority: Major > > I wanted to use the `read-only-server-config` feature in order to be able to have `standalone.xml` managed by configuration management. Additionally, I need the ability to restart Wildfly and have the same state afterwards. Unfortunately, in this case the artefacts that were deployed are not deployed anymore after the restart. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 2019