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.
Each sandbox can be updated up to 50 times. After 50 successful updates,
further updates to that sandbox are rejected with a 403 Forbidden
response. To make additional changes, delete & recreate the sandbox, or
create a new one with a different name.
Tracking the update count
Once a sandbox gets close to the fair usage limit, the Signadot Dashboard starts
showing how many updates it has used. On the sandbox detail page, the
Metadata section then displays the update count against the limit (for
example, 50 / 50), and hovering over it explains that the sandbox has reached
the fair usage limit and that you should create a new sandbox to continue making
changes. Until the sandbox nears the limit, no update count is shown.
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.
Sandbox resources can be updated. However updating resources will render all in-cluster aspects of the sandbox non-functional until the resources can be re-created.
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 sandboxes with local mappings). 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.
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.