October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-217) Customizing settings.xml via ENV variables doesn't work on galleon image

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-217?page=com.atlassian.jira.plugin.... ] Jean Francois Denise resolved WFWIP-217. ---------------------------------------- Resolution: Done > Customizing settings.xml via ENV variables doesn't work on galleon image > ------------------------------------------------------------------------ > > Key: WFWIP-217 > URL: https://issues.jboss.org/browse/WFWIP-217 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Blocker > > With released images it is possible to configure settings.xml used for S2I build via ENV variables, eg: https://github.com/jboss-openshift/cct_module/blob/1ff1d96/jboss/containe... > If I understood correctly this was introduced/changed by CLOUD-2911. But with galleon hooked into S2I the settings.xml is replaced with the one needed for slim server so this mechanism no longer works. > This is a backward compatibility issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-216) Providing own ./configuration/settings.xml to S2I build doesn't work with galleon image

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-216?page=com.atlassian.jira.plugin.... ] Jean Francois Denise resolved WFWIP-216. ---------------------------------------- Resolution: Done > Providing own ./configuration/settings.xml to S2I build doesn't work with galleon image > --------------------------------------------------------------------------------------- > > Key: WFWIP-216 > URL: https://issues.jboss.org/browse/WFWIP-216 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Blocker > Attachments: sti-custom-settings-galleon-image.log, sti-custom-settings-standard-cd-image.log > > > According to https://access.redhat.com/documentation/en-us/red_hat_jboss_middleware_fo... the user is able to provide its own settings.xml located in <app_dir>/configuration/settings.xml - this settings file then should be used for mvn build. > This clearly conflicts with galleon settings.xml. However, this is broken backward compatibility and should be somehow addressed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12613) Exclude IBM J9 JVM from Byteman-based test cases

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-12613?page=com.atlassian.jira.plugin... ] Richard Achmatowicz commented on WFLY-12613: -------------------------------------------- There is a bit of a problem here in getting the exclusion to work with the combination of two conditions above. Firstly, AFAICT, maven profiles don't permit using multiple activation conditions, so I can't easily set up a profile to exclude the test. Secondly, I can't use the condition: {noformat} Assume.assumeFalse(System.getProperty("java.version").startsWith("1.8") && System.getProperty("java.vendor").startsWith("IBM")); {noformat} within the test itself, as the agent gets loaded (and the exception gets raised) before the test executes. I can confirm this. Thirdly, Arquillian does not support the use of Assume in a @BeforeClass or @AfterClass method, which would be where I would want to call it. In other words, the issue https://issues.jboss.org/browse/WFLY-7741 still holds ( I tried it ...) Please let me know if I am missing an obvious way to get around this. What I can do is require that the test not execute against any IBM JVM, by setting up a profile to exclude that particular execution (ts.surefire.clustering.all-ejb-byteman). This would not affect the OpenJ9 test executions as they have a different Java vendor. > Exclude IBM J9 JVM from Byteman-based test cases > ------------------------------------------------ > > Key: WFLY-12613 > URL: https://issues.jboss.org/browse/WFLY-12613 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 18.0.0.Final > > > The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case. > There is a problem with running Byteman-based test cases against the IBM J9 Java runtime: > {noformat} > [ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR! > java.lang.RuntimeException: Could not install byteman agent > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71) > at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23) > at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102 > at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66) > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91) > ... 28 more > {noformat} > > {noformat} > [nrla@localhost wildfly-git-repo]$ java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR2_20151019_2144_B272764 > JIT - tr.r14.java_20151006_102517.04 > GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS > J9CL - 20151019_272764) > JCL - 20151022_01 based on Oracle jdk8u65-b17 > {noformat} > Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-202) Runtime changes to disableHTTPRoute are not reflected in Route object

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-202?page=com.atlassian.jira.plugin.... ] Martin Choma closed WFWIP-202. ------------------------------ I can confirm issue is addressed by jboss-eap-7-tech-preview-eap-operator:jb-eap-7.3-operator-rhel8-containers-candidate-66988-20191001135536. However there is followup issue https://issues.jboss.org/browse/WFWIP-223 > Runtime changes to disableHTTPRoute are not reflected in Route object > --------------------------------------------------------------------- > > Key: WFWIP-202 > URL: https://issues.jboss.org/browse/WFWIP-202 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Any changes (adding, removing or updating) made to disableHTTPRoute attribute after WildFlyServer CR was created are not reflected in underlying Route object. > Reproducer: > # create CR > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > disableHTTPRoute: false > {code} > # Edit CR with disableHTTPRoute: true. I would expect Route object will be deleted. > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > disableHTTPRoute: true > {code} > # Route object eap-cd is not disabled/deleted -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-223) disableHTTPRoute = true in runtime does not clean CR.status.hosts

