Module openstack_sdk::api::load_balancer::v2::loadbalancer::create
source · Expand description
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.
Structs§
- Type for additional vips
- Builder for
AdditionalVips. - Defines mandatory and optional attributes of a POST request.
- Builder for
DefaultPool. - Defines mandatory and optional attributes of a POST request.
- Builder for
Healthmonitor. - Defines mandatory and optional attributes of a POST request.
- Builder for
L7policies. - Defines mandatory and optional attributes of a POST request.
- Builder for
Listeners. - A load balancer object.
- Builder for
Loadbalancer. - Defines mandatory and optional attributes of a POST request.
- Builder for
Members. - Defines mandatory and optional attributes of a POST request.
- Builder for
Pools. - Defines mandatory and optional attributes of a POST request.
- Builder for
PoolsHealthmonitor. - Defines mandatory and optional attributes of a POST request.
- Builder for
RedirectPool. - Defines mandatory and optional attributes of a POST request.
- Builder for
RedirectPoolHealthmonitor. - Builder for
Request. - Defines mandatory and optional attributes of a POST request.
- Builder for
Rules. - Defines mandatory and optional attributes of a POST request.
- Builder for
SessionPersistence.
Enums§
- Error type for AdditionalVipsBuilder
- Error type for DefaultPoolBuilder
- Error type for HealthmonitorBuilder
- Error type for L7policiesBuilder
- Error type for ListenersBuilder
- Error type for LoadbalancerBuilder
- Error type for MembersBuilder
- Error type for PoolsBuilder
- Error type for PoolsHealthmonitorBuilder
- Error type for RedirectPoolBuilder
- Error type for RedirectPoolHealthmonitorBuilder
- Error type for RequestBuilder
- Error type for RulesBuilder
- Error type for SessionPersistenceBuilder