Currently in the project repository we have the Python and associated bash scripts required for stack orchestrator functionality, plus all the definitions for building and deploying our supported stack components.
This made sense initially in order to move fast and ship something. But now that the tool is more mature we should split these things into separate projects and add functionality to the core tool to support that.
To clarify: we would end up with a stack-orchestrator repository that contains nothing specific to one stack or container, plus several other repositories each containing the stuff related to specific stacks. The two would need to be combined at runtime, akin to fetching a container image from docker hub or an npm package from npmjs.com.
dboreham
commented
1 year ago
Currently in the project repository we have the Python and associated bash scripts required for stack orchestrator functionality, plus all the definitions for building and deploying our supported stack components.
E.g. we have code like this that constitutes the tool: https://github.com/cerc-io/stack-orchestrator/blob/main/app/build_containers.py
and also files like this that are specific to the building of one container required for a particular stack: https://github.com/cerc-io/stack-orchestrator/blob/main/app/data/container-build/cerc-fixturenet-eth-geth/run-el.sh
This made sense initially in order to move fast and ship something. But now that the tool is more mature we should split these things into separate projects and add functionality to the core tool to support that.
To clarify: we would end up with a stack-orchestrator repository that contains nothing specific to one stack or container, plus several other repositories each containing the stuff related to specific stacks. The two would need to be combined at runtime, akin to fetching a container image from docker hub or an npm package from npmjs.com.