by Martin Choma (Jira)

Martin Choma created WFWIP-223: ---------------------------------- Summary: disableHTTPRoute = true in runtime does not clean CR.status.hosts Key: WFWIP-223 URL: https://issues.jboss.org/browse/WFWIP-223 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Martin Choma Assignee: Jeff Mesnil Reproducer: # create CR {code} apiVersion: wildfly.org/v1alpha1 kind: WildFlyServer metadata: generation: 1 name: eap-cd namespace: default spec: applicationImage: >- brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 size: 1 disableHTTPRoute: false {code} # Edit CR with disableHTTPRoute: true. I would expect Route object will be deleted. {code} apiVersion: wildfly.org/v1alpha1 kind: WildFlyServer metadata: generation: 1 name: eap-cd namespace: default spec: applicationImage: >- brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 size: 1 disableHTTPRoute: true {code} # Route object eap-cd is not deleted but status.hosts is still filled {code:yaml} apiVersion: wildfly.org/v1alpha1 kind: WildFlyServer metadata: creationTimestamp: '2019-10-01T17:20:34Z' generation: 2 name: eap-cd namespace: mchoma resourceVersion: '629943' selfLink: /apis/wildfly.org/v1alpha1/namespaces/mchoma/wildflyservers/eap-cd uid: c7535f3f-e46f-11e9-b4ad-02e6008f3048 spec: applicationImage: >- image-registry.openshift-image-registry.svc:5000/eapcd-suite-builds/eap-cd-openshift-rhel8:17.0-4 disableHTTPRoute: false env: [] envFrom: [] replicas: 1 status: hosts: - >- eap-cd-route-mchoma.apps.eap-qe-cluster105.eap-qe-cluster105.fw.rhcloud.com pods: - name: eap-cd-0 podIP: 10.131.0.246 state: ACTIVE replicas: 1 scalingdownPods: 0 {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-200) Runtime changes to sessionAffinity are not reflected in underlying objects

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-200?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFWIP-200: ------------------------------------ I can confirm I dont see issue anymore with latest eap operator jboss-eap-7-tech-preview-eap-operator:jb-eap-7.3-operator-rhel8-containers-candidate-66988-20191001135536 > Runtime changes to sessionAffinity are not reflected in underlying objects > -------------------------------------------------------------------------- > > Key: WFWIP-200 > URL: https://issues.jboss.org/browse/WFWIP-200 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Any changes (adding, removing or updating) made to sessionAffinity attribute after WildFlyServer CR was created are not reflected in underlying Service kubernetes object. > Reproducer: > # create CR > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > {code} > # Edit CR with sessionAffinity: true > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > sessionAffinity: true > {code} > # Service object eap-cd-loadbalancer is not updated -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-200) Runtime changes to sessionAffinity are not reflected in underlying objects

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-200?page=com.atlassian.jira.plugin.... ] Martin Choma closed WFWIP-200. ------------------------------ > Runtime changes to sessionAffinity are not reflected in underlying objects > -------------------------------------------------------------------------- > > Key: WFWIP-200 > URL: https://issues.jboss.org/browse/WFWIP-200 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > Any changes (adding, removing or updating) made to sessionAffinity attribute after WildFlyServer CR was created are not reflected in underlying Service kubernetes object. > Reproducer: > # create CR > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > {code} > # Edit CR with sessionAffinity: true > {code} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > generation: 1 > name: eap-cd > namespace: default > spec: > applicationImage: >- > brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4 > size: 1 > sessionAffinity: true > {code} > # Service object eap-cd-loadbalancer is not updated -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-215) Operator headless service labeled with wildfly.org/operated-by-loadbalancer=active

