System requirements

LicOps runs as the OpenLM Router in LicOps mode, with MongoDB and Redis beside it, inside your network. Confirm the following before you deploy.

OpenLM license

Your OpenLM license must include LicOps. In OpenLM Platform, open the license summary at https://<your-platform>/licensemanager/#/license-summary and look for the LicOps feature. A license for Router failover does not include LicOps, and a license issued before LicOps existed includes neither.

Without the feature, LicOps Configuration still opens, but each page shows this notice instead of its content, and saves are refused:

LicOps License is not available with current openLM License, please contact with support team for more information.

The notice ends with a link to your OpenLM license information. If OpenLM Platform cannot reach the OpenLM LicenseManager to check the license, the pages show this notice instead, and configuration stays read-only until the check succeeds:

The LicOps license check could not be completed: the OpenLM LicenseManager is not reachable. Configuration is read-only until it answers.

A LicOps deployment that is already configured keeps running without the feature. Only changes to its configuration and rules are refused. Contact OpenLM to have your license reissued.

What you get from OpenLM

The following table lists what OpenLM supplies and how you get each item:

Item	What it is	How you get it
Container images	The Router images, and on Kubernetes the admission-webhook images	Public registry, pulled anonymously. See Deploy OpenLM LicOps.
LicOps on your license	The LicOps feature on your OpenLM license	Contact OpenLM.
HPC adapter package	The Slurm and LSF adapters and their installers	Contact OpenLM.
Integration kit	The license-map tools, a wrapper script, a Python client, an OpenAPI description and Kubernetes examples	Contact OpenLM.
Helm charts	The openlm-router and openlm-gke charts, for Kubernetes	Contact OpenLM.

Choose a platform

The following table lists what you run, how to deploy LicOps for it, and what you get:

You run	Deploy LicOps with	What you get
Slurm or LSF, or your own scheduler	Docker Compose on a Linux host, as in Deploy OpenLM LicOps	The admission API that the scheduler adapters call.
Kubernetes workloads	Helm, as in Deploy on Kubernetes	The admission API, plus the optional admission webhook that licenses annotated pods. The webhook runs on Kubernetes only.

Host requirements for Docker Compose

Confirm these requirements:

• A 64-bit Linux host. Windows hosts are not supported.
• Docker Engine 20.10 or higher, with the Docker Compose v2 plugin. Confirm with docker compose version.
• The images are published for both linux/amd64 and linux/arm64.

The following table lists the CPU, memory, and disk requirements:

Resource	Minimum	Recommended
CPU	2 vCPU	4 vCPU
Memory	2 GB	4 GB
Disk	10 GB	20 GB or more

Requirements for Kubernetes

Confirm these requirements:

• Helm 3.
• Optionally, Traefik as the cluster's ingress controller, with its IngressRoute, IngressRouteTCP, and Middleware resource types installed. With Traefik turned on, the Router chart needs the entry points web, websecure, and a TCP entry point routertcp on port 30001. Without Traefik, set traefik.enabled=false: the Router is then reachable only from inside the cluster, and you reach the Router UI with kubectl port-forward.
• To use the admission webhook: Kubernetes 1.29 or higher, permission to install a MutatingWebhookConfiguration, and either cert-manager or permission for the chart to generate its own certificate. The webhook adds its sidecar as a native sidecar container, which needs Kubernetes 1.29.
• Secrets in the target namespace, created before you install: the MongoDB connection string, the Redis connection string, and the encryption key, plus a TLS certificate while Traefik serves HTTPS, which it does by default. See Deploy on Kubernetes.

Datastores

The following table lists the datastores, their versions, and what each holds:

Datastore	Version	What it holds
MongoDB	7.x	The configuration and rules the Router collected from OpenLM Platform, and its audit log. A single node is fine.
Redis	7.0 or higher	The live seat counts, every open session, and the background job schedule of the Router.

Redis requirements

