[new feature] More granular workflow phases in Resource Plugin Spec

[gamino-brex]

New feature or functionality

There are currently two phases for plugin workflows:

_“create and delete represent plugin phase workflows to execute. Each phase defines a workflow as a sequence of steps, represented as an array. _
The create phase workflow is executed during sandbox startup, before sandboxed workloads are spun up. The delete phase workflow is executed during Sandbox termination, after sandboxed workloads have terminated.” — excerpt from Resource Plugin Specification document

We would like the two existing workflow phases to be more strictly named to match their exact behavior:

• create would be pre-create;
• delete would be post-delete;

And add more four phases:

• post-create would execute after the sandbox creation is complete;
  • Workflow phase ordering:
    1. 1st signadot sandbox apply (using the CLI);
    2. pre-create;
    3. Sandbox created;
    4. post-create;
• pre-update would execute before any change is applied to an existing sandbox;
• post-update would execute after any change is applied to an existing sandbox;
  • Workflow phase ordering:
    1. 2nd and onward signadot sandbox apply on an existing sandbox (using the CLI);
    2. pre-update;
    3. Sandbox updated;
    4. post-create;
• pre-delete would execute before any change is applied to an existing sandbox;
  • Workflow phase ordering:
    1. signadot sandbox delete (using the CLI);
    2. pre-delete;
    3. Sandbox deleted;
    4. post-delete;

Additional considerations

Use case: Fork or update additional sandboxed ingresses

Some workloads are tied to Kubernetes resources. In our case GraphQL services rely on Ingresses to appropriately make the request routing to a sandboxed GraphQL service. Our tooling allows them to add more forks to a sandbox after the sandbox is created. This means that if any GraphQL service is deployed after the sandbox is created, the routing would never work, since we run a custom resource plugin on the create phase. With the addition of pre-update, this would allow us to update and/or fork additional ingresses to new GraphQL services added to any existing sandbox.

The above is one concrete example, but it applies to any dependent resource from a forked workload added to an existing sandbox after its creation.