Deployment Unit

The user code and config is bundled as a Deployment unit and deployed to Flux runtime.

Deployment Unit structure

Deployment units are located on local disk. The path to the Deployment units directory needs to be mentioned in flux configuration file located at flux/runtime/src/main/resources/packaged/configuration.yml with key deploymentUnitsPath. The default is /tmp/workflows

# change this path as contents of /tmp are deleted on boot/periodically

deploymentUnitsPath: "/tmp/workflows/"

The structure of a deployment unit is as follows

deployment_unit_name
   |
   |-du_version_number
       |
       |-- main/
       |-- lib/
       |-- flux_config.yml
       |-- other configuration files which belong to client

main directory contains the client jar which contains workflow code. This directory is mandatory and in case of fat jar, keep the jar in this directory.
lib directory contains the jars the client jar is dependant on. This directory is optional and can be empty.

flux_config.yml

flux_config.yml file contains deployment unit specification configuration and is mandatory.

parameters:

workflowClasses is a list of class names, it tells Flux which classes to scan for @Workflow and @Task annotations. It is a mandatory param.

workflowClasses: ["com.flipkart.flux.examples.externalevents.ManualSellerVerificationFlow",
                  "com.flipkart.flux.examples.externalevents.ManualSellerVerificationService",
                  "com.flipkart.flux.examples.externalevents.NotificationService",
                  "com.flipkart.flux.examples.externalevents.SellerDataService"]

In case you are using Google Guice for DI, you can mention the Guice Module class of your code, using key guiceModuleClass. Flux creates an injector with the provided module, uses the injector while instantiating user classes. This param is optional.

guiceModuleClass: "com.flipkart.flux.examples.externalevents.SellerVerificationWorkflowModule"

You can mention the no.of dedicated Akka actors need to be created to execute a task using executionConcurrency. This number is per JVM. If the number is not mentioned the default value routers.default.instancesPerNode of configuration.yml is used.

taskConfig:
  com.flipkart.flux.integration.SimpleWorkflow_simpleStringReturningTask:
    executionConcurrency: 5

Example structure

/tmp/workflows
│
├── sample_du
│   ├── 1
│   │   ├── flux_config.yml
│   │   ├── lib
│   │   └── main
│   ├── 2
│   │   ├── flux_config.yml
│   │   ├── lib
│   │   └── main
│   └── 3
│       ├── flux_config.yml
│       ├── lib
│       └── main
└── sfs
    └── 1
        ├── flux_config.yml
        └── main

Dynamic load and unload

Load

To load a deployment unit dynamically, place the deployment unit on the disk according to specified structure. After that make a POST call to Flux runtime to load on below path.

http://<flux_url>:<port>/api/deployment/load?name=<deployment_unit_name>&version=<deployment_unit_version>

For example

http://localhost:9998/api/deployment/load?name=sample_du&version=2

Unload

To unload a deployment unit dynamically, make a POST call to Flux runtime to unload on below path.

http://<flux_url>:<port>/api/deployment/unload?name=<deployment_unit_name>&version=<deployment_unit_version>

For example

http://localhost:9998/api/deployment/unload?name=sample_du&version=1

Note:

1. Unloading WON'T delete any files from disk. It will unload the objects from the memory. Also it won't terminate the threads which were allocated to process current deployment unit's tasks as per version 1.0. So to do unload cleanly, we recommend removing the deployment unit from the disk and restarting the Flux process.
2. Make sure you are unloading the earliest version of a deployment unit. Also make sure all workflow instances which belong to this deployment unit are completed before unloading.
3. Dynamic load WON'T support changing the execution concurrency of a task. Say you have a task foo which is present sample_du deployment unit version 1 and version 2. And sample_du version 1 is already loaded at the time of booting, and now you are trying to load version 2. If the execution concurrency of the task is changed in version 2 config file, then it has to be changed in version 1 config file as well, and the Flux process has to be restarted to take effect.