Unable to deploy custom Siddhi Apps on a Kubernetes cluster as documented

[PJBC77]

Description:
We want to deploy custom Siddhi Apps on our Kubernetes clusters and for this we followed the official documentation at siddhi.io.

As far as we understood, when a Siddhi App is passed through a custom resource object for Kubernetes deployment, the Siddhi Parser appears to get the necessary information extracted from the App for the Siddhi Operator to create the deployment.

This is not happening in our environments (we tried two different AKS clusters and also a Kubernetes cluster running in one of our VMs, both with the same result). We were able to deploy Siddhi Operator, and whenever we pass a Siddhi App for Kubernetes deployment, the Siddhi Parser starts, but the Siddhi Operator is not creating the deployment of the Siddhi App. Then after some seconds the Siddhi Parser terminates as intended and we are left with the Siddhi Operator alone. We couldn't find any suggestive logs that point us towards the cause of the problem.

Is anyone else experiencing the same or you were able to deploy a Siddhi App normally and there's something missing on our end?

Thanks in advance.

Further notes and questions:

1. In the documentation, some pre-requisites are listed where one refers NATS Operator v0.5.0+ and NATS Streaming Operator v0.2.2+. We tried to install these in our clusters, but it didn't solve the Siddhi App deployment issue described. Are we missing some extra step that isn't thoroughly described in the guide? And are these components strictly necessary for Siddhi Apps' deployments or are they just used for the Siddhi Apps well functioning after the said deployment?

2. While following the documentation we noticed the given CRD (custom resource definition) for SiddhiProcess is deprecated for Kubernetes v1.22+ as seen here: Deprecated API Migration Guide. Despite this, after doing the necessary changes (updated file siddhi-process-crd.txt is attached), the issue described above persists. This deprecation issues were also found in CRDs of a couple pre-requisite componentes, namely NATS Operator and NATS Streaming Operator.

Affected Product Version:
Siddhi Operator: siddhiio/siddhi-operator:0.2.2
Siddhi Parser: siddhiio/siddhi-runner-alpine:5.1.2

OS, DB, other environment details and versions:
This issue was seen while using AKS clusters with Kubernetes version 1.23.5

Steps to reproduce:
Just followed Siddhi official documentation at siddhi.io, so if you're attempting to reproduce the issue, you can follow the same documentation and let us know if the same happens or if this is an isolated event in our end.

In total, there should be 3 different pods involved in this process (Siddhi Operator, Siddhi Parser (briefly) and Siddhi App), ending with just two running after a minute (Siddhi Operator and Siddhi App). We never see the Siddhi App running.

[amoscatelli]

We have the same issue, the lack of an answer is disturbing ...

[amoscatelli]

I can see the Siddhi Parser pod running for some time :

JAVA_HOME environment variable is set to /opt/java/openjdk
CARBON_HOME environment variable is set to /home/siddhi_user/siddhi-runner
RUNTIME_HOME environment variable is set to /home/siddhi_user/siddhi-runner/wso2/runner
[2024-01-31 14:36:41,284]  INFO {org.wso2.carbon.launcher.extensions.OSGiLibBundleDeployerUtils updateOSGiLib} - Successfully updated the OSGi bundle information of Carbon Runtime: runner  
osgi> [2024-01-31 14:36:42,662]  INFO {org.wso2.carbon.metrics.core.config.model.JmxReporterConfig} - Creating JMX reporter for Metrics with domain 'org.wso2.carbon.metrics'
[2024-01-31 14:36:42,662]  INFO {org.wso2.msf4j.internal.websocket.WebSocketServerSC} - All required capabilities are available of WebSocket service component is available.
[2024-01-31 14:36:42,676]  INFO {org.wso2.msf4j.analytics.metrics.MetricsComponent} - Metrics Component is activated
[2024-01-31 14:36:42,678]  INFO {org.wso2.carbon.databridge.agent.internal.DataAgentDS} - Successfully deployed Agent Server 
[2024-01-31 14:36:42,914]  INFO {org.wso2.carbon.analytics.idp.client.core.utils.IdPServiceUtils} - Enabling default IdPClient Local User Store as configuration is not overridden.
[2024-01-31 14:36:42,918]  INFO {org.wso2.carbon.analytics.idp.client.core.utils.IdPServiceUtils} - IdP client of type 'local' is started.
[2024-01-31 14:36:42,994]  INFO {org.wso2.msf4j.MicroservicesRunner} - Microservices server started in 54ms
[2024-01-31 14:36:42,994]  INFO {io.siddhi.parser.service.SiddhiParserApi} - Siddhi Parser REST API activated.
[2024-01-31 14:36:42,996]  INFO {org.wso2.transport.http.netty.contractimpl.listener.ServerConnectorBootstrap$HttpServerConnector} - HTTP(S) Interface starting on host 0.0.0.0 and port 9090
[2024-01-31 14:36:43,035]  INFO {org.wso2.msf4j.internal.MicroservicesServerSC} - All microservices are available
[2024-01-31 14:36:43,036]  INFO {org.wso2.transport.http.netty.contractimpl.listener.ServerConnectorBootstrap$HttpServerConnector} - HTTP(S) Interface starting on host 0.0.0.0 and port 9443
[2024-01-31 14:36:43,041]  INFO {org.wso2.carbon.kernel.internal.CarbonStartupHandler} - Siddhi Runner Distribution started in 1.979 sec

Then the pod is terminated and also the service is removed.
This is the operator log

{"level":"info","ts":1706711799.33205,"msg":"Waiting for parser","Namespace":"wso2","Name":"power-surge-app","deployment":"power-surge-app"}