May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-253) Add validation for bookinfo and mesh in checker script

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-253?page=com.atlassian.jira.plugin.... ] Matt Mahoney reassigned SWSQE-253: ---------------------------------- Assignee: Matt Mahoney (was: Sunil kondkar) > Add validation for bookinfo and mesh in checker script > ------------------------------------------------------ > > Key: SWSQE-253 > URL: https://issues.jboss.org/browse/SWSQE-253 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Sunil kondkar > Assignee: Matt Mahoney > > Current script validates if istio and kiali is up. Task is for adding validation for bookinfo and mesh -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-247) Add kiali route check in checker script

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-247?page=com.atlassian.jira.plugin.... ] Matt Mahoney reassigned SWSQE-247: ---------------------------------- Assignee: Matt Mahoney (was: Sunil kondkar) > Add kiali route check in checker script > --------------------------------------- > > Key: SWSQE-247 > URL: https://issues.jboss.org/browse/SWSQE-247 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Sunil kondkar > Assignee: Matt Mahoney > > Add kiali route check in checker script and use curl to validate that the URL is accessible > curl --insecure https://admin:admin@kiali-istio-system.ose.os39-kiali.osoos.centralci.eng... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-206) Investegate b21 Docker Failures

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-206?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-206: ------------------------------- Summary: Investegate b21 Docker Failures (was: Investegate b21 & b12 Docker Failures) Team: Infrastructure (was: Infrastructure) b12 was reinstalled, thus may no longer be an issue. b21, needs further investegration > Investegate b21 Docker Failures > ------------------------------- > > Key: SWSQE-206 > URL: https://issues.jboss.org/browse/SWSQE-206 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > Priority: Minor > > Docker periodical needs to be restarted, which is causing pod failures. This issue appears to have started when clusters were upgraded to OS3.9. > Investigate reason for failures. Resolve if at all possible. > Temp work-around: > 1) Restart docker service > 2) Reboot instance if #1 failed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-206) Investegate b21 Docker Failures

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-206?page=com.atlassian.jira.plugin.... ] Matt Mahoney reassigned SWSQE-206: ---------------------------------- Assignee: Filip Brychta (was: Michael Foley) > Investegate b21 Docker Failures > ------------------------------- > > Key: SWSQE-206 > URL: https://issues.jboss.org/browse/SWSQE-206 > Project: Kiali QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Filip Brychta > Priority: Minor > > Docker periodical needs to be restarted, which is causing pod failures. This issue appears to have started when clusters were upgraded to OS3.9. > Investigate reason for failures. Resolve if at all possible. > Temp work-around: > 1) Restart docker service > 2) Reboot instance if #1 failed -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-223) Investigate Python REST Test Failures

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-223?page=com.atlassian.jira.plugin.... ] Matt Mahoney resolved SWSQE-223. -------------------------------- Resolution: Done > Investigate Python REST Test Failures > ------------------------------------- > > Key: SWSQE-223 > URL: https://issues.jboss.org/browse/SWSQE-223 > Project: Kiali QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Matt Mahoney > > For instance this failure: http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/run-python-rest-... > Whether it is test or infrastructure problem? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-182) Validate that Istio was succesfully deployed

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-182?page=com.atlassian.jira.plugin.... ] Matt Mahoney resolved SWSQE-182. -------------------------------- Resolution: Done > Validate that Istio was succesfully deployed > -------------------------------------------- > > Key: SWSQE-182 > URL: https://issues.jboss.org/browse/SWSQE-182 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-183) Validate that Kiali was successfully deployed

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-183?page=com.atlassian.jira.plugin.... ] Matt Mahoney resolved SWSQE-183. -------------------------------- Resolution: Done > Validate that Kiali was successfully deployed > --------------------------------------------- > > Key: SWSQE-183 > URL: https://issues.jboss.org/browse/SWSQE-183 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-263) Kiali Istio Checker Job may not be working

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-263?page=com.atlassian.jira.plugin.... ] Matt Mahoney reassigned SWSQE-263: ---------------------------------- Assignee: Matt Mahoney > Kiali Istio Checker Job may not be working > ------------------------------------------- > > Key: SWSQE-263 > URL: https://issues.jboss.org/browse/SWSQE-263 > Project: Kiali QE > Issue Type: Bug > Reporter: Guilherme Baufaker Rêgo > Assignee: Matt Mahoney > > I think Kiali Istio Checker is not running fine > http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Chec... > Running > Current istio-ca pod status : Running > scripts/kiali/testscript.sh: line 55: [: too many arguments -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1587) X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3]

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1587?page=com.atlassian.jira.plugin.s... ] Martin Choma commented on ELY-1587: ----------------------------------- I have attached reproducing certificate > X500 principal [CN=client] was not decoded - no values of attribute [2.5.4.3] > ----------------------------------------------------------------------------- > > Key: ELY-1587 > URL: https://issues.jboss.org/browse/ELY-1587 > Project: WildFly Elytron > Issue Type: Bug > Components: Certificate Authority, X.500 > Affects Versions: 1.3.2.Final > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.4.0.CR1 > > Attachments: client.asn1, client.cer > > > Debugging revealed certificate use {{utf8String}} representation whereas Elytron is expecting {{printableString}} > In rfc 5280 [1] chapter 4.1.2.4. Issuer there is specified value of subject/issuer can be of 5 types > {code} > DirectoryString ::= CHOICE { > teletexString TeletexString (SIZE (1..MAX)), > printableString PrintableString (SIZE (1..MAX)), > universalString UniversalString (SIZE (1..MAX)), > utf8String UTF8String (SIZE (1..MAX)), > bmpString BMPString (SIZE (1..MAX)) } > {code} > However Elytron X500 principal decoder [2] can handle only 2 of them PRINTABLE_STRING_TYPE and IA5_STRING_TYPE (not sure which type of rfc does that match) [2] > Definitely missing {{utf8String}} (my case). Also revise for backward compatibility {{teletexString}}, {{bmpString}} and {{universalString}} > [1] https://www.ietf.org/rfc/rfc5280.txt > [2] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10463) Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10463?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-10463: ------------------------------------- [~mjurc] I have not yet run your reproducer, but wanted to clarify some misunderstandings about the expected behavior first. Setting the affinity for a @Stateful EJB should control on which node the EJB is initially created. However, the server may update the client at any time with a new weak affinity if the primary ownership of the given EJB changes, in response to a deploy/undeploy of the application containing the EJB on any node in the associated cluster. This has been the behavior ever since WF8. > Weak affinity set up by EJB client 4 is not followed with invocations running against stateful bean deploment on WildFly 13 > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10463 > URL: https://issues.jboss.org/browse/WFLY-10463 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 13.0.0.Beta1 > Environment: WildFly 13 beta runtimes. EJB client version does not matter (tested with {{org.wildfly:wildfly-ejb-client-bom:12.0.0.Final}}). > Reporter: Michal Jurc > Assignee: Paul Ferraro > Priority: Blocker > Attachments: repro.zip > > > Remote EJB client with {{InitialContext}} setting up weak affinity will not hold up the affinity, resulting in a behaviour that's different to previous releases of WildFly. In previous versions of WildFly, {{java.naming.provider.url}} property of {{InitialContext}} was enough to enforce weak affinity to a node in remote EJB client. > This is a regression compared to WildFly 12. The client version does not change the behaviour, which leads me to believe the issue is server-side. > Update: The issue affects only stateful bean invocations. > {code} > while (true) { > try { > final Properties props = new Properties(); > props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName()); > props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080"); > final InitialContext ejbCtx = new InitialContext(props); > final HelloBeanRemote bean = (HelloBeanRemote) ejbCtx > .lookup("ejb:/server/HelloBean!" + HelloBeanRemote.class.getName() + "?stateful"); > for (int i = 0; i < 10; i++) { > System.out.println(bean.hello()); > } > } catch(Exception e) { > System.out.println("Call failed!!!!"); > e.printStackTrace(); > } > final Properties props = new Properties(); > props.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName()); > props.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080"); > {code} > {code}11:56:02,452 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 0 > 11:56:02,460 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 1 > 11:56:02,465 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 2 > 11:56:02,472 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 3 > 11:56:02,477 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 4 > 11:56:02,488 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 5 > 11:56:02,496 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 6 > 11:56:02,502 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 7 > 11:56:02,507 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 8 > 11:56:02,515 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node1"): > node1, 9 > 11:56:03,535 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 0 > 11:56:03,544 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 1 > 11:56:03,555 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 2 > 11:56:03,561 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 3 > 11:56:03,568 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 4 > 11:56:03,586 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 5 > 11:56:03,595 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 6 > 11:56:03,602 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 7 > 11:56:03,616 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 8 > 11:56:03,628 DEBUG [org.jboss.ejb.client.EJBInvocationHandler:164] Calling invoke(module = /server/HelloBean, strong affinity = Cluster "ejb", weak affinity = Node "node2"): > node2, 9 > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 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 May 2018