Updates

Overview

Sandboxes can be updated, allowing changes to endpoints and forks to be incrementally applied. Those endpoints or forks which do not change accross a sequence of updates will generally remain functional without interruption. Updates facilitate a variety of sandbox use cases, including ad-hoc interactive use and consolidation of changes to many workloads in one sandbox.

Constraints on Updates

Most fields of a sandbox specification are in fact mutable -- endpoints, forks, local, labels, and ttl may be updated.

For endpoints and ttl, addition, removal, and arbitrary changes to the fields are supported.

For updating forks and locals, some constraints need to be considered. First, each baseline workload in a Sandbox can be referred to at most once, by either a fork or a local.

Starting with Signadot Operator v0.14.0, one may arbitrarily update forks and locals as well as mix forks and locals in a sandbox, provided each baseline is referred to at most once. This facilitates many workflows, including local debuging of a PR based Sandbox.

Prior to Signadot Operator v0.14.0, addition of forks and arbitrary changes to a fork specification are supported, and addition, removal, and arbitrary changes to local workloads are also supported (provided the operator supports local sandboxes). However, one cannot remove a fork, as this may engender conflicts when a fork is removed and added in succession faster than Kubernetes terminates and recreates the associated workloads. Additionally, mixing forks and locals in a Sandbox is not supported for these operator versions.

Note also that sandbox resources cannot be updated, although it may be desireable.

Updates and Readiness

When a sandbox is updated, any changes to the forks will trigger the creation of the correspondingly changed workloads in the sandbox's cluster. The sandbox is considered ready when all its workloads are ready, which in turn is defined by Kubernetes readiness probes.

As a result, after an update one generally should wait for sandbox readiness, and this behavior is the default in the CLI.

Updates and Endpoints

When a sandbox is updated, endpoint URLs which do not change continue to work. Additionally, the routing key is preserved for request routing. The persistence of endpoint URLs across updates allows one to share a single given URL and use it to view different changes to a sandbox over time. The persistence of routing keys accross updates allows testing code to be applied to several sets of changes without reconfiguration.