osc load-balancer loadbalancer create
Creates a load balancer.
This operation provisions a new load balancer by using the configuration that you define in the request object. After the API validates the request and starts the provisioning process, the API returns a response object that contains a unique ID and the status of provisioning the load balancer.
In the response, the load balancer provisioning status is ACTIVE
, PENDING_CREATE
, or ERROR
.
If the status is PENDING_CREATE
, issue GET /v2/lbaas/loadbalancers/{loadbalancer_id}
to view the progress of the provisioning operation. When the load balancer status changes to ACTIVE
, the load balancer is successfully provisioned and is ready for further configuration.
If the API cannot fulfill the request due to insufficient data or data that is not valid, the service returns the HTTP Bad Request (400)
response code with information about the failure in the response body. Validation errors require that you correct the error and submit the request again.
Administrative users can specify a project ID that is different than their own to create load balancers for other projects.
An optional flavor_id
attribute can be used to create the load balancer using a pre-configured octavia flavor. Flavors are created by the operator to allow custom load balancer configurations, such as allocating more memory for the load balancer.
An optional vip_qos_policy_id
attribute from Neutron can be used to apply QoS policies on a loadbalancer VIP, also could pass a ‘null’ value to remove QoS policies.
You can also specify the provider
attribute when you create a load balancer. The provider
attribute specifies which backend should be used to create the load balancer. This could be the default provider (octavia
) or a vendor supplied provider
if one has been installed. Setting both a flavor_id and a provider will result in a conflict error if the provider does not match the provider of the configured flavor profiles.
Specifying a Virtual IP (VIP) is mandatory. There are three ways to specify a VIP network for the load balancer:
Additional VIPs may also be specified in the additional_vips
field, by providing a list of JSON objects containing a subnet_id
and optionally an ip_address
. All additional subnets must be part of the same network as the primary VIP.
Usage: osc load-balancer loadbalancer create [OPTIONS]
Options:
-
--additional-vips <JSON>
— A list of JSON objects defining “additional VIPs”. The format for these is{"subnet_id": <subnet_id>, "ip_address": <ip_address>}
, where thesubnet_id
field is mandatory and theip_address
field is optional. Additional VIP subnets must all belong to the same network as the primary VIP.New in version 2.26
-
--admin-state-up <ADMIN_STATE_UP>
— The administrative state of the resource, which is up (true
) or down (false
). Default istrue
Possible values:
true
,false
-
--availability-zone <AVAILABILITY_ZONE>
— An availability zone name -
--description <DESCRIPTION>
— A human-readable description for the resource -
--flavor-id <FLAVOR_ID>
— The ID of the flavor -
--listeners <JSON>
— The associated listener IDs, if any -
--name <NAME>
— Human-readable name of the resource -
--pools <JSON>
-
--project-id <PROJECT_ID>
— The ID of the project owning this resource -
--provider <PROVIDER>
— Provider name for the load balancer. Default isoctavia
-
--tags <TAGS>
-
--tenant-id <TENANT_ID>
-
--vip-address <VIP_ADDRESS>
— The IP address of the Virtual IP (VIP) -
--vip-network-id <VIP_NETWORK_ID>
— The ID of the network for the Virtual IP (VIP). One ofvip_network_id
,vip_port_id
, orvip_subnet_id
must be specified -
--vip-port-id <VIP_PORT_ID>
— The ID of the Virtual IP (VIP) port. One ofvip_network_id
,vip_port_id
, orvip_subnet_id
must be specified -
--vip-qos-policy-id <VIP_QOS_POLICY_ID>
— The ID of the QoS Policy which will apply to the Virtual IP (VIP) -
--vip-subnet-id <VIP_SUBNET_ID>
— The ID of the subnet for the Virtual IP (VIP). One ofvip_network_id
,vip_port_id
, orvip_subnet_id
must be specified