September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SWSQE-947) Kiali Buildt With Code Coverage Fails To Deploy

by Matthew Mahoney (Jira)

[ https://issues.jboss.org/browse/SWSQE-947?page=com.atlassian.jira.plugin.... ] Matthew Mahoney updated SWSQE-947: ---------------------------------- Priority: Minor (was: Major) > Kiali Buildt With Code Coverage Fails To Deploy > ----------------------------------------------- > > Key: SWSQE-947 > URL: https://issues.jboss.org/browse/SWSQE-947 > Project: Kiali QE > Issue Type: Bug > Reporter: Matthew Mahoney > Priority: Minor > Labels: infrastructure > Attachments: kiali-9b7f589c8-gxpf7-kiali.log > > > Kiali build with Code-Coverage fails to start via OLM / Production Operators > No issues when using quay.io/kiali-qe/kiali:latest > Ex error: > _ > MountVolume.SetUp failed for volume "kiali-cert" : secrets "kiali-cert-secret" not found_ > Repro: > Deploy Service Mesh + Kiali + Jaeger operates via OLM > Create Control Plane, using kiali build with code coverage > kiali: > enabled: true > hub: quay.io/kiali-qe > image: kiali > tag: latest-cov -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-194) Operator does not provide way to expose arbitrary port

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-194?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFWIP-194: ----------------------------------- I agree > Operator does not provide way to expose arbitrary port > ------------------------------------------------------ > > Key: WFWIP-194 > URL: https://issues.jboss.org/browse/WFWIP-194 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > > Going through non-Operator approach scenarios we have identified Operator is missing this feature: way to expose arbitrary container port, e.g: > - https:8443 > - jolokia:8778 > - debugging:5000 > - dns-ping:8888 > - any app specific port > Could be partially workarounded by `oc port-forward` capability -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-193) Is updating Kubernetes objects created by Operator supported?

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-193?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFWIP-193. ------------------------------- Resolution: Explained > Is updating Kubernetes objects created by Operator supported? > ------------------------------------------------------------- > > Key: WFWIP-193 > URL: https://issues.jboss.org/browse/WFWIP-193 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > > Technically it is possible to update Kubernetes objects which were created by Operator, e.g. StatefulSet, Pods, ... > - Operator has its limitation compared to non-Operator approach (ports, volume mounts, deployment strategy, ...) So user may be tempted to tweak internal objects manually > - But some values of internal objects are automatically synced with Operator (env,..). So even changed they are overwritten by original operator values after a while. > What will be our general recommendation to users: > - Dont touch internal objects? > - We will document what can't be touched? > - We will document what can be touched? -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

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

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-167?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFWIP-167. ------------------------------- Resolution: Explained JBEAP-17559 has been created to track that using a standalone configuration from a ConfigMap is unsupported > 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.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12488) WFLYEJB0467: The request was rejected as the container is suspended

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12488?page=com.atlassian.jira.plugin... ] Cheng Fang resolved WFLY-12488. ------------------------------- Resolution: Explained > WFLYEJB0467: The request was rejected as the container is suspended > ------------------------------------------------------------------- > > Key: WFLY-12488 > URL: https://issues.jboss.org/browse/WFLY-12488 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 17.0.1.Final > Environment: Windows 10 > Wildfly 17 > Reporter: Yugamani K > Assignee: Cheng Fang > Priority: Major > > Unable to lookup EJB after it is being registered with JNDI. > EJB is coming up, few mins after the server startup. > {code} > Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup ncp/ncputils/NumberGeneratorBean!com.ndfs.common.numbergenerator.ejb.NumberGeneratorRemote [Root exception is java.lang.RuntimeException: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0467: The request was rejected as the container is suspended] > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:159) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:185) > at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:106) > at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:975) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.RuntimeException: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0467: The request was rejected as the container is suspended > at org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2$1.getReference(EjbJndiBindingsDeploymentUnitProcessor.java:253) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143) > ... 13 more > Caused by: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0467: The request was rejected as the container is suspended > at org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2$1.getReference(EjbJndiBindingsDeploymentUnitProcessor.java:245) > ... 14 more > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBEE-238) Add license file to JASPI Jar

by Darran Lofthouse (Jira)

