Note: this PR relies on #277 , and so that must be merged first.
This PR introduces the plugin module and some initial type definitions, as well as some code for turning a Plugin into a PluginContext object that will act as a wrapper interface for the gRPC channel (converting between tonic-generated types and "nicer" ones, maintaining the child process handle, etc.)`
The logic for how startup occurs is a first try, and should be subject to discussion. Rather than a MAX_CONN_ATTEMPTS to handle syncronizing the plugin process and Hipcheck, I would support adding a requirement that the plugin outputs to stdout some notifying message like "Ready." that we can wait for.
The code of this PR compiles, but is untested. It would require defining an actual plugin, and injecting a way to test this code into main.rs. We may want to consider switching to a library-style crate so that we can have multiple different bin/ files to enable easier testing of code such as this.
Note: this PR relies on #277 , and so that must be merged first.
This PR introduces the
pluginmodule and some initial type definitions, as well as some code for turning aPlugininto aPluginContextobject that will act as a wrapper interface for the gRPC channel (converting betweentonic-generated types and "nicer" ones, maintaining the child process handle, etc.)`The logic for how startup occurs is a first try, and should be subject to discussion. Rather than a
MAX_CONN_ATTEMPTSto handle syncronizing the plugin process andHipcheck, I would support adding a requirement that the plugin outputs tostdoutsome notifying message like "Ready." that we can wait for.The code of this PR compiles, but is untested. It would require defining an actual plugin, and injecting a way to test this code into
main.rs. We may want to consider switching to a library-style crate so that we can have multiple differentbin/files to enable easier testing of code such as this.