September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-755) Ask for more storage in PSI

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-755?page=com.atlassian.jira.plugin.... ] Filip Brychta closed SWSQE-755. ------------------------------- Resolution: Duplicate Issue Duplicate of SWSQE-724 > Ask for more storage in PSI > --------------------------- > > Key: SWSQE-755 > URL: https://issues.jboss.org/browse/SWSQE-755 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Minor > Labels: infrastructure > > Minimal ocp 4.1 cluster consumes 200 GB of storage and we only have available 2000GB in istio-dev project so it's for 10 clusters. Count how much more we need and ask for increase. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-732) Migrate Off Of The Blade Center

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-732?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-732: -------------------------------- Priority: Minor (was: Critical) > Migrate Off Of The Blade Center > ------------------------------- > > Key: SWSQE-732 > URL: https://issues.jboss.org/browse/SWSQE-732 > Project: Kiali QE > Issue Type: Story > Reporter: Matthew Mahoney > Priority: Minor > Labels: infrastructure > > Background information causing this Jira: > https://projects.engineering.redhat.com/browse/MWQEINFRA-720 > Embrace 2019 MW QE infrastructure vision > During the QE camp, we (MW infrastructure folks) were approached by DevOps lead architect sharing their interests around evolving MW QE infrastructure in Boston for upcoming years. I would like to reiterate what was suggested to keep MW QE part of the conversation. > Where we are? > Boston hardware lab is going to be consolidated into 3rd party collocation center within a year or so. Nontrivial outage is expected because of that. > Current MW QE hardware in Boston is getting underutilized as majority of workload was moved to central CI. > Baremetal systems (exotic architectures, performance labs, messaging labs) are getting obsolete and unreliable. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-745) Configure b16 for Automatic Sidecar Injection

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-745?page=com.atlassian.jira.plugin.... ] Filip Brychta closed SWSQE-745. ------------------------------- Resolution: Out of Date > Configure b16 for Automatic Sidecar Injection > --------------------------------------------- > > Key: SWSQE-745 > URL: https://issues.jboss.org/browse/SWSQE-745 > Project: Kiali QE > Issue Type: Task > Reporter: Matthew Mahoney > Priority: Minor > Labels: infrastructure > > To be consistent with Maistra installs, change b16 configuration for Automatic side-car injection. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-732) Migrate Off Of The Blade Center

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-732?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-732: ------------------------------------- Lowering priority, we already have OCP clusters in PSI and only remaining load in BOS lab are jenkins slaves, rhev/foreman for JON testing. > Migrate Off Of The Blade Center > ------------------------------- > > Key: SWSQE-732 > URL: https://issues.jboss.org/browse/SWSQE-732 > Project: Kiali QE > Issue Type: Story > Reporter: Matthew Mahoney > Priority: Critical > Labels: infrastructure > > Background information causing this Jira: > https://projects.engineering.redhat.com/browse/MWQEINFRA-720 > Embrace 2019 MW QE infrastructure vision > During the QE camp, we (MW infrastructure folks) were approached by DevOps lead architect sharing their interests around evolving MW QE infrastructure in Boston for upcoming years. I would like to reiterate what was suggested to keep MW QE part of the conversation. > Where we are? > Boston hardware lab is going to be consolidated into 3rd party collocation center within a year or so. Nontrivial outage is expected because of that. > Current MW QE hardware in Boston is getting underutilized as majority of workload was moved to central CI. > Baremetal systems (exotic architectures, performance labs, messaging labs) are getting obsolete and unreliable. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-724) Increase disk space available for PSI

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-724?page=com.atlassian.jira.plugin.... ] Filip Brychta closed SWSQE-724. ------------------------------- Resolution: Rejected 2TB are available for volumes which are needed for persistent data. Currently there is no need to have volumes with persistent data. We can reopen when it's actual again. > Increase disk space available for PSI > ------------------------------------- > > Key: SWSQE-724 > URL: https://issues.jboss.org/browse/SWSQE-724 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Priority: Major > > Currently we only have 2TB of disk allocated on PSI (See https://rhos-d.infra.prod.upshift.rdu2.redhat.com/dashboard/project/) We've already used 700g of this, even though we've used very few of our other resources. > This is very likely to be a problem long term and should be increased. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-610) Move run kiali-e2e jobs to DSL

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-610?page=com.atlassian.jira.plugin.... ] Filip Brychta closed SWSQE-610. ------------------------------- Resolution: Duplicate Issue > Move run kiali-e2e jobs to DSL > ------------------------------ > > Key: SWSQE-610 > URL: https://issues.jboss.org/browse/SWSQE-610 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Matthew Mahoney > Priority: Major > Labels: infrastructure > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-603) Migrate Jenkins2 CI Pipeline to PSI

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-603?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-603: -------------------------------- Summary: Migrate Jenkins2 CI Pipeline to PSI (was: Migrate Jenkins2 CI Pipeline to Central CI ) > Migrate Jenkins2 CI Pipeline to PSI > ------------------------------------ > > Key: SWSQE-603 > URL: https://issues.jboss.org/browse/SWSQE-603 > Project: Kiali QE > Issue Type: Story > Reporter: Matthew Mahoney > Assignee: Matthew Mahoney > Priority: Major > Labels: infrastructure > > QE CI/CP Integration -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-793) Migrate KprodM to PSI Cluster

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-793?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-793: ------------------------------------- Isn't this done already? > Migrate KprodM to PSI Cluster > ----------------------------- > > Key: SWSQE-793 > URL: https://issues.jboss.org/browse/SWSQE-793 > Project: Kiali QE > Issue Type: QE Task > Reporter: Matthew Mahoney > Assignee: Matthew Mahoney > Priority: Major > Labels: infrastructure > > The KProdM cluster is 3.11. Time to migrate to OCP4.1. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-608) QE CI/CP Integration - stage 1

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-608?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-608. --------------------------------- Resolution: Done > QE CI/CP Integration - stage 1 > ------------------------------ > > Key: SWSQE-608 > URL: https://issues.jboss.org/browse/SWSQE-608 > Project: Kiali QE > Issue Type: Story > Reporter: Matthew Mahoney > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > 90 Day QE CI/CP Integration Goals as defined in https://docs.google.com/document/d/13rp2_oEN2fKIskzuqtGB64zWPGBGQR50yMVBU... -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12098) Thread context class loader is wrong for ScheduledExecutorService threads

