HTTP call to terminate k6 process

[yorugac]

Feature Description

Currently there is a Stop test HTTP call which allows to stop the test itself but does not terminate the k6 process. This is easily noticeable when using --linger option: even after using Stop test HTTP call, k6 process must be terminated with an interrupt. (Ctrl + C, SIGTERM, etc.)

It would be good to have a possibility to terminate a running k6 process with HTTP API as well.

The absence of this call is esp. noticeable when trying to implement distributed test while native distribution mode is not available yet.
Probably a rare case, but it might also come in handy in non-distributed setups that are relying on HTTP API as well.

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

This possibility was previously mentioned here:
#2804

Also, a related discussion is here:
#3217 (comment)

[mstoykov]

Is this currently needed by something(k6-operator) - as I would prefer to leave it for #3217 which likely will completely redo the rest API either way.

[yorugac]

From my perspective, if #3217 comes with the necessary API changes, then that's sufficient for k6-operator (it'll need to be re-worked afterwards anyway).

I've got an impression that this separate issue is needed as part of the process for #3217? cc @codebien

[codebien]

as I would prefer to leave it for #3217 which likely will completely redo the rest API either way.

@mstoykov can you expand and define what it means for you redo in this context, please?

If it means rewriting from scratch the HTTP API then I don't think that is strictly required for the distributed execution. It is something we may consider as nice to have to build on top. But only after we did the first iterations and we validated the core's ideas behind the distributed execution.
For sure, we may set it as a requirement for a final version of the distributed execution. But for the first iterations, we should just have the current API's endpoints fully working in the distributed execution mode.
And, eventually, we could be very aggressive in the first experimental phase without having all the endpoints fully working, if they are not relevant for the goal.

But it could miss something relevant here, so please let me know.

[mstoykov]

@mstoykov can you expand and define what it means for you redo in this context, please?

If it means rewriting from scratch the HTTP API then I don't think that is strictly required for the distributed execution

AFAIK there isn't anything in the current API that is useful for distributed execution apart from setup/teardown calls - and those in practice need to be redone.

Both me and (AFAIK) Ned never intended for keepign this API

#995
#3497

There really isn't a reason for us to try to reuse, espcially as the current PoC uses gRPC to communicate - which also makes a lot more sense.

To be honest - I don't have a hard opinion, I just:

1. don't want us to add stuff that aren't needed
2. don't want us to try to fix stuff that don't need to be fixed

IMO - if you have a way to start an instance, you have a way to stop an instance. As the rest API isn't available for you to start it (and distributed execution won't change this) - I see no reason why we need to have an API to kill it. The whole starting and stopping machines is still outside of k6. and preferably should stay there as I don't really want to reimplement k8s.

So if someone needs this ... because somehow there is no way for them to stop and instance after somehow starting it - then we can add this. Otherwise, why should we 🤷

[codebien]

Both me and (AFAIK) Ned never intended for keepign this API

Me neither, my focus was on not doing it as part of distributed execution. If we keep them independent then I'm all for it. Except, if you see a direct dependency between them. Do you see it?

don't want us to try to fix stuff that don't need to be fixed
IMO - if you have a way to start an instance, you have a way to stop an instance. As the rest API isn't available for you to start it

Then we are going in the opposite direction from the original post. Instead of expanding we want to remove. I agree and I'm fine with it.

@mstoykov Now, my question is, do we need API v2 for what? It seems to me most of the API is designed to serve use cases relevant only before 1007 or to cover the native distribution execution absence.

[mstoykov]

Now, my question is, do we need API v2 for what?

I don't know - but we defintely do not have distributed execution at the moment, so up until that point I don't think I will be able to give you a good answer.

There likely will still be some need for pprof and debug vars endpoints. Whether k6 will continue to have a REST API for other operations arguably is a question that needs to be asnwered when we can remove it - as currently they do exist for a reason.

[codebien]

We can close this issue, as expanding the current API is not in our plans, and as we plan to address #3217 which makes mostly useless --linger so, in the end, there isn't a requirement for the proposal here.