October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-210) Operator missing way to configure multiple containers inside pod

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFWIP-210?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFWIP-210: ----------------------------------- Labels: operator (was: ) > Operator missing way to configure multiple containers inside pod > ---------------------------------------------------------------- > > Key: WFWIP-210 > URL: https://issues.jboss.org/browse/WFWIP-210 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > User scenario: As a user I am able to run multiple containers under pod > - init container pattern [1] > - side car container pattern [1] > Note, this is pattern which {{istio}} use. > [1] https://matthewpalmer.net/kubernetes-app-developer/articles/multi-contain... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-211) emptyDir.sizeLimit not propagated to Pod Spec

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFWIP-211?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFWIP-211: ----------------------------------- Labels: operator (was: ) > emptyDir.sizeLimit not propagated to Pod Spec > --------------------------------------------- > > Key: WFWIP-211 > URL: https://issues.jboss.org/browse/WFWIP-211 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > # {code:yaml} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > name: operator-empty-dir > namespace: mchoma > spec: > applicationImage: 'registry.access.redhat.com/jboss-eap-7/eap72-openshift:1.1' > size: 1 > storage: > emptyDir: > medium: Memory > sizeLimit: 1Mi > {code} > # wait until pod are started and look into pod yaml definition "1 Mi" is not there > {code:yaml} > ... > serviceAccount: default > serviceAccountName: default > subdomain: operator-empty-dir-headless > terminationGracePeriodSeconds: 30 > volumes: > - emptyDir: > medium: Memory > name: operator-empty-dir-volume > - name: default-token-j2grg > secret: > defaultMode: 420 > secretName: default-token-j2grg > status: > conditions: > ... > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected cell

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4585?page=com.atlassian.jira.plugi... ] Guilherme Gomes commented on DROOLS-4585: ----------------------------------------- [~jomarko] The problem is similar, but RHDM-1016 is related to DMN editor and DROOLS-4585 is related to Test Scenario. So probably a different approaches for handling each case. > Focus doesn't moves after the selected cell > ------------------------------------------- > > Key: DROOLS-4585 > URL: https://issues.jboss.org/browse/DROOLS-4585 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > > {color:red}*Failure*{color} > If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body. > *Expected* > Viewed part of grid follows the selected cell -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected cell

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4585?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-4585: ------------------------------------- [~karreiro] do you think is RHDM-1016 the same as DROOLS-4585? > Focus doesn't moves after the selected cell > ------------------------------------------- > > Key: DROOLS-4585 > URL: https://issues.jboss.org/browse/DROOLS-4585 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > > {color:red}*Failure*{color} > If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body. > *Expected* > Viewed part of grid follows the selected cell -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4584) Scrolling during editing mode move cell in new position on the screen

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4584?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-4584: ------------------------------------- [~manstis][~karreiro] I guess this issue could happen also for DMN, what do you think? > Scrolling during editing mode move cell in new position on the screen > --------------------------------------------------------------------- > > Key: DROOLS-4584 > URL: https://issues.jboss.org/browse/DROOLS-4584 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > Attachments: image-2019-10-01-11-24-36-774.png > > > !image-2019-10-01-11-24-36-774.png|thumbnail! > Cell moves unexpectedly in editing mode > {color:red}*Failure*{color} > If you start edit any cell of a big grid and then scroll the input would move not in the right cell. > *Expected* > Input element moves with entire table -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery

by Martin Simka (Jira)

[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ] Martin Simka updated WFWIP-218: ------------------------------- Description: this follows up on WFWIP-206 While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client {noformat} /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 {noformat} was: this follows up on WFWIP-206 While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} {noformat} /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 {noformat} > server scale down sometimes keeps data in client's data/ejb-xa-recovery > ----------------------------------------------------------------------- > > Key: WFWIP-218 > URL: https://issues.jboss.org/browse/WFWIP-218 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Blocker > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client > {noformat} > /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-218) server scale down sometimes keeps data in client's data/ejb-xa-recovery

by Martin Simka (Jira)

Martin Simka created WFWIP-218: ---------------------------------- Summary: server scale down sometimes keeps data in client's data/ejb-xa-recovery Key: WFWIP-218 URL: https://issues.jboss.org/browse/WFWIP-218 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Martin Simka Assignee: Ondrej Chaloupka this follows up on WFWIP-206 While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful Scenario: *ejb client* (app tx-client, pod tx-client-0): * EJB business method ** lookup remote EJB ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ** call remote EJB *ejb server* (app tx-server, pod tx-server-0): * EJB business method ** enlist XA resource 1 to transaction ** enlist XA resource 2 to transaction ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} {noformat} /opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000aa3c95b225d932d5e0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-198) EAP Operator long-term strategy

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ] Martin Choma closed WFWIP-198. ------------------------------ Resolution: Explained We have discussed with [~jmesnil] and strategy will be something along lines: Operator will expose just most useful options. If new option needs to be exposed user has to create RFE. If RFE will be not accepted he has to "turn off" operator and to be on his own. Loosing scale down transaction support provided by EAP7-1192. > EAP Operator long-term strategy > ------------------------------- > > Key: WFWIP-198 > URL: https://issues.jboss.org/browse/WFWIP-198 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Facts: > # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1]. > # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work. > # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime. > So given these facts question is what is long-term strategy with Operator? > # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator > # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192) > # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?) > [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wil... > [2] > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods... > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat... > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv... > https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected cell

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-4585?page=com.atlassian.jira.plugi... ] Yeser Amer commented on DROOLS-4585: ------------------------------------ I confirm, it's present. Not a regression anyway. > Focus doesn't moves after the selected cell > ------------------------------------------- > > Key: DROOLS-4585 > URL: https://issues.jboss.org/browse/DROOLS-4585 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > > {color:red}*Failure*{color} > If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body. > *Expected* > Viewed part of grid follows the selected cell -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected cell

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-4585?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-4585: -------------------------------- Affects Version/s: 7.28.0.Final > Focus doesn't moves after the selected cell > ------------------------------------------- > > Key: DROOLS-4585 > URL: https://issues.jboss.org/browse/DROOLS-4585 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.28.0.Final > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Major > Labels: CustomerFocus > > {color:red}*Failure*{color} > If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body. > *Expected* > Viewed part of grid follows the selected cell -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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 October 2019