workflow

Documentation

Index

• func Execute(pl *ActivePlan, em *engine.Metadata, c client.Client, ...) (*kudoapi.PlanStatus, error)
• type ActivePlan

Functions

func Execute

func Execute(pl *ActivePlan, em *engine.Metadata, c client.Client, di discovery.CachedDiscoveryInterface, config *rest.Config, scheme *runtime.Scheme) (*kudoapi.PlanStatus, error)

Execute method takes a currently active plan and Metadata from the underlying operator and executes it. An execution loop iterates through plan phases, steps and tasks, executing them according to the execution strategy (serial/parallel). Task execution might result in success, error and fatal error. It is to distinguish between transient and fatal errors. Transient errors are retryable, so the corresponding Plan/Phase are still in progress:

└── first-operator-zljnmj
   └── Plan deploy (serial strategy) [IN_PROGRESS]
      └── Phase main [IN_PROGRESS]
         └── Step everything (ERROR)

However, this does not apply to fatal errors! Should a fatal error occur, we will, in the spirit of "fail-loud-and-proud", abort current execution, resulting in a plan status like:

└── first-operator-zljnmj
   └── Plan deploy (serial strategy) [FATAL_ERROR]
      └── Phase main [FATAL_ERROR]
         └── Step everything (FATAL_ERROR)

In terms of Status Message, we don't propagate the message up for fatal errors

Furthermore, a transient ERROR during a step execution, means that the next step may be executed if the step strategy is "parallel". In case of a fatal error, it is returned alongside with the new plan status and published on the event bus.

Types

type ActivePlan

type ActivePlan struct {
	Name string
	*kudoapi.PlanStatus
	Spec      *kudoapi.Plan
	Tasks     []kudoapi.Task
	Templates map[string]string
	Params    map[string]interface{}
	Pipes     map[string]string
}

ActivePlan wraps over all data that is needed for its execution including tasks, templates, parameters etc.