by Paul Pogonyshev (Jira)

[ https://issues.jboss.org/browse/WFLY-12098?page=com.atlassian.jira.plugin... ] Paul Pogonyshev commented on WFLY-12098: ---------------------------------------- Unfortunately, it's not trivial, as it is deeply embedded in our huge application and further complicated by the fact that the application can run both inside a Web container (WildFly) and outside it, with limited functionality. In pseudocode I could formulate it like this: @WebListener <whatever> { public void contextInitialized (ServletContextEvent event) { use (jndiLookup ("java:comp/DefaultManagedScheduledExecutorService")); } } I'm not 100% sure, but it seems when the listener is informed that context is initialized, not _everything_ is actually initialized yet. In particular, when it tries to use the JNDI-provided ScheduledExecutorService, the service still uses class loader that cannot look up application's classes. At some point later java:comp/DefaultManagedScheduledExecutorService is always replaced with one that uses correct class loader. However, I'm not sure when exactly this happens. > Thread context class loader is wrong for ScheduledExecutorService threads > ------------------------------------------------------------------------- > > Key: WFLY-12098 > URL: https://issues.jboss.org/browse/WFLY-12098 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 16.0.0.Final > Reporter: Paul Pogonyshev > Assignee: Ivo Studensky > Priority: Major > > Tasks submitted to the standard ScheduledExecutorService (JNDI: java:comp/DefaultManagedScheduledExecutorService) are executed in threads with class loader that cannot find application classes. This is a regression in 16.0 compared to 14.0 (haven't tested 15). Tasks submitted to the simple ExecutorService (JNDI: java:comp/DefaultManagedExecutorService) see the correct class loader. > I.e. if I submit something like > () -> { System.out.println (Thread.currentThread ().getContextClassLoader (); } > to both services (i.e. exactly the same task), I get the following output. For ScheduledExecutorService (wrong): > ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @275710fc (finder: local module finder @525f1e4e (roots: [...]/wildfly/modules,[...]/wildfly/modules/system/layers/base)) > For ExecutorService (as expected): > ModuleClassLoader for Module "deployment.[...].war" from Service Module Loader > Plain ExecutorService sees exactly the same class loader as normal threads in which HTTP request are processed. In version 14.0 this was also true for ScheduledExecutorService. -- This message was sent by Atlassian Jira (v7.13.5#713005)

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