executor:
- include all things below
- cluster service API implementation: call executor, execute a plan
  - interface: Executer.Execute(plan-name, args)

args:
- it's a source code concept: map[string]any
- args come from:
  - from API args, put into map by API implementation
    - extra arg "cluster-block": any
  - from logic/physic plan definition, put into map by plan loader
- args use to:
  - pass to all actions, every action can read a sub-set (or all) of it
    - the value type/struct of a specify key is pre-defined (by us) and is fixed
  - pass to k8s-action template, to fill the template args
    - we use the key string in template directly
    - only support simple type/struct of values: int, string, list

persisted meta list:
- template list
- action definition list
- physic plan definition list
- logic plan definition list
* we will try to cache as less and short as possible about these data in running

template:
- a block of txt content, can be any format
- has a name and a version
  - name + version == template id
  - version is a int start with 1, for simple management
- render: a template has specific marks in the content, those marks can be replaced by args
- reffer and solve: a template has another type of marks in the content, a mark can specify a template by name, so the mark can be replaced by the content from the specified template
- store in CR
  - can't delete/modify a template for safty concern
  - modify => create a new template with the same name and a higher version (+1)
  - use ops platform (UI or console) to call API to maintain templates

task:
- action + args, can directly run
- we don't need to write `task` struct in code, `action.Invoke(args)` means a task
- `action id + args` can decide a task

action:
- defines a running logic, can't run until we pass args to it (become a task)
- it's a source code concept:
  - interface Action {
      Invoke(args any) err error
      IsFinish(args any) (bool, err)
    }
  - lots of `struct XXXAction` implemented this interface
- is the smallest executable unit
- has a name and a version
  - name + version == action id
  - version is a int start with 1, for simple management

action definition:
- a block of yaml content to describe an action
- strict gramma/format (TODO: need to design it)
- can be persisted but can't be delete/modifed for safty concern
  - store in CR
    - modify => create a new action with the same name and a higher version (+1)
    - use ops platform (UI or console) to call API to maintain actions
- common properties:
  - action name: string
  - action version: uint
  - render name: string
  - render version: uint

action render:
- it's a source code concept:
  - use to parse an action definition txt content to an action in code
- there are many action renders
  - k8s
  - builtin
  - ...
- every render has `struct XXXActionRender` in code
  - corresponding the gramma/format in action definition (matched by the render name)

physic plan:
- it's a source code concept: DAG of action(s)
- the action args will be here, the args type/struct will be decided by the action id

DAG:
- it's a source code concept: a list of DAG-Node
- equal to physic/logic plan
- load by physic/logic plan loader
- a DAG equal to the leading DAG-Node

DAG-Node:
- it's a source code concept, include:
  - name + version = id
  - (optional) the node task (action name + version + args)
  - (optional) a list of dependent tasks
    - a dependent task can be one of:
      - another DAG-Node in the plan
      - an action task (action name + version + args)
- the args defined here are extra args (distinguish from the args passing from UI)
  - such as aws account
  - this allow us run the system with multi config version, good for gray-upgrade

physic plan definition:
- yaml format content to describe a DAG, fairly simple
- name + version == id
- can be persisted but can't be modifed

physic plan loader:
- it's a source code concept: load definition from txt content to become real plan

logic plan / definition / loader:
- similar with physic plan
  - except: a DAG-node in a logic plan can depend on a physic plan name
- describe the IAC-independent part of the plan
  - the IAC platform related content will be in physic plan