Currently the workflow engine needs to be deployed through Fission as a regular Fission environment. This means that Fission controls the deployment, Kubernetes resources and application lifecycle. Although this sounded useful initially, over time we found that this approach is not ideal for quick development, testing and customizing the workflow deployment.
This PR extracts the fission environment proxy from workflow engine, to allow the user to fully control the workflow engine deployment. This makes it easier to develop and test the workflow engine, using common development practices for Kubernetes. It removes any interference of the Fission executor on the lifecycle. Finally, it is clearer to the user where the workflows end up in.
Finally, next to this, this PR adds...
more documentation on monitoring, tracing and development.
updates the Helm chart
adds a simple check if workflow exists before accepting an invocation.
Currently the workflow engine needs to be deployed through Fission as a regular Fission environment. This means that Fission controls the deployment, Kubernetes resources and application lifecycle. Although this sounded useful initially, over time we found that this approach is not ideal for quick development, testing and customizing the workflow deployment.
This PR extracts the fission environment proxy from workflow engine, to allow the user to fully control the workflow engine deployment. This makes it easier to develop and test the workflow engine, using common development practices for Kubernetes. It removes any interference of the Fission executor on the lifecycle. Finally, it is clearer to the user where the workflows end up in.
Finally, next to this, this PR adds...