Products define the services exposed by a Provider.
Rationale
Providers expose services into UCloud. But, different Providers expose different services. UCloud uses Products to define the services of a Provider. As an example, a Provider might have the following services:
Storage: Two tiers of storage. Fast storage, for short-lived data. Slower storage, for long-term data storage.
Compute: Three tiers of compute. Slim nodes for ordinary computations. Fat nodes for memory-hungry applications. GPU powered nodes for artificial intelligence.
For many Providers, the story doesn't stop here. You can often allocate your Jobs on a machine "slice". This can increase overall utilization, as users aren't forced to request full nodes. A Provider might advertise the following slices:
Name
vCPU
RAM (GB)
GPU
Price
example-slim-1
1
4
0
0,100 DKK/hr
example-slim-2
2
8
0
0,200 DKK/hr
example-slim-4
4
16
0
0,400 DKK/hr
example-slim-8
8
32
0
0,800 DKK/hr
Table: A single node-type split up into individual slices.
Concepts
UCloud represent these concepts in the following abstractions:
Below, we show an example of how a Provider can organize their services.
Figure: All Products in UCloud are of a specific type, such as: STORAGE and COMPUTE. Providers have zero or more categories of every type, e.g. example-slim. In a given category, the Provider has one or more slices.
Payment Model
UCloud uses a flexible payment model, which allows Providers to use a model which is familiar to them. In short, a Provider must first choose one of the following payment types:
📝 NOTE: To select a model, you must specify a ChargeType and a ProductPriceUnit. We have shown all valid combinations above.
Quotas put a strict limit on the "number of units" in concurrent use. UCloud measures this number in a Product specific way. A unit is pre-defined and stable across the entirety of UCloud. A few quick examples:
If using an absolute model, then you must choose the unit of allocation:
You specify allocations in units (UNITS_PER_X). For example: 3000 IP addresses.
You specify allocations in money (CREDITS_PER_X). For example: 1000 DKK.
📝 NOTE: For precision purposes, UCloud specifies all money sums as integers. As a result, 1 UCloud credit is equal to one millionth of a Danish Crown (DKK).
When using periodic payments, you must also specify the length of a single period. Providers are not required to report usage once for every period. But the reporting itself must specify usage in number of periods. UCloud supports period lengths of a minute, one hour and one day.
The pricePerUnit specifies the cost of a single unit in a single period.
Products not paid with credits must have a pricePerUnit of 1. Quotas and one-time payments are always made for a single "period".
This can lead to some surprising results when defining compute products. Let's consider the example from the beginning:
Name
vCPU
RAM (GB)
GPU
Price
example-slim-1
1
4
0
0,100 DKK/hr
example-slim-2
2
8
0
0,200 DKK/hr
example-slim-4
4
16
0
0,400 DKK/hr
example-slim-8
8
32
0
0,800 DKK/hr
Table: Human-readable compute products.
When implementing this in UCloud, a Provider might naively set the following prices:
Name
ChargeType
ProductPriceUnit
Price
example-slim-1
ABSOLUTE
CREDITS_PER_HOUR
100_000
example-slim-2
ABSOLUTE
CREDITS_PER_HOUR
200_000
example-slim-4
ABSOLUTE
CREDITS_PER_HOUR
400_000
example-slim-8
ABSOLUTE
CREDITS_PER_HOUR
800_000
Table: ️⚠️ Incorrect implementation of prices in UCloud ️⚠️
This is wrong. UCloud defines the price as the cost of using a single unit in a single period. The "unit of use" for a compute product is a single vCPU. Thus, a correct Provider implementation would over-report the usage by a factor equal to the number of vCPUs in the machine. Instead, the price must be based on a single vCPU:
Name
ChargeType
ProductPriceUnit
Price
example-slim-1
ABSOLUTE
CREDITS_PER_HOUR
100_000
example-slim-2
ABSOLUTE
CREDITS_PER_HOUR
100_000
example-slim-4
ABSOLUTE
CREDITS_PER_HOUR
100_000
example-slim-8
ABSOLUTE
CREDITS_PER_HOUR
100_000
Table: ✅ Correct implementation of prices in UCloud ✅
Only providers and UCloud administrators can create a Product. When this endpoint is invoked by a provider, then the provider field of the Product must match the invoking user.
The Product will become ready and visible in UCloud immediately after invoking this call. If no Product has been created in this category before, then this category will be created.
📝 NOTE: Most properties of a ProductCategory are immutable and must not be changed. As a result, you cannot create a new Product later with different category properties.
If the Product already exists, then a new version of it is created. Version numbers are always sequential and the incoming version number is always ignored by UCloud.
Paginated content can be requested with one of the following consistency guarantees, this greatly changes the semantics of the call:
Consistency
Description
PREFER
Consistency is preferred but not required. An inconsistent snapshot might be returned.
REQUIRE
Consistency is required. A request will fail if consistency is no longer guaranteed.
The consistency refers to if collecting all the results via the pagination API are consistent. We consider the results to be consistent if it contains a complete view at some point in time. In practice this means that the results must contain all the items, in the correct order and without duplicates.
If you use the PREFER consistency then you may receive in-complete results that might appear out-of-order and can contain duplicate items. UCloud will still attempt to serve a snapshot which appears mostly consistent. This is helpful for user-interfaces which do not strictly depend on consistency but would still prefer something which is mostly consistent.
The results might become inconsistent if the client either takes too long, or a service instance goes down while fetching the results. UCloud attempts to keep each next token alive for at least one minute before invalidating it. This does not mean that a client must collect all results within a minute but rather that they must fetch the next page within a minute of the last page. If this is not feasible and consistency is not required then PREFER should be used.
📝 NOTE: Services are allowed to ignore extra criteria of the request if the next token is supplied. This is needed in order to provide a consistent view of the results. Clients should provide the same criterion as they paginate through the results.