License validation performed by machines running a "feature"

[LucaNicosia]

Hi team,

I'm interested in using keygen to create licenses for a controller-worker environment.
The deployment requires a unique controller with multiple workers.
What I would like to use keygen for is to verify that the deployment associated with a license is running a SINGLE controller and as many workers as the license supports.
Is it something which is possible with keygen or my tool should perform this kind of logic?

[ezekg]

What is a controller, exactly? At first glance, it sounds like you could configure the license to allow a single machine, and then set the license's max processes to whatever your worker limit is. Then, activate the controller as a machine and all workers as processes of that machine. This would effectively allow a single controller (machine) and up in n processes (workers) per-controller.

[LucaNicosia]

Your solution looks good when we are deploying our environment on a single machine. But what about a distributed deployment such as kubernetes? We want to have a single pod for the controller, but multiple worker pods.
Since in the deployment there must be a proxy server to connect our app to keygen, I can have inside the proxy server component some logic to detect which component want to be verified. This will require a single license with n (workers) + 1 (controller) machines.

My question is: is it possible to have this logic inside keygen instead of inside my proxy?

Another question: Since I'm exploring the deployment on k8s, I'm trying to understand how to use a floating license. I'm using an heartbeat policy on my license. If I do not send the heartbeat, the machine status becomes "DEAD" and after a while it is automatically removed from the machines. I didn't see in the docs how much is the time between "DEAD" and "deleted from the machines table" and if it's configurable or not

[ezekg]

Processes are spawned and maintained per-machine, so this model can scale to n machines with m processes per-machine. I'm not sure what logic you're referring to here, so if you could, could you explain what you'd expect Keygen to do here? That'd help me be able to determine if what you're looking for is possible. I'm not 100% sure what you mean when you say "to detect which component."

As for your latter question — dead machines are typically deactivated immediately after death, though this could vary based on their resurrection strategy and cull strategy, as well as a few other factors. But most are deactivated immediately. Worst case, they'll be deactivated within their heartbeat duration, or 10 minutes, whichever is shortest.

[LucaNicosia]

Long story short: My entire statement was wrong and keygen cannot do much about it because it's not what it is designed for. I apologize for wasting your time

Long answer:
The infrastructure I'm going to validate using keygen has 1 controller (always unique) and N workers. Each worker is defined by a unique id and 2 workers with the same id cannot coexist.
My original question was "is there a way to let keygen understand that this machine is assigned to "worker-123" and if another "worker-123" (in another machine) tries to join, reject it?". I think the answer for this is no.
Moreover, in a multiprocess deployment, the machine fingerprint for 2 different workers will be the same, so I cannot even push on keygen the fact that I have 2 workers on the same machine.
So, this entire logic will be performed by me and I'll use keygen only for license validation and tracking of the machines

[ezekg]

Like I said, if you were to use machines for controllers, and then processes for workers, this may work. We'd need to introduce a processUniquenessStrategy policy setting to enforce process PID uniqueness across more than just its machine, e.g. across a license, policy or product. This would prevent duplicate processes (workers) across machines (controllers). Would this work for your use case? Let me know if I'm missing anything here.