Struct LoadbalancerCommand 

pub struct LoadbalancerCommand { /* private fields */ }

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.

An optional vip_sg_ids attribute can be used to set custom Neutron Security Groups that are applied on the VIP port of the Load Balancer. When this option is used, Octavia does not manage the security of the Listeners, the user must set Security Group Rules to allow the network traffic on the VIP port. vip_sg_ids are incompatible with SR-IOV load balancer and cannot be set if the load balancer has a listener that uses allowed_cidrs.

Implementations

impl LoadbalancerCommand

pub async fn take_action<C: CliArgs>( &self, parsed_args: &C, client: &mut AsyncOpenStack, ) -> Result<(), OpenStackCliError>

Perform command action

Trait Implementations

impl Args for LoadbalancerCommand

fn group_id() -> Option<Id>

Report the ArgGroup::id for this set of arguments

fn augment_args<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate Self via FromArgMatches::from_arg_matches_mut

fn augment_args_for_update<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate self via FromArgMatches::update_from_arg_matches_mut

impl FromArgMatches for LoadbalancerCommand

fn from_arg_matches(__clap_arg_matches: &ArgMatches) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn from_arg_matches_mut( __clap_arg_matches: &mut ArgMatches, ) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn update_from_arg_matches( &mut self, __clap_arg_matches: &ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.

fn update_from_arg_matches_mut( &mut self, __clap_arg_matches: &mut ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.