Skip to main content

dtcloud_lb (Resource)

Manages a load balancer -- the front door that accepts connections and the object every listener, pool and member hangs off.

A load balancer owns listeners, a listener owns a pool, and a pool owns members and at most one health monitor. Each is a separate resource, so changing a health monitor does not disturb the members.

Example Usage​

# Pick the size by name rather than pasting an id. Every name is offered twice --
# once without high availability and once with it -- so filter on both.
data "dtcloud_lb_flavors" "small" {
  name = "small"
  ha   = false
}

resource "dtcloud_lb" "public" {
  name        = "web-lb"
  description = "HTTPS front end for the web tier"
  flavor_id   = data.dtcloud_lb_flavors.small.flavors[0].id

  # Exactly one of vip_network_id, vip_subnet_id or vip_port_id decides where the
  # VIP lives. The platform enforces the same rule.
  vip_network_id = dtcloud_network.app.id
}
note

The VIP anchor is exactly one of three. vip_network_id, vip_subnet_id or vip_port_id decides where the address lives. Declaring the rule here turns a server-side rejection into a plan-time error.

Schema​

Required​

  • flavor_id (String) ID of the load balancer flavor (sizing). Changing this forces a new resource to be created.
  • name (String) Name of the load balancer. Can be changed in place.

Optional​

  • description (String) Free-text description. Can be changed in place.
  • enabled (Boolean) Whether the load balancer is administratively enabled.
  • external_network_id (String) External network used when a floating IP is requested. Changing this forces a new resource to be created.
  • floating_ip (String) Floating IP to associate with the load balancer. Changing this forces a new resource to be created.
  • network_type (String) Network type. The API currently accepts only Virtual. Changing this forces a new resource to be created.
  • timeouts (Block, Optional) (see below for nested schema)
  • vip_address (String) Specific VIP address to request. Allocated by the platform when omitted. Changing this forces a new resource to be created.
  • vip_network_id (String) Network to place the VIP on. Changing this forces a new resource to be created.
  • vip_port_id (String) Existing port to use for the VIP. Changing this forces a new resource to be created.
  • vip_subnet_id (String) Subnet to place the VIP on. Changing this forces a new resource to be created.

Read-Only​

  • balancing_pools (Number) Number of balancing pools configured on the load balancer.
  • created_on (String) When the load balancer was created, as reported by the API.
  • flavor_name (String) Human-readable name of the flavor.
  • high_availability (String) High-availability mode, reported as Enabled or Disabled. It is not settable here: HA is chosen by picking a flavor whose ha flag is true, so this reports back the flavor's setting.
  • id (String) The ID of this resource.
  • members_state (List of String) Operating state of each member.
  • members_total (Number) Total number of members across all pools.
  • network (List of Object) The network the load balancer's VIP sits on. (see below for nested schema)
  • status (String) Provisioning status, e.g. ACTIVE or ERROR.

Nested Schema for timeouts​

Optional:

  • create (String)
  • delete (String)
  • update (String)

Nested Schema for network​

Read-Only:

  • id (String)
  • ip (String)
  • name (String)

Behaviour worth knowing​

  • Only name, description and enabled change in place. The VIP placement and the flavor are fixed at creation; changing either rebuilds the load balancer and everything hanging off it.
  • High availability is a property of the flavor. There is no separate switch: each size is offered twice, once with ha = false and once with ha = true, and they are different flavors with different ids. Pick the HA one from dtcloud_lb_flavors.
  • The status vocabulary is the API's, not the raw platform's. A load balancer reports one title-case word -- Creating, Configuring, Active, Disabled, Deleting, Error or Unknown. Disabled is a healthy load balancer with no listener yet, and Unknown is one with a pool but no health monitor; neither is a failure.
  • One change at a time. The platform locks a load balancer while a change is in flight and refuses anything else until it settles. The provider waits for the lock and retries, which is what lets Terraform create a monitor and a member in parallel without either failing.
  • Do not mix the two styles. Use the granular resources, or dtcloud_lb_balancing_pool, but not both on the same load balancer -- the granular resources would find objects they did not create.

Timeouts​

create defaults to 30 minutes, update and delete to 15. Creating, updating and deleting are all asynchronous: the API answers at once and the provider polls until the load balancer settles.

Import​

terraform import dtcloud_lb.public 3d372446-4c75-4327-9511-98442456162f

enabled is not reported back, so an imported load balancer shows one in-place update that sets it to whatever the configuration says, and is quiet from then on. The VIP anchor is recovered as the network the address ended up on; if you anchored to a subnet or a port, say so in the configuration after importing.