Redis 7.0 is a hard minimum. LicOps records each admission with a feature that older Redis versions do not support, so on Redis 6 every admit fails.

Configure Redis with append-only persistence and no eviction:

appendonly yes
appendfsync everysec
maxmemory-policy noeviction

Neither setting is optional. Redis holds every admitted session. If it evicts or loses them, LicOps loses track of admitted seats and can admit jobs for seats that are already taken.

Redis also holds the job schedule of the Router, which the Router registers only when it starts. If Redis comes back empty while the Router keeps running, the OpenLM Platform sync stops and the seat counts are gone: admit answers 503 with a Retry-After header until you restart the Router, which restores the schedule.

Redis Cluster is not supported.

Network requirements

The following table lists the network connections LicOps needs:

Direction	Destination	Purpose
Outbound from the Router host	Your OpenLM Platform, over HTTPS	Seat counts, server health, and the rules and reservations you define.
Inbound to the Router host, from your scheduler hosts	Port 8100	The admission API. Slurm and LSF adapters, and your own tools, call it here.
Inbound to the Router host, from your administration network only	Port 8101	The Router UI, where you connect the Router to OpenLM Platform.
Inbound to the Router host, from compute nodes	Port 30001	Only if you route license checkouts through LicOps. See Connect workloads.
Outbound from the LicOps host	Each license server's lmgrd port, the port in port@host, typically 27000	Only if you route license checkouts through LicOps.
Outbound from compute nodes	Each license server's admin and vendor-daemon ports	The license checkouts themselves, which LicOps does not proxy unless you route them through it.

Restrict access to ports 8100 and 8101

Ports 8100 and 8101 are administration interfaces. Allow access to them only from your administration network and from the hosts that submit jobs, and do not publish them to the internet. Publish only the license ports your clients use. Your submit and login nodes must reach port 8100 for admission, so allow only your scheduler hosts where you can.

OpenLM Platform prerequisites

Confirm these prerequisites in OpenLM Platform:

• Every license server in a pool is monitored through the OpenLM Broker: LicOps builds its pools from the license servers and features OpenLM Platform monitors, and only admits against those. OpenLM Platform knows a license server, its licenses, and its health only through the Broker installed on that machine, so a server without a running, approved Broker is missing from every pool. For each license server:

  1. Install the OpenLM Broker on the license server machine.
  2. Approve the Broker in Broker Hub.
  3. Approve the license server under License Servers, then Pending Servers, with Approve And Merge.
  4. Check that Live Servers Statistics in License Servers shows the server as Up.

  For more information, see Install Broker, Broker Hub, Flexera FlexNet (FLEXlm), and License Servers.

• You can open LicOps Configuration. It is under Licenses and Features in the Navigation menu of OpenLM Platform. It is where you define admission rules and reservations, so you need an account with access to it, such as an account administrator.

• You can create a Router client in Identity. In OpenLM Platform, open Identity, select Authorization, and add a client whose Client Type is Router. LicOps uses the same client type as Router failover. See Configure OpenLM LicOps.

Scheduler requirements

The following table lists the requirements for each scheduler:

Scheduler	Requirements
Slurm	curl and jq on the controller and on every submit and login node. Write access to slurm.conf.
IBM Spectrum LSF	curl and jq on the management host, the execution hosts, and every submit host. Write access to lsb.queues and to $LSF_SERVERDIR on each submit host.
Kubernetes	See Requirements for Kubernetes.
Anything else	Any tool that can send an HTTP POST with a JSON body. See Call the admission API.

Encryption key

The Router encrypts the OpenLM Platform client secret before storing it. To generate a 32-byte key once per deployment, run this command:

openssl rand -base64 32

Keep the 44-character string this prints, exactly as printed. It decrypts credentials already stored in MongoDB, so replacing it does not rotate them. It makes them unreadable, and you have to connect the Router to OpenLM Platform again. Do not run it through base64 a second time: the first save of the OpenLM Platform connection then fails.