Darran Lofthouse created JBEE-238: ------------------------------------- Summary: Add license file to JASPI Jar Key: JBEE-238 URL: https://issues.jboss.org/browse/JBEE-238 Project: JBoss Enterprise Spec APIs Issue Type: Task Components: jboss-jaspi-api Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: jboss-jakarta-jaspi-api_spec-2.0.0.Final -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12488) WFLYEJB0467: The request was rejected as the container is suspended

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12488?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-12488: ----------------------------------- [~yugamani] thanks for the updates. > WFLYEJB0467: The request was rejected as the container is suspended > ------------------------------------------------------------------- > > Key: WFLY-12488 > URL: https://issues.jboss.org/browse/WFLY-12488 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 17.0.1.Final > Environment: Windows 10 > Wildfly 17 > Reporter: Yugamani K > Assignee: Cheng Fang > Priority: Major > > Unable to lookup EJB after it is being registered with JNDI. > EJB is coming up, few mins after the server startup. > {code} > Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup ncp/ncputils/NumberGeneratorBean!com.ndfs.common.numbergenerator.ejb.NumberGeneratorRemote [Root exception is java.lang.RuntimeException: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0467: The request was rejected as the container is suspended] > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:159) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189) > at org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:185) > at org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:106) > at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:975) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.RuntimeException: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0467: The request was rejected as the container is suspended > at org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2$1.getReference(EjbJndiBindingsDeploymentUnitProcessor.java:253) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143) > ... 13 more > Caused by: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0467: The request was rejected as the container is suspended > at org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2$1.getReference(EjbJndiBindingsDeploymentUnitProcessor.java:245) > ... 14 more > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-191) Runtime changes to serviceAccountName are not reflected

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-191?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFWIP-191. ------------------------------- Resolution: Done Upstream issue was fixed in https://github.com/wildfly/wildfly-operator/issues/66 > Runtime changes to serviceAccountName are not reflected > ------------------------------------------------------- > > Key: WFWIP-191 > URL: https://issues.jboss.org/browse/WFWIP-191 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Major > > Any runtime chnages (adding, removing or updating) made to serviceAccountName are not reflected in underlying StatefullSet (generation is same) and Pod objects. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-195) Operator does not provide way to configure https

by Martin Choma (Jira)

Martin Choma created WFWIP-195: ---------------------------------- Summary: Operator does not provide way to configure https Key: WFWIP-195 URL: https://issues.jboss.org/browse/WFWIP-195 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Martin Choma Assignee: Jeff Mesnil Operator is missing way of configuring - https port, e.g. 8443 - termination policy (passthrough, edge, reencrypt) - way to specify certificates -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-185) PVC not deleted by deleting WildFlyServer CR

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-185?page=com.atlassian.jira.plugin.... ] Jeff Mesnil closed WFWIP-185. ----------------------------- Resolution: Rejected > PVC not deleted by deleting WildFlyServer CR > -------------------------------------------- > > Key: WFWIP-185 > URL: https://issues.jboss.org/browse/WFWIP-185 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Blocker > > When I delete WildFlyServer CR PVC created by this CR is not deleted as StatefullSet and Pods are . > I see Statefull Set and Pod has ownerReferences attribute referencing to parent. > ownerReferences > List of objects depended by this object. If ALL objects in the list have been deleted, this object will be garbage collected. If this object is managed by a controller, then an entry in this list will point to this controller, with the controller field set to true. There cannot be more than one managing controller. > I dont see such attribute specified in PVC > {code} > # Please edit the object below. Lines beginning with a '#' will be ignored, > # and an empty file will abort the edit. If an error occurs while saving this file will be > # reopened with the relevant failures. > # > apiVersion: v1 > kind: PersistentVolumeClaim > metadata: > annotations: > pv.kubernetes.io/bind-completed: "yes" > pv.kubernetes.io/bound-by-controller: "yes" > creationTimestamp: 2019-08-30T13:12:27Z > finalizers: > - kubernetes.io/pvc-protection > labels: > app.kubernetes.io/managed-by: wildfly-operator > app.kubernetes.io/name: simple-jaxrs-eap72 > app.openshift.io/runtime: wildfly > name: simple-jaxrs-eap72-volume-simple-jaxrs-eap72-0 > namespace: mchoma > resourceVersion: "3633284" > selfLink: /api/v1/namespaces/mchoma/persistentvolumeclaims/simple-jaxrs-eap72-volume-simple-jaxrs-eap72-0 > uid: d0aac389-cb27-11e9-b93c-fa163e9a0fb6 > spec: > accessModes: > - ReadWriteOnce > resources: > requests: > storage: 1Mi > volumeName: vol57 > status: > accessModes: > - ReadWriteMany > - ReadWriteOnce > capacity: > storage: 1Gi > phase: Bound > {code} -- 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