COGNIT OpsForge

OpsForge deploys the COGNIT Stack on a target infrastructure, turning it into a Cognitive Serverless Framework for the Cloud-Edge Continuum.

The COGNIT Stack is built using the following components:

Name	Documentation	Testing	Installation
Device Client (Python)	Wiki documentation	Test folder	README
COGNIT Frontend	User guide	Test folder	Install guide
EdgeCluster Frontend	User guide	Test folder	Install guide
Device Client (C)	N/A	Test folder	README
OpenNebula	Official	Q&A	Install guide
Serverless Runtime	Wiki documentation	Test folder	README

OpsForge automatically deploys and configures:

• OpenNebula Frontend — Cloud-Edge Manager (oned, Sunstone, FireEdge, OneFlow)
• COGNIT Frontend — assigns clusters to devices based on device requirements
• COGNIT Optimizer — decides workload placement across clusters and scales the number of VMs when needed
• Devices Load Estimator — updates estimated load from per-service CPU usage, feeding the Optimizer
• Edge Cluster Frontend — per-edge-site proxy and service orchestration (via deploy-edge)

How to use

OpsForge is a Ruby CLI that runs on your local machine. It:

1. Installs OpenNebula and the COGNIT Frontend on a target host using one-deploy + COGNIT Ansible playbooks
2. Optionally provisions edge cluster nodes and deploys the EdgeCluster Frontend via OneFlow

There is no Terraform required for on-premises deployments.

Requirements

• Ruby ≥ 3.0 and the gem json-schema
• Ansible ≥ 2.14
• The one-deploy git submodule initialized: git submodule update --init ansible/one-deploy
• Root SSH access (key-based, no password) to all target hosts from the machine running OpsForge
• If using AWS: Terraform ≥ 1.5 and AWS CLI

Tested on-prem setup

Role	OS	Resources
Frontend	Ubuntu 24.04	4 GB RAM, 2 vCPUs, 20 GB disk
Edge host (KVM node)	Ubuntu 24.04	4 GB RAM, 2 vCPUs, 20 GB disk

Additional requirements:

• Root SSH (key-based) from your laptop to the frontend, and from the frontend to each edge host
• host-passthrough CPU model on edge host VMs — without it the VMX flag is hidden from the guest and nested KVM fails (/dev/kvm missing)
• All VMs must reach the internal COGNIT APT repository

Internals: what happens under the hood

When you run ./opsforge deploy or ./opsforge deploy-edge, OpsForge:

1. Validates your template against schema.json
2. Generates ansible/inventory.yaml and ansible/ansible.cfg from the template values
3. Runs ansible-playbook from the ansible/ directory using the following playbook chain:

deploy (control plane):

ansible/playbooks/cognit.yaml
  ├── Bootstrap: write internal APT repo (if one_internal_repo_url is set), apt update
  ├── opennebula.deploy.pre   (one-deploy: prechecks)
  ├── opennebula.deploy.site  (one-deploy: installs OpenNebula packages + services)
  └── cognit-frontend.yaml    (installs COGNIT Frontend service)

deploy-edge (edge cluster):

ansible/playbooks/edge-only.yaml
  └── edge-cluster.yaml
        ├── Distribute SSH keys to edge hosts
        ├── Pre-configure edge hosts (repo, packages)
        ├── Create OnPrem provider + oneprovision cluster
        ├── Wait for provision to reach RUNNING/DONE
        ├── Sync ONE remotes to edge hosts
        ├── Export marketplace app for the flavour (e.g. NatureFR)
        ├── Wait for images to be READY
        ├── Instantiate OneFlow service
        ├── Configure nginx ECF proxy on edge host
        └── Update cluster template (EDGE_CLUSTER_FRONTEND, FLAVOURS, PROVIDER, GEOLOCATION)

The one-deploy submodule is used as an Ansible collection (opennebula.deploy). Its collections_path is set to ansible/one-deploy/ansible_collections/ in the generated ansible.cfg.

Deploy

Step 0 — Initialize one-deploy submodule

git submodule update --init ansible/one-deploy

Step 1 — Deploy the control plane

./opsforge deploy <template.yaml>

This installs OpenNebula + COGNIT Frontend on a single host. The template must provide the frontend host and the oneadmin password.

On-premises template example:

:infra:
  :hosts:
    :frontend: "192.0.2.10"        # IP or hostname, root SSH access required
:cognit:
  :one_pass: "mypassword"          # oneadmin password

AWS template example:

:infra:
  :aws:
    :region: "eu-central-1"
    :ssh_key: "my-aws-key"
:cognit:
  :one_pass: "mypassword"

When the deployment completes, OpsForge prints the access URLs:

================================================================================

Infrastructure
{"frontend": "192.0.2.10"}

Access
- Cloud-Edge Manager: oneadmin / mypassword
- Sunstone:    http://192.0.2.10:9869
- FireEdge:    http://192.0.2.10:2616
- COGNIT Frontend: http://192.0.2.10:1338
- SSH: Connect to the frontend "192.0.2.10" as root.

Logs available at ./opsforge.log

Step 2 — Deploy edge clusters

Once the control plane is up, provision one or more edge clusters with:

./opsforge deploy-edge <edge_template.yaml>

This requires no Terraform — it runs only Ansible against the existing frontend. The template must point to the already-deployed frontend and provide at least one edge host IP.

Edge template example:

:infra:
  :hosts:
    :frontend: "192.0.2.10"        # existing frontend (from Step 1)
:cognit:
  :one_pass: "mypassword"
  :flavour: "NatureFR"             # use-case flavour (see below)
  :provider: "OnPrem"              # provider name for cluster metadata
  :geolocation: "48.8566,2.3522"  # optional: lat,lon
  :edge_host_ips:
    - "192.0.2.20"                 # one or more edge hosts, root SSH access required

Available flavours: NatureFR, SmartCity, EnergyTorch, Energy, CyberSecurity

Edge hosts must be reachable by SSH from the frontend host. The deploy-edge command connects to the frontend and delegates all edge-host operations from there.

Template reference

All available fields are described in schema.json. Key fields:

Field	Required for	Description
:infra: :hosts: :frontend:	deploy (on-prem), deploy-edge	Frontend host IP/hostname
:infra: :aws:	deploy (AWS)	AWS configuration block
:cognit: :one_pass:	both	oneadmin password
:cognit: :one_version:	both	OpenNebula version (default: 7.1)
:cognit: :edge_host_ips:	deploy-edge	List of edge host IPs
:cognit: :flavour:	deploy-edge	Use-case flavour name
:cognit: :provider:	deploy-edge	Provider name for cluster metadata
:cognit: :geolocation:	deploy-edge	Cluster geolocation "lat,lon"

Build SR Appliance

A separate workflow builds the Serverless Runtime appliance using kiwi:

./opsforge build_sr <host> [sr_version] [jumphost] [flavour]

The target host must be an OpenSUSE machine with ~10 GB of free space. The result is a qcow2 image at /root/kiwi-image/output/cognit-sr.x86_64-1.0.0.qcow2 on the build host.

./opsforge build_sr 172.20.0.5
# ...
# The appliance was generated at 172.20.0.5:/root/kiwi-image/output/cognit-sr.x86_64-1.0.0.qcow2

Terminate

To destroy AWS infrastructure provisioned by OpsForge:

./opsforge clean

This runs terraform destroy on the AWS stack and removes generated config files. On-premises deployments must be cleaned up manually.