Important: We can not use resources abstraction, because we will need an ability to build different graphs for tasks in lifecycle management Also moved all specs to doc/spec directory
2.1 KiB
Problem: Different execution strategies
We will have different order of execution for different actions (installation, removal, maintenance)
- Installation and removal of resources should be done in different order.
- Running maintenance tasks may require completely different order of actions, and this order can not be described one time for resources, it should be described for each action.
IMPORTANT: In such case resources are making very little sense, because we need to define different dependencies and build different executions graphs for tasks during lifecycle management
Dependency between resources
Several options to manage ordering between executables
- Allow user to specify this order
- Explicitly set requires/require_for in additional entity like profile
- Deployment flow should reflect data-dependencies between resources
1st option is pretty clear - and we should provide a way for user to manage dependencies by himself (even if they will lead to error during execution)
2nd is similar to what is done in fuel, and allows explicitly set what is expected to be executed. However we should not hardcode those deps on resources/actions itself. Because it will lead to tight-coupling, and some workarounds to skip unwanted resource execution.
3rd option is manage dependencies based on what is provided by different resources. For example input: some_service
Please note that this format is used only to describe intentions.
:: image: ref: namespace: docker value: base_image
Practically it means that docker resource should be executed before some_service. And if another_service needs to be connected to some_service
:: connect: ref: namespace: some_service value: port
But what if there is no data-dependencies?
In such case we can add generic way to extend parameters with its requirements, like:
::
requires:
- ref:
namespace: node