November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-992) UI automation - implement login via OCP login page

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-992?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan commented on SWSQE-992: -------------------------------------- Actually UI automation for Kiali uses now OC token in a URL which makes auto login. > UI automation - implement login via OCP login page > -------------------------------------------------- > > Key: SWSQE-992 > URL: https://issues.jboss.org/browse/SWSQE-992 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Priority: Major > Labels: automation > > Kiali use to have it's own login page which is still implemented in our automation. We need to update it to use OCP login page instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-966) UI Automations - Check Traces tab functionality

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-966?page=com.atlassian.jira.plugin.... ] Hayk Hovsepyan updated SWSQE-966: --------------------------------- Sprint: Kiali Sprint #28, Kiali Sprint #30 (was: Kiali Sprint #28) > UI Automations - Check Traces tab functionality > ----------------------------------------------- > > Key: SWSQE-966 > URL: https://issues.jboss.org/browse/SWSQE-966 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > Traces tab of Kiali is not automated in UI Automations framework. > We need to automate: > 1. Traces menu clicking and verifying the opened page. > 2. Traces tab. Click, no errors, no login asked. > 3. Search Traces in Traces tab. Verify that it shows traces or a message that traces does not exist. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1000) Apply AI in Health and Status validations when possible.

by Hayk Hovsepyan (Jira)

