OpenLM LicOps

When a cluster starts more licensed jobs than it has free seats, the jobs that lose the race fail after they reach a node, or hold the node while they wait for a license. OpenLM LicOps checks for a seat before the job starts. Your scheduler asks LicOps for a seat when the job is submitted, and LicOps answers yes or no. When the job starts, LicOps tells it which license server to check out from.

OpenLM LicOps is in early availability

OpenLM LicOps is in early availability. It isn't listed in Products, then Downloads in OpenLM Platform. You deploy it from the container images described in Deploy OpenLM LicOps, and OpenLM supplies the scheduler adapters. Contact OpenLM before you plan a production rollout.

Choose between the Router and LicOps

OpenLM ships two products as one program, the OpenLM Router. The mode you give the Router at its first start decides which product it is:

Aspect	OpenLM Router (failover)	OpenLM LicOps
Built for	Engineers on workstations, whose FlexLM clients use one license server	HPC clusters and Kubernetes workloads that start many licensed jobs at once
What it does	Moves clients from a failed primary server to its backup	Admits a job only when a seat is free, and picks the license server for it from a pool, the servers that serve the same vendor and feature
License servers	A primary and an optional backup for each application	Any number of servers for each vendor and feature
What you configure in OpenLM Platform	Port mappings	Admission rules and reservations
Router mode	basic	loadBalancer

Choose one for your OpenLM account: failover or LicOps, not both. LicOps Configuration in OpenLM Platform works with one Router at a time, the one that reported most recently. If you need failover for workstation users, see OpenLM Router instead.

How a job goes through LicOps

LicOps answers three requests in the life of every job. The scheduler adapters make them for you. A custom integration makes them itself.

1. Admit: when the job is submitted. The adapter asks for one or more seats of one vendor and feature. LicOps answers Admit or Deny. A denied job never enters the queue.
2. Dispatch: when the job starts on a node. LicOps names the license server to check out from, in port@host form. If the server it planned on has failed since admission, LicOps moves the seat to a healthy server that serves the same feature.
3. Release: when the job ends, whether it succeeds, fails, or is canceled. The seat returns to the pool.

LicOps tracks each job as a session, named by a session ID that the caller generates and sends with all three requests.

A pool is every license server that serves one vendor daemon and feature, written VENDOR:FEATURE, for example MLM:MATLAB. Every request names a pool, never a server: LicOps chooses the server.

Where the seat counts come from

LicOps takes the license servers, their seat totals, the seats in use, and the health of each server from OpenLM Platform, about every 10 seconds. The OpenLM Broker on each license server reports them to OpenLM Platform, so LicOps can only use servers whose Broker reports to OpenLM Platform. To that it adds what only LicOps knows: the seats it has admitted that are not checked out yet. LicOps calculates the free seats as follows:

free = total − in use − admitted, not yet checked out

That last term is what stops the last seat being given out twice. The license manager cannot see a job that is still starting, so without LicOps two jobs could both be admitted for one free seat. LicOps evaluates the whole sum in one step for each request, and corrects its count against the figures from OpenLM Platform about every 10 seconds.

Nothing is held at the license server. LicOps does not check licenses out and does not reserve them in FlexLM. Your applications check out exactly as they do today, from the server that dispatch names or from the server they already use.

How LicOps chooses a server

Without rules, LicOps places each admitted seat on the least-loaded healthy server in the pool. To change that, write admission rules in OpenLM Platform. With them you can keep a server for one team, fill cheaper servers first, spread jobs evenly, or slow a burst of checkouts. See Control placement with admission rules. To cap how many seats LicOps hands out on a server at certain times of day, see Cap seats on a schedule.

Whether the application then checks out from the server LicOps chose depends on how you connect your workloads. See Decide whether LicOps also chooses the server.

What you deploy

LicOps runs in your own network, next to your scheduler. It only calls out to OpenLM Platform. Nothing on the OpenLM Platform side opens a connection to it.

The following table lists the components you deploy:

Component	Where it runs	What it does
The Router, in LicOps mode	A Linux host with Docker, or your Kubernetes cluster, with MongoDB and Redis	Answers admit, dispatch, and release requests. Its browser page connects it to OpenLM Platform.
Slurm or LSF adapters	Your scheduler's controller and submit hosts	Make the three requests at the submission, start and end of every licensed job. OpenLM supplies them.
Kubernetes admission webhook	Your Kubernetes cluster	Makes the three requests for pods that you annotate. Optional.
OpenLM Broker	Each license server in a pool	Reports the server, its licenses, and its health to OpenLM Platform. You might already run it.

You define admission rules and reservations in OpenLM Platform, under LicOps Configuration. The Router collects them about every 10 seconds, the same way a failover Router collects its port mappings.

LicOps terms

The following table lists the names you meet when you work with LicOps:

Name	What it is
OpenLM Router	The program LicOps runs on. In LicOps mode, its status reads Load balancer mode active and its mode is loadBalancer.
LicOps Configuration	The OpenLM Platform app, under Licenses and Features, where you see the LicOps settings and define admission rules and reservations. It also configures a failover OpenLM Router, where it shows Port Mappings.
Pool	Every license server that serves one vendor daemon and feature, such as MLM:MATLAB.
Session	One job's seats, from admit to release, named by a session ID the caller generates.
Listen port	Port 30001 on the LicOps host. It matters only if you route checkouts through LicOps.
Router UI	The browser page on the LicOps host where you connect LicOps to OpenLM Platform.
Client Type Router	The identity client type LicOps signs in with, the same as a failover Router.
OpenLM Broker	The OpenLM component on each license server that reports the server, its licenses, and its health to OpenLM Platform.

Current limitations

LicOps has these limitations:

• Tested with FlexLM only: Pools and checkouts are FlexLM vendor daemons and features.
• Seats are counted, not held: A user who checks out a license without going through LicOps, from a workstation for example, still takes a seat. LicOps sees that seat in the next in-use figure from OpenLM Platform, not before.
• Reservations cap seats but do not hold them: A reservation limits how many seats LicOps hands out on a server. It does not set seats aside on the license server. See Cap seats on a schedule.
• LSF support is in early access: validate the adapters on a non-production queue before you rely on them. Each LSF job can ask for one vendor and feature, while the Slurm adapter admits several licenses for one job.
• The Kubernetes interception chain is pre-release: The sidecar and init-container images are development builds. Calling the API directly from a Kubernetes job is not affected.
• 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. See System requirements.

In this section

Work through the pages in order:

1. System requirements: the license, host, datastores, network, and OpenLM Platform access LicOps needs.
2. Deploy OpenLM LicOps: run the Router in LicOps mode with Docker Compose. To deploy on Kubernetes, see Deploy on Kubernetes.
3. Configure OpenLM LicOps: connect LicOps to OpenLM Platform and check that it sees your pools.
4. Control placement with admission rules: optional, decide which server each job lands on.
5. Cap seats on a schedule: optional, limit the seats LicOps hands out during set hours.
6. Connect workloads: wire Slurm, LSF, Kubernetes, or your own tools to LicOps.
7. Operate OpenLM LicOps: see what LicOps is holding and find out why a job was denied.
8. Troubleshooting: what the common symptoms mean.
9. API reference: every request, response, and deny reason.