April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-93) Create internal git repository

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-93?page=com.atlassian.jira.plugin.s... ] Filip Brychta edited comment on SWSQE-93 at 4/5/18 9:12 AM: ------------------------------------------------------------ There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready and move # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com is approved, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 was (Author: fbrychta): There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready and move # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 > Create internal git repository > ------------------------------ > > Key: SWSQE-93 > URL: https://issues.jboss.org/browse/SWSQE-93 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We need internal git repository for things like: > * dockerfiles for jenkins docker slaves > * openshift templates > * installation scripts > Part of this task is to investigate options we have for internal git repositories (there is not just one) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-93) Create internal git repository

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-93?page=com.atlassian.jira.plugin.s... ] Filip Brychta edited comment on SWSQE-93 at 4/5/18 9:09 AM: ------------------------------------------------------------ There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready and move # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 was (Author: fbrychta): There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 > Create internal git repository > ------------------------------ > > Key: SWSQE-93 > URL: https://issues.jboss.org/browse/SWSQE-93 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We need internal git repository for things like: > * dockerfiles for jenkins docker slaves > * openshift templates > * installation scripts > Part of this task is to investigate options we have for internal git repositories (there is not just one) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-93) Create internal git repository

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-93?page=com.atlassian.jira.plugin.s... ] Filip Brychta commented on SWSQE-93: ------------------------------------ There is a ongoing effort to create general RedHat GitLab instance [1]. It's not ready yet and it's not clear when it will be. Goal is to have only one GitLab instance and merge all other instances [2]. I see following options: # continue using hawkular-qe-utils (gerrit) until https://gitlab.corp.redhat.com is ready # create new gerrit project and move to https://gitlab.corp.redhat.com when it's ready # create new repo in https://gitlab.cee.redhat.com (cee team instance), if the https://gitlab.corp.redhat.com, we will have to move there because cee instance will be canceled probably # create new gerrit project and stay there unless there will be some issue with that I like 2) because we will probably need just two internal repos, one for internal tooling and one for internal tests (see SWSQE-121). Majority will be in public repo. Also we can later decide if we want to move to https://gitlab.corp.redhat.com or not. 3) is also fine but it will require additional work if https://gitlab.corp.redhat.com is approved and ready [1] - https://projects.engineering.redhat.com/browse/PNTSYSOPS-2390 [2] - https://mojo.redhat.com/docs/DOC-1127529 > Create internal git repository > ------------------------------ > > Key: SWSQE-93 > URL: https://issues.jboss.org/browse/SWSQE-93 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > > We need internal git repository for things like: > * dockerfiles for jenkins docker slaves > * openshift templates > * installation scripts > Part of this task is to investigate options we have for internal git repositories (there is not just one) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-123) Rresearch - Find the source to get original data from

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-123: ------------------------------------ Summary: Rresearch - Find the source to get original data from Key: SWSQE-123 URL: https://issues.jboss.org/browse/SWSQE-123 Project: Kiali QE Issue Type: Sub-task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Rest API return data for graph in Json format. Research where is the original source of data and how to read that in automation framework. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-122) Service Graph Data from Rest/Json automated testing

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created SWSQE-122: ------------------------------------ Summary: Service Graph Data from Rest/Json automated testing Key: SWSQE-122 URL: https://issues.jboss.org/browse/SWSQE-122 Project: Kiali QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2454) [DMN Designer] Decision content not visible after reopen

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2454?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2454: -------------------------------- Tester: Jozef Marko > [DMN Designer] Decision content not visible after reopen > -------------------------------------------------------- > > Key: DROOLS-2454 > URL: https://issues.jboss.org/browse/DROOLS-2454 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.8.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Fix For: 7.8.0.Final > > Attachments: Screenshot from 2018-04-05 14-35-20.png, Screenshot from 2018-04-05 14-35-52.png > > > If the decision with bigger context table is reopened, its content is not visible. > h2. Acceptance test > In each scenario, width of columns don't have to be same as before closing, however each column should has some minimal/default width. > # Steps to reproduce fixed > # Define top level as Literal expression, reopen > # Define top level as Decision table, add columns, reopen > # Define top level as Relation, add columns, reopen > # Define top level as Invocation, specify complex parameters, reopen > # Define top level as Function, add a lot of parameters, reopen > # Define top level as Context, recursively add more Contexts, reopen -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-121) Investigate Guidelines for Upstream First Testing

by Filip Brychta (JIRA)

