[JBoss JIRA] (DROOLS-4513) s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails
by Filippe Spolti (Jira)
[ https://issues.jboss.org/browse/DROOLS-4513?page=com.atlassian.jira.plugi... ]
Filippe Spolti updated DROOLS-4513:
-----------------------------------
Sprint: 2019 Week 41-43 (from Okt 7)
> s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4513
> URL: https://issues.jboss.org/browse/DROOLS-4513
> Project: Drools
> Issue Type: Bug
> Components: build, kie server
> Affects Versions: 7.14.0.Final, 7.18.0.Final, 7.24.0.Final
> Environment: OpenShift 3.11 with rhdm72-prod-immutable-kieserver.yaml/rhdm73-prod-immutable-kieserver.yaml
> Reporter: Hiroko Miura
> Assignee: Filippe Spolti
> Priority: Major
> Labels: support
> Fix For: 7.29.0.Final
>
> Attachments: ruleTest.zip
>
>
> If multiple ksession are defined in kmodule.xml and Event Lister is set more than one ksession, s2i build fails at KieServerContainerVerifier with the following error.
> {noformat}
> [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT
> java.lang.RuntimeException: Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:172)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:65)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:53)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:40)
> at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:119)
> at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:101)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - com.redhat.gss:ruleTest:1.0.0-SNAPSHOT not verified.
> ERROR Aborting due to error code 1 from kie server container verification
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4513) s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails
by Filippe Spolti (Jira)
[ https://issues.jboss.org/browse/DROOLS-4513?page=com.atlassian.jira.plugi... ]
Filippe Spolti updated DROOLS-4513:
-----------------------------------
Fix Version/s: 7.29.0.Final
> s2i build fails at KieServerContainerVerifier without appropriate logging when kmodule.xml schema validation fails
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4513
> URL: https://issues.jboss.org/browse/DROOLS-4513
> Project: Drools
> Issue Type: Bug
> Components: build, kie server
> Affects Versions: 7.14.0.Final, 7.18.0.Final, 7.24.0.Final
> Environment: OpenShift 3.11 with rhdm72-prod-immutable-kieserver.yaml/rhdm73-prod-immutable-kieserver.yaml
> Reporter: Hiroko Miura
> Assignee: Filippe Spolti
> Priority: Major
> Labels: support
> Fix For: 7.29.0.Final
>
> Attachments: ruleTest.zip
>
>
> If multiple ksession are defined in kmodule.xml and Event Lister is set more than one ksession, s2i build fails at KieServerContainerVerifier with the following error.
> {noformat}
> [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT
> java.lang.RuntimeException: Cannot find KieModule: com.redhat.gss:ruleTest:1.0.0-SNAPSHOT
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:172)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:65)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:53)
> at org.kie.server.services.impl.KieServerContainerVerifier.verify(KieServerContainerVerifier.java:40)
> at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:119)
> at org.kie.server.services.impl.KieServerContainerVerifier.main(KieServerContainerVerifier.java:101)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> [main] ERROR org.kie.server.services.impl.KieServerContainerVerifier - com.redhat.gss:ruleTest:1.0.0-SNAPSHOT not verified.
> ERROR Aborting due to error code 1 from kie server container verification
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4672) Executable model compilation fails with function call and large input array
by Luca Molteni (Jira)
[ https://issues.jboss.org/browse/DROOLS-4672?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-4672:
---------------------------------
Sprint: 2019 Week 41-43 (from Okt 7)
> Executable model compilation fails with function call and large input array
> ---------------------------------------------------------------------------
>
> Key: DROOLS-4672
> URL: https://issues.jboss.org/browse/DROOLS-4672
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.28.0.Final
> Reporter: Martin Weiler
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> A rule with the following RHS fails to compile in the executable model:
> {noformat}
> $input.setNo12Count(functions.sumOf(new Object[]{$no1Count_1, $no2Count_1, $no3Count_1, $no4Count_1, $no5Count_1, $no6Count_1, $no7Count_1, $no8Count_1, $no9Count_1, $no10Count_1, $no11Count_1}).intValue());
> {noformat}
> Failure:
> {noformat}
> text=cannot find symbol
> symbol: method execute((drools,$n[...]t); })
> {noformat}
> Compilation is successful if one of the input parameters (eg. {{$no11Count_1}}) is removed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Guillaume Smet (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Guillaume Smet commented on WFLY-11566:
---------------------------------------
My colleague [~y.rodiere] did some investigation on the issue.
There are a couple of possibilities (we have a similar issue with Quarkus - not exactly the same) but we would need WildFly to pass us some configuration and right now Hibernate Validator bootstraps the ValidatorFactory entirely by itself. So we would need some infrastructure changes in WildFly and the Hibernate Validator CDI extension.
Not entirely sure it's worth it?
For now the best course of action is to set {{hibernate.validator.allow_parameter_constraint_override}} to {{true}} if someone has this issue. But there's a good chance it will break EE conformance.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12676) memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment
by Stefano Maestri (Jira)
[ https://issues.jboss.org/browse/WFLY-12676?page=com.atlassian.jira.plugin... ]
Stefano Maestri commented on WFLY-12676:
----------------------------------------
I merged the cahnge. It needs an upgrade of IJ to include fix into WF/EAP
> memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12676
> URL: https://issues.jboss.org/browse/WFLY-12676
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 18.0.0.Final
> Reporter: Scott Marlow
> Assignee: Stefano Maestri
> Priority: Blocker
> Fix For: 19.0.0.Beta1
>
> Attachments: 2lc.jar, java_pid12802.0001.zip, jcaleakmarlow.txt
>
>
> As part of looking at [WFLY-12671], I found that org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is leaking the application classloader (after undeployment) via org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory originalTCCL being kept after undeployment.
> See attached jcaleakmarlow.txt (also attached to [WFLY-12671]), which shows the leak.
> I tried waiting a few minutes after undeployment and the leak was still there. I also tried an even simpler app (2lc.jar) and still there is a leak. I also attached the heapdump (java_pid12802.0001.zip)
> To recreate:
> * Deploy simple (no app code will be executed) 2lc.jar app.
> * Undeploy by doing "rm 2lc.jar.deployed" in wildfly/standalone/deployments
> * Look at memory with MAT or other memory leak tool.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFCORE-4722) Fix test suite tests to work with Eclipse OpenJ9
by Ondrej Kotek (Jira)
Ondrej Kotek created WFCORE-4722:
------------------------------------
Summary: Fix test suite tests to work with Eclipse OpenJ9
Key: WFCORE-4722
URL: https://issues.jboss.org/browse/WFCORE-4722
Project: WildFly Core
Issue Type: Task
Components: Test Suite
Reporter: Ondrej Kotek
Assignee: James Perkins
Fix For: 11.0.0.Beta1
Some tests fail when Eclipse OpenJ9 is the JVM. In most cases there are specific changes for the IBM J9 JVM which can be ported over to support both Eclipse OpenJ9 and IBM J9.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-255) Existing PVC can slip into as the storage for operator
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-255?page=com.atlassian.jira.plugin.... ]
Petr Kremensky updated WFWIP-255:
---------------------------------
Description:
PVC created manually (any accessModes) by user can be slip into the Operator.
*Things to notice here:*
* WFWIP-186 StorageSpec is intended to be mounted in ReadWriteOnce mode
* {{foo: bar}} should never pass the validation as it is not a valid storage configuration
*reproduce*
* create PVC, use the ${OPERATOR_NAME}\-volume\-${OPERATOR_NAME}-0 name - the PVC would be in normal circumstances created by the operator
{noformat}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
{noformat}
* deploy the project
{noformat}
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
spec:
applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
replicas: 1
storage:
foo: bar
{noformat}
The PVC created by user is reused by operator.
Additional details:
* oc get pvc quickstart-volume-quickstart-0 -o yaml
{noformat}
$ oc get pvc quickstart-volume-quickstart-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
...
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
status:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 10Gi
phase: Bound
{noformat}
* oc get wildflyserver quickstart -o yaml
{noformat}
$ oc get wildflyserver quickstart -o yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
...
spec:
applicationImage: quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0
replicas: 1
storage:
foo: bar
status:
hosts:
- quickstart-route-statefulset.apps-crc.testing
pods:
- name: quickstart-0
podIP: 10.128.1.101
state: ACTIVE
replicas: 1
scalingdownPods: 0
{noformat}
* oc get pod/quickstart-0 -o yaml
{noformat}
$ oc get pod/quickstart-0 -o yaml
...
volumeMounts:
- mountPath: /wildfly/standalone/data
name: quickstart-volume
...
volumes:
- name: quickstart-volume
persistentVolumeClaim:
claimName: quickstart-volume-quickstart-0
{noformat}
was:
PVC created manually (any accessModes) by user can be slip into the Operator.
*Things to notice here:*
* WFWIP-186 StorageSpec is intended to be mounted in ReadWriteOnce mode
* {{foo: bar}} should never pass the validation as it is not a valid storage configuration
*reproduce*
* create PVC, use the ${OPERATOR_NAME}-volume-${OPERATOR_NAME}-0 name - the PVC would be in normal circumstances created by the operator
{noformat}
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
{noformat}
* deploy the project
{noformat}
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
spec:
applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
replicas: 1
storage:
foo: bar
{noformat}
The PVC created by user is reused by operator.
Additional details:
* oc get pvc quickstart-volume-quickstart-0 -o yaml
{noformat}
$ oc get pvc quickstart-volume-quickstart-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: quickstart-volume-quickstart-0
...
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
resources:
requests:
storage: 1Mi
volumeMode: Filesystem
volumeName: pv0022
status:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 10Gi
phase: Bound
{noformat}
* oc get wildflyserver quickstart -o yaml
{noformat}
$ oc get wildflyserver quickstart -o yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: quickstart
...
spec:
applicationImage: quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0
replicas: 1
storage:
foo: bar
status:
hosts:
- quickstart-route-statefulset.apps-crc.testing
pods:
- name: quickstart-0
podIP: 10.128.1.101
state: ACTIVE
replicas: 1
scalingdownPods: 0
{noformat}
* oc get pod/quickstart-0 -o yaml
{noformat}
$ oc get pod/quickstart-0 -o yaml
...
volumeMounts:
- mountPath: /wildfly/standalone/data
name: quickstart-volume
...
volumes:
- name: quickstart-volume
persistentVolumeClaim:
claimName: quickstart-volume-quickstart-0
{noformat}
> Existing PVC can slip into as the storage for operator
> ------------------------------------------------------
>
> Key: WFWIP-255
> URL: https://issues.jboss.org/browse/WFWIP-255
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Major
>
> PVC created manually (any accessModes) by user can be slip into the Operator.
> *Things to notice here:*
> * WFWIP-186 StorageSpec is intended to be mounted in ReadWriteOnce mode
> * {{foo: bar}} should never pass the validation as it is not a valid storage configuration
> *reproduce*
> * create PVC, use the ${OPERATOR_NAME}\-volume\-${OPERATOR_NAME}-0 name - the PVC would be in normal circumstances created by the operator
> {noformat}
> apiVersion: v1
> kind: PersistentVolumeClaim
> metadata:
> name: quickstart-volume-quickstart-0
> spec:
> accessModes:
> - ReadWriteOnce
> - ReadOnlyMany
> - ReadWriteMany
> resources:
> requests:
> storage: 1Mi
> volumeMode: Filesystem
> volumeName: pv0022
> {noformat}
> * deploy the project
> {noformat}
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: quickstart
> spec:
> applicationImage: "quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0"
> replicas: 1
> storage:
> foo: bar
> {noformat}
> The PVC created by user is reused by operator.
> Additional details:
> * oc get pvc quickstart-volume-quickstart-0 -o yaml
> {noformat}
> $ oc get pvc quickstart-volume-quickstart-0 -o yaml
> apiVersion: v1
> kind: PersistentVolumeClaim
> metadata:
> name: quickstart-volume-quickstart-0
> ...
> spec:
> accessModes:
> - ReadWriteOnce
> - ReadOnlyMany
> - ReadWriteMany
> resources:
> requests:
> storage: 1Mi
> volumeMode: Filesystem
> volumeName: pv0022
> status:
> accessModes:
> - ReadWriteOnce
> - ReadWriteMany
> - ReadOnlyMany
> capacity:
> storage: 10Gi
> phase: Bound
> {noformat}
> * oc get wildflyserver quickstart -o yaml
> {noformat}
> $ oc get wildflyserver quickstart -o yaml
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: quickstart
> ...
> spec:
> applicationImage: quay.io/wildfly-quickstarts/wildfly-operator-quickstart:18.0
> replicas: 1
> storage:
> foo: bar
> status:
> hosts:
> - quickstart-route-statefulset.apps-crc.testing
> pods:
> - name: quickstart-0
> podIP: 10.128.1.101
> state: ACTIVE
> replicas: 1
> scalingdownPods: 0
> {noformat}
> * oc get pod/quickstart-0 -o yaml
> {noformat}
> $ oc get pod/quickstart-0 -o yaml
> ...
> volumeMounts:
> - mountPath: /wildfly/standalone/data
> name: quickstart-volume
> ...
> volumes:
> - name: quickstart-volume
> persistentVolumeClaim:
> claimName: quickstart-volume-quickstart-0
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months