You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
At the moment, we are using Siddhi Parser service to create partial Siddhi apps to be distributed based on the state of the queries by the Siddhi Kubernetes Operator.
This service furthermore, provides information about whether we need to create ingresses to expose the endpoints based on the source types.
In order to retrieve this information, within parser service, we compile the user-given Siddhi app creating a SiddhiAppRuntime. In order to successfully create a SiddhiAppRuntime for the Siddhi app, we need to have all extension JARs in Siddhi Parser's classpath.
During the 0.2.0-m1 Siddhi Parser release, we included all the jars that were bundled in the distribution's vanilla version(5.1.0-m1).
Let's assume that a user creates a custom extension and creates a Siddhi-Runner docker image manually and use it within the Siddhi custom resource. In this scenario, the Siddhi parser service would fail since its classpath does not have the custom JAR.
As a solution, we need to use all the JARs that are bundled in the Siddhi Runner docker image provided through the Siddhi Custom resource or configured as an Operator configuration.
To achieve this, we are going to move the Siddhi Parser component to the Siddhi Runner distribution itself and expose its functionality through a script.
From this approach, the Siddhi Operator can run the Siddhi Parser script in Siddhi Runner image and get the distributed partial Siddhi apps and other needed information to be used during deployment from it.
Affected Product Version:
0.2.0-m1
The text was updated successfully, but these errors were encountered:
Description:
At the moment, we are using Siddhi Parser service to create partial Siddhi apps to be distributed based on the state of the queries by the Siddhi Kubernetes Operator.
This service furthermore, provides information about whether we need to create ingresses to expose the endpoints based on the source types.
In order to retrieve this information, within parser service, we compile the user-given Siddhi app creating a SiddhiAppRuntime. In order to successfully create a SiddhiAppRuntime for the Siddhi app, we need to have all extension JARs in Siddhi Parser's classpath.
During the 0.2.0-m1 Siddhi Parser release, we included all the jars that were bundled in the distribution's vanilla version(5.1.0-m1).
Let's assume that a user creates a custom extension and creates a Siddhi-Runner docker image manually and use it within the Siddhi custom resource. In this scenario, the Siddhi parser service would fail since its classpath does not have the custom JAR.
As a solution, we need to use all the JARs that are bundled in the Siddhi Runner docker image provided through the Siddhi Custom resource or configured as an Operator configuration.
To achieve this, we are going to move the Siddhi Parser component to the Siddhi Runner distribution itself and expose its functionality through a script.
From this approach, the Siddhi Operator can run the Siddhi Parser script in Siddhi Runner image and get the distributed partial Siddhi apps and other needed information to be used during deployment from it.
Affected Product Version:
0.2.0-m1
The text was updated successfully, but these errors were encountered: