As a GPU PaaS customer, you should be given credentials allowing access to your GPU-PaaS Openstack project. This document assumes that you are already familiar with accessing openstack APIs and resources in general, but will guide you through the usage of the specific resources that make up the Spot usage of the product.

Description

A Spot Instance is a non-priority instance in the Cloud platform, aimed at providing temporary computing resources for businesses that can afford running computations when the cloud service is not highly loaded by higher-priority usages.

A Spot instance may be terminated by the cloud services, with a few guarantees and constraints:

  • Spot Instances are created using the Flavors containing preemptible in their names
  • Instances are guaranteed a minimum uptime of 30 minutes
  • Instances are notified 15 minutes before their termination

Spawning a Spot Instance

As previously mentioned, a specific set of Flavors, containing “preemptible” in their names must be used to identify an Instance as a Spot Instance.

As an example, assuming our basic GPU computation Flavor is named boost-c8m12-gpu-1080-1, the first word would be followed by the preemptible, yielding the Spot flavor boost-preemptible-c8m12-gpu-1080-1.

There is currently no specific limitation on various Openstack resources that may or may not be attached to a Spot Instance, this is up to your needs.

Watching out for an imminent termination

When the cloud platform wishes to free up resources for higher priority usages, it will select Spot Instances for termination. Upon doing so, it provides one passive means

Checking the Metadata from within the Instance

When an Instance is Active (running), Openstack provides a networked service, that acts as a facility allowing the software within the Instance to get its metadata. Two methods are available, and documented by Openstack :

  • An Openstack “native” method
  • An Amazon EC2 compatible method

As an example, this section shows how to use the Openstack way to collect the metadata’s JSON payload:

curl -s http://169.254.169.254/openstack/latest/meta_data.json
{
    ...
    "meta": {
        "cloud_termination_scheduled_event_time": 128749143,
        "cloud_termination_time": 128712743,
        ...
    },
    ...
}

Upon scheduling a termination for an Instance, the cloud services will augment its metadata with two keys:

  • cloud_termination_scheduled_event_time: timestamp at which the Instance’s termination was decided by the cloud service
  • cloud_termination_time: timestamp at which the Instance is expected to be terminated.

Both pieces of information are provided in order to prevent a situation where one notification might have been missed, and the user would be surprised by too small a delay before actual termination.

Registering a WebHook to receive HTTP Notifications on an external service

In a completely different approach, a Webhook registration service is available to allow consuming specific notifications from Openstack in general.

By subscribing to the notifications related to cloud_termination events, you can be notified of any scheduled termination of any Instance in your Projects.

This section will walk you through the registration of your Webhook in the cloud service, assuming you already have a service complying to our expected Webhook API.

Webhook Registration flow

The Webhook registration requires two main steps:

  1. Registering the webhook itself, associating the webhook URL with the project refered to by the authentified user
  2. Subscribing to one or more notifications, based on supported filters

Note that to interact with the Webhook management service, you will need an Openstack (Keystone) authentication token, scoped to the project you want to register the webhook for, using the usual X-auth-token HTTP Header to provide you token to the service.

The following schema aims to transcribe the described the steps, in order, and with slightly more detail:

sequenceDiagram
    participant Webhook
    actor Customer
    participant Management Service
    participant OpenStack

    Customer->>Management Service: Register webhook URL
    Customer->>Management Service: Subscribe to specific notifications

    OpenStack->>Management Service: Emit event notification
    Management Service->>Management Service: Check for subscriptions
    Management Service->>Webhook: Forward notifications to relevant subscriptions
    Webhook->>Customer: Deliver notification

Through the use of a scoped authentication token, the webhook and subscriptions are guaranteed to only handle resources from the project the token is scoped to.

OpenAPI Specifications for the services

Now that you know the general flow to register your webhook service and receive notification, you can take a look at our complete OpenAPI Specifications, clarifying possible remaining questions that you may have:

The first one will give you the full API description of the webhook management service, while the second one specifies the API your webhook service must offer to the webhook system.