Filip Brychta created SWSQE-121: ----------------------------------- Summary: Investigate Guidelines for Upstream First Testing Key: SWSQE-121 URL: https://issues.jboss.org/browse/SWSQE-121 Project: Kiali QE Issue Type: Task Reporter: Filip Brychta Assignee: Michael Foley According to [1] not all tests might be pushed to public repos, we need to: * investigate which test can be public and which must be private * read discussion "Guidelines on Opensourcing tests" on jbmc-team list * for those which can be public add proper licensing and other necessary things * create ticket for license checker [1] - https://mojo.redhat.com/docs/DOC-1033126 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2454) [DMN Designer] Decision content not visible after reopen

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2454?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2454: -------------------------------- Description: If the decision with bigger context table is reopened, its content is not visible. h2. Acceptance test In each scenario, width of columns don't have to be same as before closing, however each column should has some minimal/default width. # Steps to reproduce fixed # Define top level as Literal expression, reopen # Define top level as Decision table, add columns, reopen # Define top level as Relation, add columns, reopen # Define top level as Invocation, specify complex parameters, reopen # Define top level as Function, add a lot of parameters, reopen # Define top level as Context, recursively add more Contexts, reopen was: If the decision with bigger context table is reopened, its content is not visible. h2. Acceptance test In each scenario, width of columns don't have to be same as before closing, however each column should has some minimal/default width. # Steps to reproduce fixed # Define top level as Literal expression, reopen # Define top level as Decision table, add columns, reopen # Define top level as Relation, add columns, reopen # Define top level as Invocation, specify complex parameters, reopen # Define top level as Function, add a lot of parameters, reopen > [DMN Designer] Decision content not visible after reopen > -------------------------------------------------------- > > Key: DROOLS-2454 > URL: https://issues.jboss.org/browse/DROOLS-2454 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.8.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Fix For: 7.8.0.Final > > Attachments: Screenshot from 2018-04-05 14-35-20.png, Screenshot from 2018-04-05 14-35-52.png > > > If the decision with bigger context table is reopened, its content is not visible. > h2. Acceptance test > In each scenario, width of columns don't have to be same as before closing, however each column should has some minimal/default width. > # Steps to reproduce fixed > # Define top level as Literal expression, reopen > # Define top level as Decision table, add columns, reopen > # Define top level as Relation, add columns, reopen > # Define top level as Invocation, specify complex parameters, reopen > # Define top level as Function, add a lot of parameters, reopen > # Define top level as Context, recursively add more Contexts, reopen -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2454) [DMN Designer] Decision content not visible after reopen

by Jozef Marko (JIRA)

Jozef Marko created DROOLS-2454: ----------------------------------- Summary: [DMN Designer] Decision content not visible after reopen Key: DROOLS-2454 URL: https://issues.jboss.org/browse/DROOLS-2454 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.8.0.Final Reporter: Jozef Marko Assignee: Michael Anstis Fix For: 7.8.0.Final Attachments: Screenshot from 2018-04-05 14-35-20.png, Screenshot from 2018-04-05 14-35-52.png If the decision with bigger context table is reopened, its content is not visible. h2. Acceptance test In each scenario, width of columns don't have to be same as before closing, however each column should has some minimal/default width. # Steps to reproduce fixed # Define top level as Literal expression, reopen # Define top level as Decision table, add columns, reopen # Define top level as Relation, add columns, reopen # Define top level as Invocation, specify complex parameters, reopen # Define top level as Function, add a lot of parameters, reopen -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-116) Reinstall openshift production cluster

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-116?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-116: ------------------------------------- On a call we agreed to install the new prod cluster from scratch on b20 and another blade which can be removed form old prod cluster. Old prod cluster can be still up with 2 nodes until we have new one. > Reinstall openshift production cluster > -------------------------------------- > > Key: SWSQE-116 > URL: https://issues.jboss.org/browse/SWSQE-116 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Guilherme Baufaker Rêgo > > Currently there are following problems with our OS cluster: > * docker on nodes is using loopback devices which is strongly discouraged for production use > * small partition for imagefs and nodefs which is causing issues "The node was low on resource: imagefs" > * different root passwords > We need to: > # investigate recommended partitioning for production OS clusters (also think about RAID versions available on each blade) > # reinstall RHELs with recommended partitions > # Configuring Docker Storage as described in https://docs.openshift.com/container-platform/3.9/install_config/install/... > # install OS 3.9 > # create mojo documentation -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018