fetch processes by machine

[imperialguy]

Looks like there is no filter to fetch processes by machine id. See here. Can you please add this?

[ezekg]

There is, but it looks like we’re missing docs for it. We’ll get those added soon. In the meantime, you can use the following:

GET https://api.keygen.sh/v1/accounts/<account>/processes?machine=<id>

[imperialguy]

I see. Great. Thanks.

Couple more things. I know these can be calculated, but wondering if we can have requests that return back the following:

1. Number of remaining machines for a license.
2. Number of remaining processes for a machine/license.

[imperialguy]

Also, one more thing. It looks like there's a soft limit on the number of processes per machine. Meaning, say, there's a limit of 2 processes per machine. After 10 mins of spawning (or if killed earlier manually), the process counter resets itself to 0. And there's an ability to spawn new processes again.

Is there anyway we can add an option to hard limit the number of processes per machine? So, after the processes are killed (either manually or due to lack of heartbeat), the counter does not always reset.

So, when the hard limit option is checked, there will be an option to send a special DELETE request to mark a process slot as consumed (e.g. similar to this - it may be something like --> DELETE https://api.keygen.sh/v1/accounts/{ACCOUNT}/processes/hard/{ID})

Say, there's max 3 process slots per machine. And you check the hard limit option in your policy. A hard-limit scenario would look something like this:

1. Send POST requests to spawn 3 processes on the machine - PID 1, PID 2 and PID 3
2. After 5 minutes, send special DELETE request to kill PID 1 - this DELETE request will also mark the process slot as consumed
3. After 6 minutes send a regular DELETE request to kill PID 2
4. After 10 minutes, you neither receive a heartbeat nor a manual kill request for PID 3, so you kill PID 3 automatically on the server as usual, but you also mark the process slot as consumed because we are enforcing a hard limit policy here.

At the end of the above scenario, the machine will only have 1 consumable process slot left, as opposed to 3 because it resets only 1 slot (from PID 2), instead of resetting all three slots.

[ezekg]

There is no soft limit. Your processes are likely being deactivated because they're dying. Unlike machines, processes require a heartbeat to be sent, by default every 10 minutes. If you want processes to stay alive, you should send regular heartbeat intervals to our API indicating that it's still running, otherwise it will die and be automatically deleted. You can kill a process at any time.

The process limit is the number of running processes allowed per-machine. If a process is killed, it no longer takes up a slot because it no longer exists. If a process's heartbeat dies, it will take up a slot until it has been automatically deleted (for which the timeframe can vary based on the policy's resurrection and cull strategies).

We don't track processes that have been killed (they no longer exist to our API after deletion). So that means they're not counted towards the machine's process limit. If you need to track killed processes, you should consider not killing the processes, and perhaps set the cull strategy to KEEP_DEAD so that processes with a dead heartbeat stick around as well.

Though I'm not sure why you would want to do that. 🙂

Lastly —

You can obtain the current license's machine count via the license object, under data.relationships.machines.meta.count.

Currently, we don't expose the current process count on the machine object, because you should really be tracking that on the machine itself (i.e. in your running application), since it's in charge of spawning and killing its processes. If you do need a process count for something, you can list the machine's processes and count the objects.

[imperialguy]

The process limit is the number of running processes allowed per-machine.

That pretty much sums up the design. The key phrase is number of running processes. Fair enough.