Release Notes for GA 8
Available on: Dec 13 2019
Supported Platforms:
Ubuntu 18.04
CentOS 7.5
RedHat 7.5
Supported Browsers:
Chrome
Edge
Safari
Features Functionality
Kubernetes Deployment Available for Offline Installs
Kubernetes offline deployment is available and supported.
Pliant to be Deplolyed on K3S
This will allow a proper cluster to be setup and managed with Kubernetes tools. Also we no longer require Docker to be installed on the machine on which Pliant is to be deployed. The tarball is fully self-contained.
Workflow Inputs Default to Required
In the start section, all variables will have the option for Required enabled by default.
The main impact of this will be that when user flows are being called from other flows, the inputs they define will now always show as required unless the user specifically turns them off.
Distributed Workers and Worker Groups – Provisioning through the API
Worker nodes can now be able to be provisioned on remote servers in logically and physically remote areas of the infrastructure. This can be useful when security of policy concerns dictate that particular flows of versions of flows will only be used in certain parts of the infrastructure.
Remote workers can be deployed either with access to the internet and through a tarball.
Ports 443, 8081 and 5672 must be open between the controller and remote workers.
NOTE: Expect 8081 to no longer be required in the next one or two releases. 5672 will move to 5671 as it becomes encrypted, so in the short term it may be beneficial to have both ports open.
The distributed architecture of Pliant calls for the creation of Worker Groups of worker nodes. Individual worker nodes are joined to specific Worker Groups. Each node can belong to only Worker Group at this time. Users may choose which Worker Group will run a particular instance of a flow. The scheduler will then send flows the members of the Worker Group using a load-balancing scheme.
Addressing flows to Worker Groups instead of individual worker nodes allows for easy horizontal scalability. Of course an Worker Group can contain a single worker node
There is an Worker Group called Default which always exists on a cluster.
There is an API endpoint to create Worker Groups on the cluster. Currently there is no UI.
Workflow APIs should be able to take an optional parameter Worker Group, which will default to Default. Thus, when a workflow is invoked with a specific API call, we should direct it to runners in that specific group.
Remote worker nodes authenticate to their groups through a shared key (password) which is defined when the group is created.
Scrolling Zones are Clearly Marked
When dragging a block beyond the edge of the current view (up or down), the view starts scrolling when the mouse pointer dragging the block approaches the edge of the view.
It is often hard to judge where exactly the scrolling zones are and there is no easy way to have the browser hint.
Pliant now displays highlighted fields which closely (though not 100% accurately) indicate where the scrolling zones are.
Various performance optimizations
Optimizations around both the front-end and the back-end of the system have been implemented
Timing Data Embedded in WorkFlow Output
The flow invocation URL accepts an extra parameter called "stats" (similarly to "sync") which when set to true makes sure that the workflow serializes various statistics once it completes running. The statics will be serialized in an object called stats. It has the following format.
“$stats":{
"timeStarted":1576248536113,
"timeEnded":1576248537485
}