- 18 Sep 2024
- 11 Minutes to read
- Print
- DarkLight
Cogniac Workflow Creation and Workflow Deployment
- Updated on 18 Sep 2024
- 11 Minutes to read
- Print
- DarkLight
1. Objective
This document explains how to use deployment groups and deployment workflow (also called workflow), and how to create them using the steps below.
2. Overview
Deployment provides extended control over production visual inspection pipeline workloads. Deployment Groups and Deployment Workflows are created and managed via the Cogniac CloudCore platform and executed on Cogniac EdgeFlow physical appliances or Cogniac CloudFlow instances.
3. Introduction
The Deployments feature provides the following benefits to Cogniac users:
Decouples CloudCore visual application development from EdgeFlow application deployment, which allows each to progress with minimal dependencies
Provides fine-grained control (when required) of overall application model versions and application configurations
Supports application pipelines “rerouting” in Deployment Workflows, allowing for different application assemblies than in CloudCore
Enable perfectly repeatable execution of frozen application pipelines in the form of immutable Deployment Workflows
Manage identical fleets of EdgeFlow devices as a single virtual entity in the form of a Deployment Group
The Deployments feature is powerful as it introduces new higher-level abstractions for managing production or testing environments. Two new high-level management concepts are introduced: the Deployment Group and the Deployment Workflow.
The following diagram demonstrates the relationship between the new managed objects introduced by the Deployments feature:
4. Main terminology used in this document
The definitions of the core high-level concepts are as follows:
EdgeFlow - a dedicated inference resource in the form of a physical
EdgeFlow appliance or a CloudFlow instance
Deployment Group - a set of similar purpose and capacity EdgeFlow instances
Deployment Workflow - a “frozen” application pipeline including models and configuration intended for execution across a Deployment Group
5. EdgeFlow
In this context, EdgeFlow represents an EdgeFlow appliance or a CloudFlow instance since CloudFlow is effectively a type of EdgeFlow. EdgeFlow instances are an already familiar feature of the Cogniac System, accessible from the “EdgeFlow Gateways” menu item, where individual EdgeFlow instances can be managed via a view shown here:
6. Deployment Group
The Deployment Groups concept allows groups of similar EdgeFlow instances to be grouped to be more easily managed as a group. Most importantly, a Deployment Group enables a specific Deployment Workflow to be deployed across a set of identical EdgeFlows in a simplified manner. An individual Deployment Group can execute a single Workflow at a time.
To create a deployment group click on the “+” sign, enter name and description(optional), then click on “Okay”.
The list of configured Deployment Groups can be viewed from the Deployment Groups Menu item in CloudCore.
A list of Deployment Groups will appear as follows, which allows the selection of existing Deployment Groups as well as the creation.
Individual Deployment Groups present a view somewhat similar to the individual EdgeFlow View.
The essential characteristics of a Deployment Group are as follows:
A set of EdgeFlows all of the same model type
The current Workflow that matches the deployment group
Update Workflow from a list of available workflows with a matching EdgeFlow model
Preload the workflow onto the EdgeFlow before switching over to the new workflow. This will minimize downtime.
A set of Managers who have permission to change a specific Deployment Group
Deployments History shows the history of the workflows deployed to this group
Delete Group, where the user can delete unused deployment groups
EdgeFlow instances can be assigned to a Deployment Group either via this Deployment Group view or the original EdgeFlow view. Here is how the assignment looks from the original EdgeFlow view:
One key aspect of Deployments is replacing the previous “Model Deployment Policy” mechanism. Previous staging and production model deployment policy configurations can be easily migrated to Deployments and the corresponding per-app model configuration.
Please contact Cogniac Support to programmatically migrate your previous staging and production configurations to Deployment Groups and Deployment Workflows.
You can also check the tutorial → [Here].
7. Workflow
Deployment Workflows (or “Workflows” for short) are a “frozen” application pipeline including models and config intended for execution across a Deployment Group.
An essential characteristic of a Workflow is that it is immutable by design. Once created, a Workflow can never change. This ensures that a particular workflow produces consistent results when deployed on different EdgeFlow instances, especially over time. This characteristic enables high-confidence rollback and, as such, lowers the bar to making forward progress.
7.1 Workflow Creation
Deployment Workflows can be created in CloudCore via the EdgeFlow Menu item:
Once the Deployment Workflows menu is selected, you can create a new workflow and see a list of existing Deployment Workflows.
Click on the blue “plus” button to create a new workflow:
Enter the Name of the Workflow, Description (add an optional description e.g., purpose of the Workflow), and select the targeted EdgeFlow/CloudFlow type from the drop-down menu. You can select the Auto Version Update, which will create a new version if there is a model update, an application-specific change, or a camera update for the applications in a Workflow. Lastly, you can select the applications to add(you need to click first on “Deselect All” because it is selected by default) to the Workflow and click the blue Create Workflow button.
Suppose you need to change the configuration of the applications for this workflow. In that case, you can hover over the application and click on the edit icon on the right corner of the application. A detailed configuration panel is displayed when you click on the Edit icon:
Once they click on the Edit icon, a view similar to this should be visible:
Users can make modifications to the application configuration and save the configuration. These changes only affect the workflow they are creating, not the CloudCore configuration.
Detailed information about inference execution policies is available at https://support.cogniac.ai/v1/docs/applications.
If many applications are in view, you can click into full-screen mode, deselect all, and select only the desired applications to be included in the Workflow.
Once done, click Create Workflow. The newly created workflow will be displayed similarly to the image below:
Click on the pipeline icon next to Applications will bring you the pipeline view of the workflow in a separate tab in the browser:
7.2 Workflow Clone
You can also clone existing workflows in CloudCore. Open up an existing workflow, and click on the “Clone New Workflow button”.
Users can modify the Name, Description, and Retarget the Edge Flow model and add, remove, or edit the applications to the previous existing workflow. After you are done with the modification, click Save New Workflow. They would be brought back to the view of the new workflow you have cloned.
You can also check the tutorial → [Here].
7.3 Workflow Update
Once a Workflow is created it can be accessed in the section Deployment Workflows. Please see the screenshot below:
Once the users are navigated to the Workflows page, they should expand and select the Workflow they would need to update.
On the bottom of the page there is a button called Workflow Update, and by selecting it, users can update the following Workflow parameters:
Auto Version Update -> Active / Inactive - this option allows the user to deploy the latest version once there is a Workflow Update (When the User adds or removes Applications )
Name / Description - are parameters that can be updated anytime
EdgeFlow version can’t be updated once the Workflow is created.
Applications - Add/ Remove - To add an application Users should type either an Application Name or Application ID (Application ID is a unique identifier and allows the users to filter the exact application if there are many applications with the same name)
Users can select the Pipeline View that will expand the Applications included in the following Workflow.
Once the users has finished adding/removing apps or updating the Workflow they should click on the Save Changes button in order to generate the latest version of the Workflow.
Once a new Model is released this also pushes a new Workflow version. If the Auto Version Update is enabled, the latest Workflow version will be automatically deployed with the latest model release.
You can also view the Update Workflow tutorial → Here
8. Deploying a Workflow to the EdgeFlow
Once the Workflow is created, it can be assigned to a deployment group. A deployment group without a workflow is considered undefined.
When the Deployment Group is selected, the user can schedule when the workflow is deployed to the EdgeFlows associated with the deployment group from the two options - “Deploy Now” or “Schedule Deployment”.
8.1 Deploy Now
This option allows the user to pick a specific version and deploy it to the EdgeFlow at the current time.
From the drop-down menu, select the Workflow that needs to be deployed.
Once you have selected the Workflow version, you will see the following screen. You need to select the exact version, as the latest one is at the top. In the current scenario, it is the V21.
After that, you will have to pick the schedule to be deployed during a specified time, and date. The time will appear in your local time zone.
To start the deployment, click “Finish”.
The Workflow will be displayed in the Future Workflow section until the deployment has completed.
Once the deployment is successful, it will be displayed in the Current Workflow section.
8.2 Schedule Deployment
It allows the user to choose between two options:
“Periodically deploy the latest version”
and
“Deploy a specific version one time”
8.2.1 Periodically deploy the latest version
This feature allows the user to keep their application with the latest version and trigger a deployment if EdgeFlow doesn’t have the latest version deployed. Users can choose the frequency to check for a newer version when this option is selected. Below are all the frequency options available:
When a new version is created, and the auto version is active, it periodically checks for a more recent version and deploys the latest version hourly.
Daily - checks on a specific day of the month (1 to 30) and specific time (00 to 23h) and minutes in 15-minute intervals (00,15,30,45)
Weekly - is checking on a specific day/s (if multiple selections) of the week (Monday to Friday) and specific time (00 to 23h) and minutes in 15-minute intervals (00,15,30,45)
Please see the options displayed in the images below:
8.2.2 Deploy a specific version one time
Allows the user to pick a date/time (for the deployment) from the Calendar. After selecting the Workflow version, date and time deployment, click “Finish”.
The scheduled Workflow will be displayed in the Future Workflow section and under it you will see the date and time that you have scheduled for the deployment to start.
8.3 Pre-load Workflow
The user can select the ‘Pre-load Workflow software on Deployment Group EdgeFlows’ which should trigger a deployment before the actual deployment on the EdgeFlow.
Select the Workflow that you want to be pre-loaded.
After it is pre-loaded it will move in the Pre-loaded Workflow section.
You can also check the tutorial → [Here].
9. Check the deployment
Each workflow has a unique ID, which helps us identify a specific Workflow deployment in the logs. The deployment workflow consists of four stages (statuses) in the Edge Flow, and all of the stages should be checked to confirm whether the deployment was successful.
Below are the four statuses that exist under the ‘deployment_status’ in the Deployments History:
Download - Downloads the workflow json (checks for md5)
Delete - Deletes existing pods currently deployed in the EdgeFlow
Deploy - Deploys the downloaded json file from the CloudCore to the EdgeFlow
Success - This is the final status, indicating the deployment was successful
Also, we need to be sure if all of those have the correct http status code (200 for Success) displayed under the ‘get_workflow_status_code’.
9.1 View the deployment history
There are two ways to check a deployment workflow in the system. The first is by navigating to the deployments history in the Deployment Group tab. However, this option does not give a complete detailed log, so we must also check the Edge Flow logs during the specified time and for the set (ID: Version) combination.
Once the user has collected the information from the Deployments History in the Deployment Group tab, they will need to navigate to the Edge Flow device using the Edge Flow menu item at the top of the page.
After that, select the EdgeFlow device from the list of devices available:
Then, the Status page of the Edge Flow device will be opened. On this page, you can find a lot of helpful information about the device, such as GPU memory usage, Temperature, CPU and Memory usage, and Network statistics.
On the top of the page, there are also two buttons, Status and Workload Status, and the user needs to select the Status button.
Once the Status of the Edge Flow is selected, a new page will be opened in the same browser window. It should look like the one below:
After selecting the deployment option, we need to narrow down the timespan by selecting the Calendar field in the top right corner and clicking “Submit”.
The deployment logs should be visible in reverse chronological order for the user, and they need to expand each log to view the full details inside it.
We already have the ID and version from the previous screen (LTAVG:0), and we can use the Ctrl+F (to find on the page) and check if this is the same Workflow ID.
Now, we can see the logs have the same ID and confirm the deployment steps (stages) are completed.
We see the sequence goes as follows (from the bottom to the top):
"deployment_status": "downloading workflow"
"deployment_status": "downloaded workflow"
"deployment_status": "deleting existing workflow"
"deployment_status": "deploying workflow"
"deployment_status": "success"
Thus, our deployment was successful. However, we also need to check the Pods, and we can do it by going back to the EdgeFlow device status page and selecting Workload Status. If all the pods (Application pipelines) are green, then the EF device deployment has succeeded.
The current workflow has only one Application with ID:a383truv. And once we check the Workload Status, we can see it is green: