Skip to main content

Using RouteGroups

Overview​

RouteGroups are used to test application features that include changes to multiple microservices. Whereas a change to a microservice is contained in a Sandbox, RouteGroups allow you to select multiple sandboxes and have a single routing context associated with them. Additionally, it also allows you to specify one or more endpoints to any service or host within your cluster. These endpoints return hosted URLs that automatically set the appropriate request context for you to test/preview changes across multiple services.

RouteGroups can be managed through the Signadot Dashboard or the CLI.

Using RouteGroups and Sandboxes​

RouteGroups and Sandboxes may be applied independently, and each time a sandbox or routegroup is created, deleted, or changed, both the set of sandboxes matching a routegroup and routegroup status may change as a result.

This allows for workflows in which routegroups are created either before or after matching sandboxes.

In general, RouteGroups should be ready when exercising their routing context, and RouteGroups are ready whenever all their associated matched sandboxes are ready.

Some discipline or convention may be needed in order to enforce that matched sandboxes do not change while using a routegroup's routing context. More information about matching is available here.

Routing Conflicts​

It is not possible to specify RouteGroups and Sandboxes in such a way that the routing context associated with the RouteGroup would be ambiguous. This happens when 2 or more matched sandboxes refer to the same baseline workload as a fork (spec.forks[_forkOf]) or as a local workload (spec.local[_].from). In this case, it is ambiguous whether a request should be routed to one sandbox instead of another amongst those sandboxes forking the same workload.

Every change which may affect the set of sandboxes matched by a RouteGroup is checked to ensure that the routing context is unambiguous.

For example, the CLI may give this error upon creating a sandbox or changing its labels:

% signadot sandbox apply -f sb-fe2.yaml
Error: 400 Bad Request: can't upsert sandbox: for routegroup rg-1: 1 error occurred:
        * ambiguous fork: Deployment:hotrod/frontend in sandboxes {sb-fe, sb-fe2}

Also, the CLI may give this error upon creating a RouteGroup or changing its sandbox label matcher: Conventions for labeling and Route Group matching should take this into account to ensure smooth operation and unambiguous routing contexts.