July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-899) Create plan document

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-899?page=com.atlassian.jira.plugin.... ] Filip Brychta edited comment on SWSQE-899 at 7/31/19 9:02 AM: -------------------------------------------------------------- Doc: https://docs.google.com/document/d/1QRABnGYjgG9J0_QImiMPA78uL8NXmjLJbV864... was (Author: fbrychta): Doc: > Create plan document > -------------------- > > Key: SWSQE-899 > URL: https://issues.jboss.org/browse/SWSQE-899 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Critical > Labels: infrastructure > > Which steps we need to take before outage, after outage? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-899) Create plan document

by Filip Brychta (Jira)

Filip Brychta created SWSQE-899: ----------------------------------- Summary: Create plan document Key: SWSQE-899 URL: https://issues.jboss.org/browse/SWSQE-899 Project: Kiali QE Issue Type: Sub-task Reporter: Filip Brychta Assignee: Filip Brychta Which steps we need to take before outage, after outage? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-898) Prepare for BOS lab outage

by Filip Brychta (Jira)

Filip Brychta created SWSQE-898: ----------------------------------- Summary: Prepare for BOS lab outage Key: SWSQE-898 URL: https://issues.jboss.org/browse/SWSQE-898 Project: Kiali QE Issue Type: Story Reporter: Filip Brychta Assignee: Filip Brychta There is an outage scheduled on Tuesday, August 20th and Wednesday the 21st. This outage will affect jon/kiali qe infrastructure and following systems will not be accessible: - https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/ - http://jenkins.jonqe.lab.eng.bos.redhat.com:9080/ - https://foreman.jonqe.lab.eng.bos.redhat.com - https://rhevm.jonqe.lab.eng.bos.redhat.com - all Dell system b01 -- b25 For JON it means following: - no provisioning via foreman - no jenkins jobs For kiali it means following: - no jenkins jobs (PR testing, nightly testing, provisioning of ocp4 in PSI, ...) - ocp 3.11 clusters in bladecenter will not be available - ocp 4 clusters in PSI will not be affected so manual testing will be possible but automatic provisioning of new cluster will not be available (jenkins will be down) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1858) Create Three new shaded jars elytron-common, elytron-acme, and elytron-password

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1858: ------------------------------------- Summary: Create Three new shaded jars elytron-common, elytron-acme, and elytron-password Key: ELY-1858 URL: https://issues.jboss.org/browse/ELY-1858 Project: WildFly Elytron Issue Type: Task Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.0.Alpha5 These are for use by Quarkus bundling together some of the common dependencies. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-167) EAP Operator handling ConfigMap internally

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-167?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFWIP-167: ------------------------------------ Isn't this externalizing configuration denying infrastucture immutability concept? So far we have overriding feature in s2i [1], but that keep infrastructure immutability pattern. But current Operator does not have s2i support. Also note as there will be only one Operator at a time, we cant remove StandaloneConfigMapSpec, when s2i will be part of operator. So now question is is it worth adding it in current state? [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... > EAP Operator handling ConfigMap internally > ------------------------------------------ > > Key: WFWIP-167 > URL: https://issues.jboss.org/browse/WFWIP-167 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Major > > If I understand description in [1] correctly. To specify custom standalone.xml I have to create ConfigMap with standalone.xml first and afterwards link operator to this ConfigMap. > Is it possible to handle creation of ConfigMap and storing standalone.xml for me? Ideally I just specify file URI where custom standalone.xml is located. This location have to be accessible from operator pod. In this way we can look at it as hiding internals (implementation details) from users. > Currently when user wants to change standalone.xml he does in ConfigMap, not operator. When changing standalone.xml through config map, I assume pod have to be restarted manually. Operator could do that for me. > However this can be triggered by storing newer version of standalone.xml under another key, eg `standalone.xml.v2` and changing `StandaloneConfigMapSpec.key` in operator. > What do you think? Have you considered this approach? > [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#sta... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4587) Clarify description of 'maximum-cert-path'

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4587?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-4587: ---------------------------------------- Assignee: Jan Stourac (was: Darran Lofthouse) > Clarify description of 'maximum-cert-path' > ------------------------------------------ > > Key: WFCORE-4587 > URL: https://issues.jboss.org/browse/WFCORE-4587 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Jan Stourac > Priority: Trivial > Fix For: 10.0.0.Beta3 > > > Trivial extension of 'maximum-cert-path' attribute of trust-manager to give message when this value actually takes any effect - only if OCSP or CRL are configured. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4587) Clarify description of 'maximum-cert-path'

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4587?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-4587: ------------------------------------- Fix Version/s: 10.0.0.Beta3 > Clarify description of 'maximum-cert-path' > ------------------------------------------ > > Key: WFCORE-4587 > URL: https://issues.jboss.org/browse/WFCORE-4587 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta2 > Reporter: Jan Stourac > Assignee: Jan Stourac > Priority: Trivial > Fix For: 10.0.0.Beta3 > > > Trivial extension of 'maximum-cert-path' attribute of trust-manager to give message when this value actually takes any effect - only if OCSP or CRL are configured. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2362) Providing logical member name in JDBC_PING

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2362?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2362: -------------------------------- I fail to understand what your problem is. Can you illustrate this with a setp-by-step example? > Providing logical member name in JDBC_PING > ------------------------------------------ > > Key: JGRP-2362 > URL: https://issues.jboss.org/browse/JGRP-2362 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.17, 4.0.18, 4.0.19, 4.1.0, 4.0.20 > Reporter: S Pokutniy > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.2 > > > When using JDBC_PING and logical names instead of UUIDs and one of the cluster member crashes or get killed and this member is not coordinator then its database set still remains in the database as long as coordinator changes (independently from remove_old_coords_on_view_change /remove_all_data_on_view_change). If the the cluster is then restarted the old dataset makes connect() much slower (+30 seconds), as the members seem to be tryting to connect to it. Parameter remove_all_data_on_view_change seems to be the solution but it does not work as long as coordinator does not change, so practically the same as remove_old_coords_on_view_change. > The only solution seems to be to provide an appropriate delete statement in parameter initialize_sql, which would delete old entry, for example like this: delete from JGROUPSPING where ping_data like '%logical name%'. However, this is neither really quick nor the ideal solution, as ping_data's datatype is bytea or bit varying. > It would be great to have also logical name in JGROUPSPING, which is instead per default in insert(). This is also easy to implement as there is access to this information in PingData. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2361) Error related to Jgroup and Database connection is getting reset

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2361?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2361 at 7/31/19 7:09 AM: --------------------------------------------------------- Could be that you're running different versions of JGroups (cookie sent by /172.26.235.231:43565 does not match own cookie; terminating connection). What's your JGroups config (jgroups-tcp.xml)? was (Author: belaban): Could be that you're running different versions of JGroups (cookie sent by /172.26.235.231:43565 does not match own cookie; terminating connection). What's your JGroups config? > Error related to Jgroup and Database connection is getting reset > ---------------------------------------------------------------- > > Key: JGRP-2361 > URL: https://issues.jboss.org/browse/JGRP-2361 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.11 > Environment: Hybris running on tomcat - Centos 7 > Reporter: karthikeyan Aruljothi > Assignee: Bela Ban > Priority: Major > Attachments: Jgroup error in preprod-000.txt, Jgroups blocking and terminating connection.txt, Jgroups error in console.txt, error Jgroups.txt > > > Hi , > we are facing an issue with our cluster configuration and due to this JVM responding time also takes more time, after clearing the cache / restarting all nodes application works as expected. > When issue arises one of the core occupies 100% cpu utilization then it confirms to restart the server otherwise it never process any request. Below is our configuration in local.properties. Also providing error logs as attachment. could see error in logs related to Jgroups blocking and connection getting terminated between nodes. > Let us know your valuable inputs, on what exactly the issue i.e causing the slowness then blocking the whole server. > Attached cluster configuration for each nodes and error logs > Adding to this we are getting below error while doing deployment/restarting of servers > WARN [localhost-startStop-1] [GMS] hybrisnode-0: JOIN(hybrisnode-0) sent to hybrisnode-2 timed out (after 3000 ms), on try 3 > WARN [pool-3-thread-1] [GMS] hybrisnode-3: JOIN(hybrisnode-3) sent to hybrisnode-1 timed out (after 3000 ms), on try 4 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2361) Error related to Jgroup and Database connection is getting reset

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2361?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2361: -------------------------------- Could be that you're running different versions of JGroups (cookie sent by /172.26.235.231:43565 does not match own cookie; terminating connection). What's your JGroups config? > Error related to Jgroup and Database connection is getting reset > ---------------------------------------------------------------- > > Key: JGRP-2361 > URL: https://issues.jboss.org/browse/JGRP-2361 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.11 > Environment: Hybris running on tomcat - Centos 7 > Reporter: karthikeyan Aruljothi > Assignee: Bela Ban > Priority: Major > Attachments: Jgroup error in preprod-000.txt, Jgroups blocking and terminating connection.txt, Jgroups error in console.txt, error Jgroups.txt > > > Hi , > we are facing an issue with our cluster configuration and due to this JVM responding time also takes more time, after clearing the cache / restarting all nodes application works as expected. > When issue arises one of the core occupies 100% cpu utilization then it confirms to restart the server otherwise it never process any request. Below is our configuration in local.properties. Also providing error logs as attachment. could see error in logs related to Jgroups blocking and connection getting terminated between nodes. > Let us know your valuable inputs, on what exactly the issue i.e causing the slowness then blocking the whole server. > Attached cluster configuration for each nodes and error logs > Adding to this we are getting below error while doing deployment/restarting of servers > WARN [localhost-startStop-1] [GMS] hybrisnode-0: JOIN(hybrisnode-0) sent to hybrisnode-2 timed out (after 3000 ms), on try 3 > WARN [pool-3-thread-1] [GMS] hybrisnode-3: JOIN(hybrisnode-3) sent to hybrisnode-1 timed out (after 3000 ms), on try 4 -- This message was sent by Atlassian Jira (v7.12.1#712002)

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