Roles
A user must be assigned the admin application role to execute any of the examples described on this page.
Manage Compute Pool
Winning Variant creates its own compute pool that it uses to run its services in an isolated environment. The admin application role is granted the following permissions: OPERATE, MODIFY, USAGE, MONITOR . This means that an admin can alter the compute pool directly.
All services are designed to run on a single instance, so there’s no point in increasing the number of nodes in the compute pool as each service will still use just a single instance.
Manage Services
The Winning Variant services can be managed by an admin using the following stored procedures (all within the management schema):
| Procedure | Description |
|---|
suspend_services() | Suspends all services. |
suspend_config_service() | Suspends just the configuration service. |
suspend_variant_service() | Suspends just the variant service. |
resume_services() | Resumes all services. |
resume_config_service() | Resumes the configuration service. |
resume_variant_service() | Resumes the variant service. |
get_service_status() | Gets the status of all services. |
get_service_endpoints() | Shows ingress URLs for all services. |
Examples
USE <application_name>;
-- Suspend all services
CALL management.suspend_services();
-- Check status of services
CALL management.get_service_status();
Task Scheduling
Winning Variant maintains a few internal tasks whose schedules can be modified to fit your company’s needs. Each task’s schedule may be modifed with the following stored procedure:
management.set_task_schedule(task_name VARCHAR, schedule VARCHAR)
| Parameter | Description |
|---|
task_name | The name of the task to reschedule. Possible values are listed below. |
schedule | A string defining the new schedule. Any string value compatible with the SCHEDULE parameter for CREATE TASK will work here. |
Available tasks are:
| Task Name | Description | Default Schedule |
|---|
assignments_load | Loads new assignments into the table for immediate analysis. | At the 0:00 and 0:30 minute of each hour. |
assignments_cache_snapshot | Takes a snapshot of the block storage volume that contains the internal assignment cache. | Nightly at midnight Pacific Time. |
variant_config_refresh | Forces a refresh of the configuration used by the Variant API.
The configuration is updated in real time when an experiment is modified, but this is a “belt and suspenders” approach to make sure that it’s correct at least hourly if something gets out of sync. | At the top of each hour. |
Example
-- Load assignments once an hour
CALL management.set_task_schedule('assignments_load', '1 hour')
Configuration Properties
While certain components of the app are configurable directly via SQL (i.e., scaling a compute pool), other components may be configured indirectly.
Properties
| Property | Description | Default |
|---|
ASSIGNMENTS:LOAD_DELAY_SECONDS | How long (in seconds) to delay assignment loading. This is done to ensure that internal stages get caught up before loading data into a table. Snowflake doesn’t offer an SLA for stage syncing, so this should be long enough to handle most cases. If it’s too short, some data may not get picked up and will need to wait for the next run. | 60 |
Set configuration property
To set a property, execute the following procedure:
CALL management.set_config_property('<property>', '<value>')
-- Reduce the assignment load delay to 10 seconds
CALL management.set_config_property('ASSIGNMENTS:LOAD_DELAY_SECONDS', '10')
All values are stored as strings. So even a number, such as 100 should be stored as '100'.
Get configuration properties
To see the current configuration properties, perform a SELECT from management.config_properties.
Example
-- See all configuration properties
SELECT * FROM management.config_properties;
