Resources on CloudBolt Documentation

Resource types (XaaS)

Mon, 01 Jan 0001 00:00:00 +0000

Cloud Management Platform (CMP) ships with one resource type: Service. Defining more allows the Catalog to offer items beyond servers. A blueprint names the type it deploys, and every resource it creates is listed and managed under that type. CMP calls this feature XaaS, or anything as a service.

(opens full-size image in a new tab)

Manage resource types

Go to Admin > Resource Types (XaaS). The page lists every resource type, and the Quantity column shows how many of that type you have access to. Select a type to see them.

Resource attributes

Mon, 01 Jan 0001 00:00:00 +0000

Every parameter value a resource includes is on its Parameters tab. An attribute is one you have promoted to the Overview tab, beside the resource’s group, owner, and rate, making it immediately visible.

Show a parameter as an attribute

Attributes are chosen at the parameter level, not the resource level, so the setting applies everywhere that parameter is used.

Go to Admin > Parameters and open the parameter.
Enable Show as Attribute. The switch saves once set.

A resource displays attributes it has values for, ordered by label. The same setting governs servers, where the value appears on the server’s Details tab. Enable it for a parameter used by both only if it belongs on both.

Auto scaling

Mon, 01 Jan 0001 00:00:00 +0000

Auto scaling is built from Cloud Management Platform (CMP) parts you can see and change: a rule that checks deployed resources on a schedule, plugins that read CPU load, and a parameter on each resource that sets the thresholds.

How it works

The Check Resources for Scaling Conditions rule reads each resource’s Auto-Scaling Config parameter, which sets the minimum and maximum CPU thresholds per tier. When a tier exceeds its maximum, CMP adds more servers to it and adds them to the load balancer; when it falls below its minimum, CMP deletes servers and takes them out of the rotation. A tier is also brought back inside its min_servers and max_servers bounds whatever the CPU is doing.

Resource expiration

Mon, 01 Jan 0001 00:00:00 +0000

Nothing expires on its own. Setting the date marks the resource; the Expire Resources rule is what finds it afterward and acts on it, and both the rule and its action are disabled by default. Servers expire through their own mechanism, described in Server expiration.

Set an expiration date

Provide a value for the Expiration Date parameter. There are two ways to do it:

At order time, by adding Expiration Date to the blueprint as a blueprint-level parameter, with its destination set to the resource, so the person ordering can pick a date.
On an existing resource, from its Parameters tab.

Act on expired resources

The Expire Resources rule pairs a condition that finds expired resources with an action that acts on them. Both halves are disabled by default, so enable the rule and its action before relying on it. See Rules for how rules are enabled and run, including the recurring job they depend on, which is also disabled on a new instance.