Disclaimer: this is more of a train of thought than a well thought out idea, but I'd like to discuss it.
Rufio is currently an 'optional' component. An orchestration component is responsible for arranging the Rufio Jobs and Tink Workflows (this is essentially what CAPT does for provisioning Kubernetes clusters).
Is there a use-case for tighter integration between Tink Core and Rufio by supplying fields on Workflows? Would it, for example, be useful to allow users to specify some sort of "boot strategy" on a Workflow that results in a netboot?
Assuming we worked out the details of a "boot strategy" the result would be a fully automated machine provisioning solution that can be executed with a single workflow instead of requiring an additional orchestration layer.
An example boot strategy could be "issue the series of commands to netboot every 60s until the first action transitions to 'running'".
Disclaimer: this is more of a train of thought than a well thought out idea, but I'd like to discuss it.
Rufio is currently an 'optional' component. An orchestration component is responsible for arranging the Rufio Jobs and Tink Workflows (this is essentially what CAPT does for provisioning Kubernetes clusters).
Is there a use-case for tighter integration between Tink Core and Rufio by supplying fields on Workflows? Would it, for example, be useful to allow users to specify some sort of "boot strategy" on a Workflow that results in a netboot?
Assuming we worked out the details of a "boot strategy" the result would be a fully automated machine provisioning solution that can be executed with a single workflow instead of requiring an additional orchestration layer.
An example boot strategy could be "issue the series of commands to netboot every 60s until the first action transitions to 'running'".