by Martin Choma (Jira)

[ https://issues.jboss.org/browse/WFWIP-215?page=com.atlassian.jira.plugin.... ] Martin Choma closed WFWIP-215. ------------------------------ I can verify issue is not present in image-registry.openshift-image-registry.svc:5000/eapcd-suite-builds/jboss-eap-7-tech-preview-eap-operator:jb-eap-7.3-operator-rhel8-containers-candidate-66988-20191001135536 > Operator headless service labeled with wildfly.org/operated-by-loadbalancer=active > ---------------------------------------------------------------------------------- > > Key: WFWIP-215 > URL: https://issues.jboss.org/browse/WFWIP-215 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Ondrej Chaloupka > Priority: Blocker > > # create the WildflyServer CR > {code:yaml} > apiVersion: wildfly.org/v1alpha1 > kind: WildFlyServer > metadata: > name: eap-cd > namespace: mchoma > spec: > applicationImage: >- > image-registry.openshift-image-registry.svc:5000/eapcd-suite-builds/eap-cd-openshift-rhel8:17.0-4 > env: [] > envFrom: [] > size: 1 > {code} > # Both services {{eap-cd-headless}} and {{eap-cd-loadbalancer}} created by Operator have same labels. We used to select service based on label wildfly.org/operated-by-loadbalancer. > {code} > eap-cd-headless > app.kubernetes.io/managed-by=eap-operator > app.kubernetes.io/name=eap-cd > app.openshift.io/runtime=eap > wildfly.org/operated-by-loadbalancer=active > eap-cd-loadbalancer > app.kubernetes.io/managed-by=eap-operator > app.kubernetes.io/name=eap-cd > app.openshift.io/runtime=eap > wildfly.org/operated-by-loadbalancer=active > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-221) jps can't see server process in Openshift

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-221?page=com.atlassian.jira.plugin.... ] Jean Francois Denise edited comment on WFWIP-221 at 10/1/19 12:52 PM: ---------------------------------------------------------------------- [~jbliznak] It doesn't occur when running an image built with s2i, you observe the issue with a run of the builder image. Right? was (Author: jdenise): [~jbliznak] It doesn't occur when running an image built with s2i, you observe the issue with a run of the builder image. > jps can't see server process in Openshift > ----------------------------------------- > > Key: WFWIP-221 > URL: https://issues.jboss.org/browse/WFWIP-221 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > > This is somewhat curious issue. > When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and I can find java process in /proc/*/cmdline (image has no `ps` utility). > This happens only in Openshift environment and it is a regression to what was working with latest published CD image. > Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process. > {code:java} > # this works fine > docker run -it docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP... sh > sh-4.4$ /opt/eap/bin/openshift-launch.sh & > sh-4.4$ jps -l > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-221) jps can't see server process in Openshift

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-221?page=com.atlassian.jira.plugin.... ] Jean Francois Denise commented on WFWIP-221: -------------------------------------------- [~jbliznak] It doesn't occur when running an image built with s2i, you observe the issue with a run of the builder image. > jps can't see server process in Openshift > ----------------------------------------- > > Key: WFWIP-221 > URL: https://issues.jboss.org/browse/WFWIP-221 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > > This is somewhat curious issue. > When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and I can find java process in /proc/*/cmdline (image has no `ps` utility). > This happens only in Openshift environment and it is a regression to what was working with latest published CD image. > Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process. > {code:java} > # this works fine > docker run -it docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP... sh > sh-4.4$ /opt/eap/bin/openshift-launch.sh & > sh-4.4$ jps -l > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019