A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/stacklok/toolhive/compare/v0.2.3...toolhive-operator-crds-0.0.13 below:

Comparing v0.2.3...toolhive-operator-crds-0.0.13 · stacklok/toolhive · GitHub

While cleaning up the structure of the run config, I had to deal with the fact that ToolHive implements detached workload creation by deconstructing the run config back into command line arguments, and then calling the run command in a forked process. Since there is code for each value in the run config, this became a blocker for some of my plans to make the runconfig structure more generic.

After playing around with a few ideas, I came up with an approach which removes the need to pass the run config via CLI args to the detached process:

1. Create the run config and save it to disk once it has been validated.
2. If we are creating a detached workload, fork/exec and use the restart command instead of the run command. Provide the name of the workload which we created in step 1. In other words - we treat a new background workload the same way as we treat a stopped workload which was previously running.
3. Modify the restart command to have a foreground option. This way, the restart operation in the background process starts the workload instead of trying to fork again.
Advantages are:

* We get rid of a bunch of code for passing arguments to the child process.
* We no longer have to change the code for starting detached workloads each time we add a new option.
* This should bring us a little closer to our plan for implementing configuration changes.

As part of this PR, some unused existing code was removed.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4