feat(api): namespace wide disable/enable/stop/delete/update/ready operations on processes

[dzmitry-lahoda]

• for feat(namespace): down/stop all processes in namescape API/CLI #378
• for question: child process-composes #377

I did not moved mutex from per process to per "namespace". So should I? Currently we accept concurrency to some degree. We could improve concurrency by non erroring idempotent (delete deleted), but seems current code will need a lot of refactor.

Also there is no good split for 5xx vs 4xx errors - because low level code does not do it nor other APIs.

For me both acceptable, but imho there should be task to make errors more structured as go can later for whole API.

Add to API only, it is up to later PR make it CLI/ Go client if deemed useful, so better to be do correct errors first.
Let settle semantics first in API to keep PR smallest possible.

[dzmitry-lahoda]

As for testing, I will do Rust CLI and write Rust tests in our project. If any issues will return with PR.

[dzmitry-lahoda]

@F1bonacc1 I do not think it can be merged, so some design could be discussed?

Why something like this to be in Process Compose.

• to use PC remotely, behind some automation, in tests (or other transient jobs), seems need something to be. so it is not one user use case, but agenda for many. i provided design and impl of one of option.
• making own things on client side, can end up build own mutex covering whole PC OpenAPI methid, that is harder than should be and harder to maintain. providing what API can as part of Go and CLI clients later will need even more wrapping boiler plate. so making outside is hard.
• error handling. i feel that error handling to be improved (made more typed overtime). changes can only start in PC code, not string contains by outside code.

[F1bonacc1]

I think this is a good idea.
This make NSs a more important concept in the PC than it is today.
Thanks for the initiative.

I left you a few comments about the implementation.
Most of them are related to the business logic being implemented in the API instead of the project runnner.

Can you please also add some tests? I am not sure that there won't be any race issues. Check with make testrace.

[dzmitry-lahoda]

This make NSs a more important concept in the PC than it is today.

Yeah, people can add more things too later. For example TUI grouping or depends_on namespace or like.

Can you please also add some tests? I am not sure that there won't be any race issues. Check with make testrace.

Ok will do tests.

[dzmitry-lahoda]

@F1bonacc1 are tests for such changes usually written on api level or on project runner level?

[dzmitry-lahoda]

As of now "testing" on API(OpenAPI) level via Rust in our test runner codebase. Will send some patches if any after.

[F1bonacc1]

@F1bonacc1 are tests for such changes usually written on api level or on project runner level?

Project runner level. See system_test.go. We want to check concurrency issues (make testrace).

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dzmitry-lahoda]

need to add namespace ready after #396, so that I can make test(test = namespace) setup wait ready

[dzmitry-lahoda]

ready seems hard to define. so just need to return 404 when there is no such namespace at least for now.

impl of not ready or other can be decided by client (handling status code + state + config).

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud