Decouple tool functionality from payload #315

New Issue

dboreham · 2023-04-11T13:29:12Z

dboreham commented

2023-04-11 13:29:12 +00:00

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.

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.

👍 1

dboreham commented

2023-04-11 13:30:23 +00:00

We have done some of this already with the hosting repo.

We have done some of this already with the [hosting ](https://github.com/cerc-io/hosting) repo.

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/stack-orchestrator#315