Sandbox 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

Sandbox updates do not allow one to update an aribtrary part of a sandbox specification in an arbitrary way. Most fields of a sandbox specification are in fact immutable -- only endpoints, forks and ttl may be updated.

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

For forks, addition of forks and arbitrary changes to a fork specification are supported. 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.

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

Forks remove and changes to sandbox resources may be supported in the future.

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.