Skip to main content

openstack_cli_block_storage/v3/
cluster.rs

1// Licensed under the Apache License, Version 2.0 (the "License");
2// you may not use this file except in compliance with the License.
3// You may obtain a copy of the License at
4//
5//     http://www.apache.org/licenses/LICENSE-2.0
6//
7// Unless required by applicable law or agreed to in writing, software
8// distributed under the License is distributed on an "AS IS" BASIS,
9// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
10// See the License for the specific language governing permissions and
11// limitations under the License.
12//
13// SPDX-License-Identifier: Apache-2.0
14
15//! Block storage Cluster commands
16//!
17
18use clap::{Parser, Subcommand};
19
20use openstack_cli_core::{cli::CliArgs, error::OpenStackCliError};
21use openstack_sdk::AsyncOpenStack;
22
23pub mod list;
24pub mod show;
25
26/// Clusters (clusters)
27///
28/// Administrator only. Lists all Cinder clusters, show cluster detail, enable or disable a
29/// cluster.
30///
31/// Each cinder service runs on a host computer (possibly multiple services on the same host; it
32/// depends how you decide to deploy cinder). In order to support High Availability scenarios,
33/// services can be grouped into clusters where the same type of service (for example,
34/// cinder-volume) can run on different hosts so that if one host goes down the service is still
35/// available on a different host. Since there’s no point having these services sitting around
36/// doing nothing while waiting for some other host to go down (which is also known as
37/// Active/Passive mode), grouping services into clusters also allows cinder to support
38/// Active/Active mode in which all services in a cluster are doing work all the time.
39///
40///
41/// **Note**: Currently the only service that can be grouped into clusters is cinder-volume.
42///
43/// Clusters are determined by the deployment configuration; that’s why there is no
44/// ‘create-cluster’ API call listed below. Once your services are up and running, however, you can
45/// use the following API requests to get information about your clusters and to update their
46/// status.
47#[derive(Parser)]
48pub struct ClusterCommand {
49    /// subcommand
50    #[command(subcommand)]
51    command: ClusterCommands,
52}
53
54/// Supported subcommands
55#[allow(missing_docs)]
56#[derive(Subcommand)]
57pub enum ClusterCommands {
58    List(Box<list::ClustersCommand>),
59    Show(Box<show::ClusterCommand>),
60}
61
62impl ClusterCommand {
63    /// Perform command action
64    pub async fn take_action<C: CliArgs>(
65        &self,
66        parsed_args: &C,
67        session: &mut AsyncOpenStack,
68    ) -> Result<(), OpenStackCliError> {
69        match &self.command {
70            ClusterCommands::List(cmd) => cmd.take_action(parsed_args, session).await,
71            ClusterCommands::Show(cmd) => cmd.take_action(parsed_args, session).await,
72        }
73    }
74}