[ https://issues.jboss.org/browse/SWSQE-1000?page=com.atlassian.jira.plugin... ] Hayk Hovsepyan updated SWSQE-1000: ---------------------------------- Sprint: Kiali Sprint #30 > Apply AI in Health and Status validations when possible. > -------------------------------------------------------- > > Key: SWSQE-1000 > URL: https://issues.jboss.org/browse/SWSQE-1000 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > > For instance TRAFFIC column in Traffic tab. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2396) increasing networkdata, cpu and heap

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2396?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2396: -------------------------------- There are many components involved; what makes you think this is caused by JGroups? To look into this, I need * Configuration * Heap dump, thread dump. Best would be JFR dumps that show CPU and heap usage > increasing networkdata, cpu and heap > ------------------------------------ > > Key: JGRP-2396 > URL: https://issues.jboss.org/browse/JGRP-2396 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.19 > Reporter: Rob van der Boom > Assignee: Bela Ban > Priority: Major > > hey, > we have an keycloak (sso) setup, version 7.0.1 running in kubernetes - aws. > Its build on wildfly 17, infinispan 9.4 and jgroups 4.0.19. > We have 3 pods running in standalone-ha with cache setup on distribution (all 3 nodes - so equivalent to replication) > ISSUE: > We see a slowly growing of networkstatistics, heap and cpu, while the number of sessions in keycloak (cached) remain almost stable. > The cpu growth is caused by the TQbundler process, which explaines the networkdata growth. It looks like this is causing also a memory leakage.. > every 5 days we have to restart the pods and then every resets to a very low level including the heap. this while all sessions are still valid and cached. > The only issue i could find maybe related to this is: > https://issues.jboss.org/browse/JGRP-2382?jql=project%20%3D%20JGRP%20AND%... > Could this be the same issue and does it also cause increasing network and cpu (since that is why we have to restart, the heap has much space left !). > And if so how does this issue continue since for us its a major issue. > We als had this issue already in keycloak 5 (wildfly 15), thats why we upgraded to the latest available version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2382) JGroups version 4.0.13.Final.jar is causing memory leaks

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2382?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-2382. -------------------------- Resolution: Out of Date Reopen with a reproducer > JGroups version 4.0.13.Final.jar is causing memory leaks > -------------------------------------------------------- > > Key: JGRP-2382 > URL: https://issues.jboss.org/browse/JGRP-2382 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.13 > Environment: AIX machine 7.1 with JDK 1.8 > Reporter: Rashmi Acharya > Assignee: Bela Ban > Priority: Major > Attachments: dumps_TEST_node1_20190918_after_3_hours.zip, dumps_TEST_node1_20190918_right_after_restart.zip, dumps_TEST_node2_20190918_after_3_hours.zip, dumps_TEST_node2_20190918_right_after_restart.zip > > > We are observing a constant memory growth and leak with JGroup version 4.0.13 .. > One of our customer is having two node cluster environment and in one node we are observing org.Group.Messages which contain org.groups.Header and org.groups.Stack.ipAddress objects.. these are not getting cleared from memory.. > We dont see any exception related to Jgroups from logs and but it is causing a gradual emory growth and OOM. > Here is the Jgroups cluster configuration we have: > dynamic.cluster.property_string > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> > <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT2;"/> > <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/> > <MERGE3 min_interval="3000" max_interval="5000" /> > <FD_ALL timeout="20000" interval="15000"/> > <FD_SOCK/> > <FD timeout="5000" max_tries="48" /> > <VERIFY_SUSPECT timeout="1500"/> > <BARRIER/> > <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> > <UNICAST3/> > <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000"/> > <pbcast.GMS print_local_addr="true" join_timeout="15000" /> > </config> > ================================= > dynamic.cluster.distribution_property_string > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> > <TCP bind_port="&MULTICAST_NODE_PORT1;" /> > <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/> > <MERGE3 min_interval="3000" max_interval="5000"/> > <FD_SOCK/> > <FD timeout="5000" max_tries="48"/> > <VERIFY_SUSPECT timeout="1500"/> > <BARRIER/> > <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> > <UNICAST3/> > <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000" /> > <pbcast.GMS print_local_addr="true" join_timeout="5000"/> > </config> > ================================ > dynamic.cluster.lock.protocolStack > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> > <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT3;"/> > <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/> > <MERGE3 min_interval="3000" max_interval="5000"/> > <FD_ALL timeout="20000" interval="5000"/> > <FD timeout="5000" max_tries="48"/> > <VERIFY_SUSPECT timeout="1500"/> > <BARRIER/> > <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> > <UNICAST3 /> <pbcast.STABLE desired_avg_gossip="20000" /> > <pbcast.GMS print_local_addr="true" join_timeout="5000"/> > <FRAG2 frag_size="8096"/> > <CENTRAL_LOCK2/> > </config> -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-229) Configuring JGroups encryption protocols produces deprecated configuration

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-229?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFWIP-229: ------------------------------------ [~yersan] this new "non-deprecated" way is it tracked somewhere as RFE? I havent found any. In documentation we have documented only one way [1], which you call "deprecated". [1] https://doc-stage.usersys.redhat.com/documentation/en-us/jboss_enterprise... > Configuring JGroups encryption protocols produces deprecated configuration > -------------------------------------------------------------------------- > > Key: WFWIP-229 > URL: https://issues.jboss.org/browse/WFWIP-229 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Environment: The example has been produced with the following S2I environment variables: > {code} > OPENSHIFT_DNS_PING_SERVICE_NAME=ping-service > JGROUPS_ENCRYPT_PROTOCOL=ASYM_ENCRYPT > JGROUPS_CLUSTER_PASSWORD=foobar123 > OPENSHIFT_DNS_PING_SERVICE_PORT=8888 > JGROUPS_PING_PROTOCOL=dns.DNS_PING > SCRIPT_DEBUG=true > {code} > Reporter: Michal Jurc > Assignee: Yeray Borges > Priority: Critical > > Any S2I configuration of ping protocols utilising encryption for protocols will result in deprecated configuration. S2I should not configure runtime to deprecated configuration by default, unless the user chooses to. > {code:title=Example JGroups ASYM_ENCRYPT configuration} > [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=org.jgroups.protocols.ASYM_ENCRYPT:read-resource-description > { > "outcome" => "success", > "result" => { > "description" => "The configuration of a protocol within a protocol stac > k.", > "capabilities" => [{ > "name" => "org.wildfly.clustering.jgroups.protocol", > "dynamic" => true, > "dynamic-elements" => [ > "stack", > "protocol" > ] > }], > "deprecated" => { > "since" => "5.0.0", > "reason" => "Deprecated. Use protocol=ASYM_ENCRYPT instead." > }, > "attributes" => { > "module" => { > "type" => STRING, > "description" => "The module with which to resolve the protocol > type.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => "org.jgroups", > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "properties" => { > "type" => OBJECT, > "description" => "The properties of this protocol.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "socket-binding" => { > "type" => STRING, > "description" => "Defines the bind address/port used of the serv > er socket used to receive messages from other cluster members.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "deprecated" => { > "since" => "5.0.0", > "reason" => "Deprecated. Supports EAP 7.0 slaves." > }, > "access-type" => "read-only", > "storage" => "configuration" > }, > "statistics-enabled" => { > "type" => BOOLEAN, > "description" => "Indicates whether or not this protocol will co > llect statistics overriding stack configuration.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > }, > "operations" => undefined, > "notifications" => undefined, > "children" => {"property" => { > "description" => "A JGroups protocol property.", > "model-description" => undefined > }} > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1000) Apply AI in Health and Status validations when possible.

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1000: ------------------------------------- Summary: Apply AI in Health and Status validations when possible. Key: SWSQE-1000 URL: https://issues.jboss.org/browse/SWSQE-1000 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan For instance TRAFFIC column in Traffic tab. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2396) increasing networkdata, cpu and heap

by Rob van der Boom (Jira)

Rob van der Boom created JGRP-2396: -------------------------------------- Summary: increasing networkdata, cpu and heap Key: JGRP-2396 URL: https://issues.jboss.org/browse/JGRP-2396 Project: JGroups Issue Type: Bug Affects Versions: 4.0.19 Reporter: Rob van der Boom Assignee: Bela Ban hey, we have an keycloak (sso) setup, version 7.0.1 running in kubernetes - aws. Its build on wildfly 17, infinispan 9.4 and jgroups 4.0.19. We have 3 pods running in standalone-ha with cache setup on distribution (all 3 nodes - so equivalent to replication) ISSUE: We see a slowly growing of networkstatistics, heap and cpu, while the number of sessions in keycloak (cached) remain almost stable. The cpu growth is caused by the TQbundler process, which explaines the networkdata growth. It looks like this is causing also a memory leakage.. every 5 days we have to restart the pods and then every resets to a very low level including the heap. this while all sessions are still valid and cached. The only issue i could find maybe related to this is: https://issues.jboss.org/browse/JGRP-2382?jql=project%20%3D%20JGRP%20AND%... Could this be the same issue and does it also cause increasing network and cpu (since that is why we have to restart, the heap has much space left !). And if so how does this issue continue since for us its a major issue. We als had this issue already in keycloak 5 (wildfly 15), thats why we upgraded to the latest available version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12685) Update Microprofile Health to 2.1

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFLY-12685?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-12685: ------------------------------- Summary: Update Microprofile Health to 2.1 (was: Update Microprofile Health to 2.1.0 ) > Update Microprofile Health to 2.1 > --------------------------------- > > Key: WFLY-12685 > URL: https://issues.jboss.org/browse/WFLY-12685 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Health > Reporter: Tobias Stadler > Assignee: Jeff Mesnil > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-981) OCP 4.2 provisioning broken due to network issues

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-981?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-981. --------------------------------- Resolution: Done It was caused by problem in PSI openstack. https://redhat.service-now.com/surl.do?n=PNT0687777 It's still not resolved fully but it's not happening very often, still waiting for https://access.redhat.com/support/cases/#/case/02499913 > OCP 4.2 provisioning broken due to network issues > ------------------------------------------------- > > Key: SWSQE-981 > URL: https://issues.jboss.org/browse/SWSQE-981 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Blocker > Labels: infrastructure > > Provisioning of OCP 4.2 is not working. Not clear why yet. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 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 November 2019