> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt
> Use this file to discover all available pages before exploring further.
# Resource Types
> Reference for all Xloud Orchestration resource types — compute, networking, storage, identity, and orchestration primitives with definition examples.
## Overview
Xloud Orchestration supports over 100 built-in resource types covering the full range
of cloud infrastructure. Each resource type maps to a specific cloud service API. The
Orchestration engine provisions resources in dependency order and tracks their lifecycle
as part of the parent stack.
Resource type names use the `Xloud::Service::ResourceType` convention. Available
resource types depend on the services enabled in your cluster.
***
## Resource Categories
| Category | Service | Common Resource Types |
| ----------------- | ------------------- | --------------------------------------------------------------------- |
| **Compute** | Xloud Compute | Server, KeyPair, ServerGroup |
| **Networking** | Xloud Networking | Net, Subnet, Router, RouterInterface, FloatingIP, SecurityGroup, Port |
| **Storage** | Xloud Block Storage | Volume, VolumeAttachment |
| **Identity** | Xloud Identity | Project, User, Role |
| **Orchestration** | Xloud Orchestration | Stack, WaitCondition, AutoScalingGroup, ScalingPolicy |
***
## Resource Definition Structure
Every resource follows this structure:
```yaml title="resource-structure.yaml" theme={null}
resources:
logical_resource_name:
type: Xloud::Service::ResourceType # Required
depends_on: # Optional — explicit ordering
- other_resource_name
condition: my_condition # Optional — conditional creation
deletion_policy: Delete # Optional — Retain | Snapshot | Delete
properties: # Required — resource configuration
property_name: value
property_from_param: { get_param: param_name }
property_from_resource: { get_resource: other_resource }
metadata: # Optional — arbitrary key-value data
custom_key: custom_value
```
### `depends_on` and Dependency Resolution
The engine automatically detects dependencies from intrinsic functions like
`get_resource` and `get_attr`. Use `depends_on` only for ordering requirements
that cannot be expressed through property references.
```yaml title="explicit-dependency.yaml" theme={null}
resources:
network:
type: Xloud::Networking::Net
properties:
name: app-network
subnet:
type: Xloud::Networking::Subnet
depends_on: [network] # Wait for network before creating subnet
properties:
network_id: { get_resource: network }
cidr: "10.0.1.0/24"
```
***
## Resource Examples by Category
### Xloud::Compute::Server
```yaml title="compute-server.yaml" theme={null}
resources:
web_server:
type: Xloud::Compute::Server
properties:
name: web-server
image: { get_param: image }
flavor: { get_param: flavor }
key_name: { get_param: key_name }
security_groups:
- { get_resource: web_sg }
networks:
- network: { get_param: network }
user_data_format: RAW
user_data: |
#!/bin/bash
apt-get install -y nginx
systemctl enable --now nginx
```
### Xloud::Compute::KeyPair
```yaml title="keypair.yaml" theme={null}
resources:
deploy_key:
type: Xloud::Compute::KeyPair
properties:
name: deploy-key
save_private_key: true # Private key returned as stack output
outputs:
private_key:
value: { get_attr: [deploy_key, private_key] }
```
### Xloud::Compute::ServerGroup
```yaml title="server-group.yaml" theme={null}
resources:
anti_affinity_group:
type: Xloud::Compute::ServerGroup
properties:
name: web-anti-affinity
policies:
- anti-affinity # Spread instances across different hosts
```
### Xloud::Networking::Net
```yaml title="network.yaml" theme={null}
resources:
app_network:
type: Xloud::Networking::Net
properties:
name: app-network
admin_state_up: true
```
### Xloud::Networking::Subnet
```yaml title="subnet.yaml" theme={null}
resources:
app_subnet:
type: Xloud::Networking::Subnet
properties:
name: app-subnet
network_id: { get_resource: app_network }
cidr: "192.168.10.0/24"
ip_version: 4
dns_nameservers:
- "8.8.8.8"
- "1.1.1.1"
enable_dhcp: true
```
### Xloud::Networking::Router and RouterInterface
```yaml title="router.yaml" theme={null}
resources:
router:
type: Xloud::Networking::Router
properties:
name: app-router
external_gateway_info:
network: { get_param: external_network }
router_interface:
type: Xloud::Networking::RouterInterface
properties:
router_id: { get_resource: router }
subnet_id: { get_resource: app_subnet }
```
### Xloud::Networking::FloatingIP
```yaml title="floating-ip.yaml" theme={null}
resources:
floating_ip:
type: Xloud::Networking::FloatingIP
properties:
floating_network: { get_param: external_network }
floating_ip_assoc:
type: Xloud::Networking::FloatingIPAssociation
properties:
floatingip_id: { get_resource: floating_ip }
port_id: { get_attr: [web_server, addresses, app-network, 0, port] }
```
### Xloud::Networking::SecurityGroup
```yaml title="security-group.yaml" theme={null}
resources:
web_sg:
type: Xloud::Networking::SecurityGroup
properties:
name: web-security-group
description: Allow HTTP, HTTPS, and SSH
rules:
- protocol: tcp
port_range_min: 22
port_range_max: 22
remote_ip_prefix: "0.0.0.0/0"
- protocol: tcp
port_range_min: 80
port_range_max: 80
remote_ip_prefix: "0.0.0.0/0"
- protocol: tcp
port_range_min: 443
port_range_max: 443
remote_ip_prefix: "0.0.0.0/0"
```
### Xloud::BlockStorage::Volume
```yaml title="volume.yaml" theme={null}
resources:
data_volume:
type: Xloud::BlockStorage::Volume
properties:
name: app-data
size: 100 # GB
volume_type: ceph-ssd
description: Application data volume
```
### Xloud::BlockStorage::VolumeAttachment
```yaml title="volume-attachment.yaml" theme={null}
resources:
data_volume_attach:
type: Xloud::BlockStorage::VolumeAttachment
properties:
instance_uuid: { get_resource: web_server }
volume_id: { get_resource: data_volume }
mountpoint: /dev/vdb
```
### Xloud::Identity::Project
```yaml title="project.yaml" theme={null}
resources:
app_project:
type: Xloud::Identity::Project
properties:
name: my-app-project
description: Project for the application team
enabled: true
```
### Xloud::Identity::User
```yaml title="user.yaml" theme={null}
resources:
svc_user:
type: Xloud::Identity::User
properties:
name: svc-deployer
password: { get_param: svc_password }
email: svc-deployer@example.com
enabled: true
```
### Xloud::Orchestration::Stack (Nested Stack)
```yaml title="nested-stack.yaml" theme={null}
resources:
database_tier:
type: Xloud::Orchestration::Stack
properties:
template: { get_file: database-stack.yaml }
parameters:
flavor: { get_param: db_flavor }
network: { get_resource: app_network }
```
### Xloud::Orchestration::WaitCondition
Use `WaitCondition` to pause stack creation until an external signal is received
(e.g., after cloud-init completes application installation):
```yaml title="wait-condition.yaml" theme={null}
resources:
wait_handle:
type: Xloud::Orchestration::WaitConditionHandle
app_ready:
type: Xloud::Orchestration::WaitCondition
depends_on: [app_server]
properties:
handle: { get_resource: wait_handle }
timeout: 300 # Seconds to wait for signal
count: 1
app_server:
type: Xloud::Compute::Server
properties:
user_data:
str_replace:
template: |
#!/bin/bash
apt-get install -y myapp
# Signal completion
curl -X POST "$WAIT_URL" -d '{"Status": "SUCCESS", "UniqueId": "app"}'
params:
$WAIT_URL: { get_resource: wait_handle }
```
***
## Next Steps
Template structure, parameters, intrinsic functions, and conditions
Auto-scaling group and scaling policy resource examples
Create, update, and manage the stack lifecycle
Diagnose resource provisioning failures and dependency errors