ocicli(1)

NAME
ocicli - configure your baremetal cluster through the OCI API

SYNOPSIS
ocicli <command> [options]

DESCRIPTION

The ocicli shell script configures the cluster OCI drives.

OUTPUT FORMAT

-csv

    ocicli may be called with -csv as first argument to display using a csv output.

COMMANDS

machine-list [-a|all] [-v|--versions] [-s|--status] [-z|--zones] [-r|--racking] [-n|--network] [-h|--hardware] [-b|--blockdevs] [-i|--ipmi] [-l|--links] [-f|--filter]

    List all the computers recorded in the OCI database. This command understand a few flags as below. Each time, there is a shorter version of the option using the first letter of the argument and a single minus sign.

--all | -a
    Display all fields, as if all display options where passed. This usually doesn't fit on a normal screen, but may be useful when parsing the output in CSV mode.

--versions | -v
    Display BIOS, Dell Lifecycle and IPMI firmware versions.

--status | -s
    Display the operating system installation and puppet run statuses. Also display the time of the last run of openstack-cluster-installer-agent. Note that the agen only runs when the machine is running in Debian live, before being installed.

--zones | -z
    Display the cluster name, swift region and location where the machine has been installed.

--network | -n
    Display the networking information, such as IP addresses.

--ethernet | -e
    Display the network interfaces with MAC addresses and speed and the switch name and interface connected to it.

--hardware | -h
    Display the hardware configuration of the machine, including the amount of available memory, and the detected block and network devices.

--blockdevs | -b
    Display the connected block devices.

--ipmi | -i
    Display the IPMI information.

--links | -l
    Display the network interfaces without MAC addresses and speed. This is useful as the -e option can be very wide and not display well on smaller screens.

--filter <field=value> | -f <field=value>
    Filter the output with field and values. For example, if one would like to display only the servers in a datacenter called d4 and row b, here is how: ocicli machine-list -r -f loc_dc=4,loc_row=b

machine-show <serial-num|hostname>

    Show the details about a computer in the cluster.

machine-ipmi-adopt <serial-num>

    This command is useful when the IPMI is using dhcp. This command sets the current IPMI IP as the one currently in use in the server, it then sets a new (random) password for user number 2 (as per ipmitool user list 1), and records user, password and IP in the OCI db for later use.

machine-guessed-profile <serial-num|hostname> [-d / --debug]

    Show the guessed hardware profile according to /etc/openstack-cluster-installer/hardware-profiles.json. This is useful to tweak hardware-profiles.json by trials and errors. The -d or --debug option help designing hardware-profiles.json, by showing how profiles are filtered.

machine-check-megacli-applied <serial-num|hostname> [hardware-profile-name]

    Check if the megacli profile is applied or not. If no hardware profile is given as parameter, it is then guessed.

machine-megacli-apply <machine_serial> [hardware_profile_name]"

    Apply the MegaCli commands to a machine. If no hardware profile is given as parameter, it is then guessed.

machine-megacli-reset-raid <machine_serial>

    Reset the RAID configuration of a machine, removing all RAID devices.

machine-guess-racking <machine_serial>

    Print the datacenter, row, rack and position in the rack, as guessed by OCI, reading /etc/openstack-cluster-installer/auto-racking.json.

machine-auto-rack <machine_serial>

    Fill-up the racking information as machine-guess-racking would guess it.

machine-auto-add <machine_serial>

    Automatically add a machine to a cluster, guessing its role thanks to the hardware profiles defined in /etc/openstack-cluster-installer/hardware-profiles.json (needed to guess the machine role) and the racking infomation in /etc/openstack-cluster-installer/auto-racking.json (needed to guess the machine location name).

machine-to-dns <machine_serial>

    Record the machine hostname into an external DNS service. This works only if the [dns_plugin] section of openstack-cluster-installer.conf is configured properly. See the OCI contrib folder in the source of OCI to see how to write the plugin shell script.

machine-out-of-dns <machine_serial>

    Delete the machine from DNS using the plugin script.

machine-to-monitoring <machine_serial>

    Insert the machine into the monitoring system. This works only if the [monitoring_plugin] section of openstack-cluster-installer.conf is configured properly. See the OCI contrib folder in the source of OCI to see how to write the plugin shell script.

machine-out-of-monitoring <machine_serial>

    Delete the machine from monitoring using the plugin script.

machine-gen-root-pass <machine_serial>

    Generate a random password, ssh into the machine, and set this password for root. Optionally, if the [root_pass_plugin] section of openstack-cluster-installer.conf is configured properly, record the root password using the configured helper script. It is adviced to use something like Hashicorp Vault or OpenStack Barbican for storing these root passwords.

machine-forget-root-pass <machine_serial>

    Remove the root password from the password store, using the plugin script.

machine-set <serial-num> [options]

    Set properties of a computer in the cluster. Options are as below.

--hostname <hostname>
    Overrides the hostname as calculated by OCI when adding a computer in a cluster. Must be issued before installing a server.

--install-on-raid <yes/no>
    Install the operating system using software RAID. See below on how to configure such a RAID array.

--raid-type <0/1/10/5>
    Select RAID type 0, 1, 10 or 5.

--raid-dev0 <sda>
    Select sda for the RAID device 0.

--raid-dev1 <sda>
    Select sda for the RAID device 1.

--raid-dev2 <sda>
    Select sda for the RAID device 2.

--raid-dev3 <sda>
    Select sda for the RAID device 3.

--serial-console-device <ttyS0/ttyS1/none>
    Select the serial console device for the main console output. This is very useful if one is using IPMI and serial over LAN. This will influence both the way grub is configured, and systemd configuration for starting up the serial console. Note that this option must be set before installing the operating system, it will not be modified after install.

--dc <string>
    Data center where the computer is installed. This is seen in machine-show or machine-list -a.

--row <string>
    Data center rack row where the computer is installed. This is seen in machine-show or machine-list -a.

--rack <string>
    Rack where the computer is installed. This is seen in machine-show or machine-list -a.

--ustart <num>
    Rack unit start where the computer is installed. This is seen in machine-show or machine-list -a.

--uend <num>
    Rack unit end where the computer is installed. This is seen in machine-show or machine-list -a.

--ceph-use-if-available <yes/no>
    Set a compute node to use Ceph as the backend for /var/lib/nova/instances.

--ceph-az <0/1/2/3/4/5/6/7/8/9>
    Set the CEPH AZ for a compute host, cephmon or cephosd (if using multiple ceph AZ). This does not work for billosd / billmon that are always on AZ 0.

--nested-virt <yes/no>
    Set this to yes if wishing to enable nested virtualization in a compute node.

--use-gpu <yes/no>
    Set this to yes if the compute node is providing a GPU to its guests.

--gpu-name <name>
    Set the name of the GPU (free string). This option is only useful is uising --use-gpu yes.

--gpu-vendor-id
    Set the PCI ID of the vendor of the GPU, as seen by lspci -nn. This option is only useful is uising --use-gpu yes.

--gpu-produc-id <ID>
    Set the product ID of the GPU, as seen by lspci -nn. This option is only useful is uising --use-gpu yes.

--gpu-device-type <type-PCI/type-PF/type-VF>
    Set the type of GPU to do passthrough with. Note that this depends on the GPU card and firmware. For example, newer Nvidia Tesla T4 require type-PF when older firmware required type-PCI.

--vfio-ids <IDs>
    VFIO IDs that must be passed to the kernel module when starting. Multiple ID strings can be passed, separated by the + caracter. A reboot (after puppet is applied) of the compute node is necessary for this to be applied. This option is only useful is uising --use-gpu yes.

--cpu-mode <host-model/host-passthrough/custom/cluster_value>
    Set the CPU mode of a compute. With host-passthrough, all of the compute node CPU flags will be exposed to a guest. With custom, the cpu-model must be set (see below). With cluster_value, the compute node inherit from the parameter set at the cluster level.

--cpu-model <MODEL>
    Set the CPU model exposed to Qemu guests. The full list of supported CPU model is to be found in the Qemu documentation. This option is

--cpu-model-extra-flags <FLAG1,FLAG2>
    Extra CPU flags to pass to the guests.

--swift-store-account <yes/no>
    Activate Accounts storage on a swiftproxy or swiftstore node.

--swift-store-container <yes/no>
    Activate Containers storage on a swiftproxy or swiftstore node.

--swift-store-object <yes/no>
    Activate Objects storage on a swiftproxy or swiftstore node.

--servers-per-port <int>
    Number of servers per port for a swift Objects server.

--disk-chunk-size <int>
    Disk chunk size for swift objects server.

--network-chunk-size <int>
    Network chunk size for swift objects server.

--lvm-backend-name
    Set the name of the LVM backend. Only applies to Cinder volume nodes. This can be helpful to distinguish between 2 different backend, for example with one backend being SSD, the other one being HDD.

--ipmi-use <yes/no>
    If set, this computer uses IPMI.

--ipmi-call-chassis-bootdev <yes/no>
    If set, this computer supports using IPMI to set the boot device (ie: disk or PXE).

--ipmi-username <username>
    Sets the IPMI username for this computer. After setting this value, ocicli machine-apply-ipmi must be called.

--ipmi-password <password>
    Sets the IPMI password for this computer. After setting this value, ocicli machine-apply-ipmi must be called.

--ipmi-addr <ipaddr>
    Sets the IPMI address to contact the IPMI of this computer. After setting this value, ocicli machine-apply-ipmi must be called.

--ipmi-port <port>
    Sets the IPMI port to contact the IPMI of this computer. After setting this value, ocicli machine-apply-ipmi must be called.

--ipmi-netmask <netmask>
    Sets the IPMI netmask for this computer. The default value is 255.255.255.0. After setting this value, ocicli machine-apply-ipmi must be called.

--ipmi-default-gw <gatewayip>
    Sets the IPMI default gateway for this computer. The default value for the IPMI gateway is the first valid IP address of the network as per the IPMI address and the IPMI netmask. After setting this value, ocicli machine-apply-ipmi must be called.

--ceph-osd-initial-setup
    When a machine acting as Ceph OSD, its OSDs are setup once on the first puppet runs, and then automatically, this is disabled. This parameter makes it possible to force the setup to be ran again, for example if a new block device is added to the host. It is recommended to leave this not activated in production, to handle gracefully borken block devices.

--force-no-bgp2host
    If a cluster is set to use a bgp-to-the-host networking, some servers, for example network nodes, may need to use L2 connectivity. If this parameter is set to yes, then L2 connectivity will be forced, instead of bgp-to-the-host over IPv6 unnumbered.

--ipmi-vlan <vlanid|off>
    Sets the IPMI vlan. The default value for the IPMI VLAN is off, meaning no VLAN is tagged. After setting this value, ocicli machine-apply-ipmi must be called.

machine-add [--fixed-ip <ipaddr>] <serial-num> <cluster-name> <role-name> <location-name>

    Add a machine to a cluster. The networks attached to location specified will automatically be assigned to that computer (ie: IP addresses will be reserved for that machine). If it is a network node (or a controller that acts as a network node if no network nodes are defined on the cluster) or a compute node, if it exists, the vm-net will also be added to the machine. If it is a cephosd node, and a ceph network exist, it will also be added to the machine. When the optional parameter --fixed-ip is added, the IP address must be in the pool that OCI will use automatically when adding the machine. The IP must also be free.

machine-remove <serial-num>

    Remove a machine from a network, and make it available so it can be added again in a cluster.

machine-destroy <serial-num>

    Completely remove a computer (and all of its attached network card and block storage devices) from the OCI database. The only way to have it re-appear is to run the discovery agent again in the machine (which may happen immediately if the machine is running the OCI live image).

machine-reboot-on-hdd <serial-num>

    SSH into the machine, and make it (cleanly) reboot on the HDD.

machine-reboot-on-live <serial-num>

    SSH into the machine, and make it (cleanly) reboot on the Debian live hardware discovery system.

machine-ipmi-reboot-on-hdd <serial-num>

    Issue an IPMI reboot command, and make the computer reboot on its installed operating system.

machine-ipmi-reboot-on-live <serial-num>

    Issue an IPMI reboot command, and make the computer reboot on the Debian live hardware discovery system.

machine-hpe-ilo-license-install <serial-num>

    If there's a /root/License.xml, this installs it as the HPE ILO license. This file should be installed in the live image here: /etc/openstack-cluster-installer/live-image-additions/root/License.xml

machine-activate-ipmi-over-lan <serial-num>

    This activates IPMI over LAN. Depending on what server type, OCI may use different techniques. For Dell, it's going to use racadm (on the server, doing an ssh connection to it). For HPE, it will use ilorest.

machine-ipmi-cmd <serial-num> <ipmi-command>

    Runs any IPMI command over LAN using the recorded IPMI credentials.

machine-ipmi-assign-ip <serial-num> <ipmi-network>

    Assign an IPMI IP address to a machine. If the machine already has an IPMI IP assigned, it will be removed from the database, and a new one will be assigned from the specified network. Note that the IPMI configuration will not be applied automatically. Call machine-apply-ipmi to do so.

machine-install-os <serial-num>

    Install Debian on the target computer, reboot the machine, and apply to it its puppet configuration.

machine-install-log <serial-num>

    Show the installation log of the computer, if the system is installing. If it has rebooted under its operating system, show its puppet debug log.

machine-apply-ipmi <serial-num>

    Apply the IPMI configuration to a machine (ie: run the ipmitool commands).

machine-set-ipmi [--do-ipmitool-cmds] [--ipmi-defgw GATEWAY] [--ipmi-netmask NETMASK] [--ipmi-call-chassis-bootdev yes/no] <serial-num> <use-ipmi:yes/no> <ipmi-ip-addr> <ipmi-port> <ipmi-username> <ipmi-password>

    Set the IPMI configuration of a computer. If --do-ipmitool-cmds is used, then ipmitool commands will be issued in the target machine, effectively setting-up the IPMI configuration. If --ipmi-call-chassis-bootdev is used, then IPMI will be used to select the boot device before rebooting the computers.

machine-console <serial-num>

    Display the ipmitool command that must be used to access the serial over LAN of a computer, as per the information stored with the machine-set-ipmi.

machine-wipe <serial-num>

    Whipe the begining of all HDDs of the machine with /dev/urandom values.

machine-ip-list <serial-num>

    Display a list of network names and IP address of a computer.

machine-ip-add <serial-num> <network-name> <ip-address>

    Manually add an IP address to a computer. The IP must be in a range included in the network-name.

machine-ip-remove <serial-num> <ip-address>

    Remove an IP address from a computer.

machine-report-counter-reset <serial-num>

    Reset the hardware discovery report counter. This may be useful to restart the automated installation process.

machine-renew-ipmi-password <serial-num>

    Change the IPMI password of a server, and record it in the OCI db.

machine-replace-hardware <old-serial-num> <new-serial-num>

    Replace a deffective machine by a new one. This assume that all hard drives have been moved from the old machine to the new one, and that the old hardware is being destroyed.

compute-decomission <serial-num>

    Shutdown all services of a compute node, and remove its reference from all projects: Nova, Cinder, Neutron and Placement.

password-list [--lter FILTER_STATEMENT]

    List passwords in the OCI db. FILTER_STATEMENT can use one of these fields: id cluster service passtype az. Multiple fields can be used in one request. For example: ocicli password-list --filter cluster=1,passtype=ssh.

password-show <id>

    Show a password.

password-set <id> <pass1> [pass2]

    Set a password to a value. Depending on the password type, the 2nd param may be useful. For example, for an ssh key, pass2 can contain the path to a private key file. If absent, the private key file will be set to an empty string.

ipmi-assign-check

    This command will check if the currently assigned IPMI address of every machine match one of the IPMI networks, and if so, check if the IPMI IP address is recorded in OCI's DB. If the IP address isn't there, a new record will be added. This command is particularly useful if migrating from an old version of OCI, or if the administrator wishes to manually assign IPMI addresses to machines. It's also useful simply when turning on the automatic IPMI address numbering feature in /etc/openstack-cluster-installer/openstack-cluster-installer.conf.

check-all-ipmi [filter]

    This command will iterate through all machines in the OCI database, and check if the IPMI replies to a "chassis power status" command (within a 5 seconds timeout). It is possible to add a filter, matching what's in the output of ocicli machine-list -a. For example, it's possible to do "ocicli check-all-ipmi serial LIKE 'D%'" to check that IPMI is replying on all machines with the serial starting by D.

network-list

    List all networks.

network-set <network-name> [--cidr MASK] [--iface1 IFDEFINITION] [--iface2 IFDEFINITION] [--lldp-match SQL_MATCH_STRING] [--ip IPv4] [--is-public yes/no] [--location location-name] [--mtu MTU] [--role ROLE] [--vip-usage VIP_USAGE] [--vlan VLAN_NUM] [--bridge-name NAME] [--ipmi-match-addr IPADDR] [--ipmi-match-cidr CIDR] [--ipmi-mode <ocimanaged/externaldhcp]

    Set attributes of a network. If --iface1 and --iface2 are used, bonding will be used on every machine using this network. The --role parameter can be use to set the role of the network. These roles are currently available in OCI: ovs-bridge, ceph-cluster, vm-net and ipmi. If not using one of these network roles, then OCI will understand that we're talking about a machine role, and that this network should be assigned only to the machines assigned with this role. The --vip-usage parameter can be use to set the role of a VIP network. This will be used to select the correct network when choosing a VIP. Valid values are: controller, messaging, sql or sqlmsg. The --lldp-match parameter makes it possible to filter ethernet cards depending on the switch hostname they are plugged in, as reported by lldp. For example, if writing 'd1-mgmt%', OCI will match cards that are plugged into switches with hostname starting with d1-mgmt. The [--mtu MTU] and [--vlan VLAN_NUM] are used to set the MTU and VLAN number of a network, during the installation of a server. This value doesn't influence servers already installed, which should then be tweaked manually. The [--bridge-name NAME] parameter controles the name of the birdge, in case the network role is set to ovs-bridge. The [--is-public yes/no] is to be use on the network used to host the OpenStack API. The [--ipmi-match-addr IPADDR] and [--ipmi-match-cidr CIDR] parameters are only for when the network role is set to "ipmi". If in /etc/openstack-cluster-installer/openstack-cluster-installer.conf the parameter automatic_ipmi_numbering=yes is set, then OCI will attempt to match the DHCP IP address with the network described with these 2 parameters. As the default is 0.0.0.0/0, it will match by default. If there are more than one DHCP networks, it is possible to assign different IPMI address ranges depending on which DHCP network is matched with this rule. For example, if you have a 2 DHCP networks, one set to PXE boot servers on 10.0.10.0/24, and that for the machines on this DHCP network, the IPMI addresses should be on the pool 192.168.10.0/24, then this can be done: ocicli network-create ipmi 192.168.10.0 24 zone1 no ocicli network-set ipmi --role ipmi --ipmi-match-addr 10.0.10.0 --ipmi-match-cidr 24 [--ipmi-mode <ocimanaged/externaldhcp] If set to ocimanaged, OCI will manage a pool of IP address in its own database, and assign a free IP address to any new server (until the server is destroyed with ocicli machine-destroy). If set to externaldhcp, the server IPMI will get an IPMI address from DHCP. When the server DHCP boot is matched (see --ipmi-match-addr and --ipmi-match-cidr options above), OCI fetches the current IPMI username for user 2, sets a password, and records username, password and IP address of IPMI in its database. In this mode, it is recommended that the DHCP address of servers for IPMI never changes. One way to do this is either through a MAC address reservation, or a per-port nerver changing IP address (ie: the IP address of the IPMI port is set forever in the DHCP server).

network-create <network-name> <ip> <cidr-mask> <location-name> <is-public:yes/no>

    Create a new network in the database. Note that after the network is created, it must be added to a cluster to be effective. Note that location-name must exist before creating the network.

network-delete <network-name>

    Delete a network from the db.

network-add <network-name> <cluster-name> <role-name> <iface1> <iface2>

    Add a network to a cluster.

network-remove <network-name>

    Remove a network from a cluster.

location-list

    List all location of the database.

location-create <location-name> <swiftregion-name>

    Create a new location in the OCI database. Note that swiftregion-name before creating the location. You still need to create a swiftregion-name even if your cluster doesn't use swift (then the swiftregion-name will not be used).

location-delete <location-name>

    Delete a location from the database. Note that no check is being done if the record is used anywhere.

swift-region-list

    List all swiftregion from the database.

swift-region-create <swiftregion-name>

    Create a new Swift region.

swift-region-delete <swiftregion-name>

    Delete a Swift region. Note that no check is being done if the region is being used or not (use it at your own risk).

swift-calculate-ring <cluster-name> [initial-account-weight [--ec-only] [initial-container-weight] [initial-object-weight]]]

    Calculate the Swift ring for a new cluster. Beware that you should never call this when a cluster has already been deployed (instead, modify the existing ring, and distribute it to all nodes). Eventually, one can set the initial-weight (without it, the default weight is 1000 for each drive). If you wish to only create the Erasure Coding ring, add the --ec-only parameter.

swift-publish-ring <cluster-name>

    Publish a swift ring to all swiftstore and swiftproxy nodes of a cluster. Note that this command must be issued on the OCI machine itself, as the command isn't using any API: it just copies the local files to the cluster.

cluster-list

    List all clusters in the database.

cluster-create <cluster-name> <example.com>

    Create a new cluster with name cluster-name and with domain name example.com

cluster-delete <cluster-name>

    Delete a cluster form the database. Beware that no check is being done if the cluster is still in use. Use at your own risks.

cluster-show <cluster-name>

    Display the information about a cluster and show its variables.

cluster-set <cluster-name> [--time-server-host <time-server-hostname>] [--vip-hostname <hostname>] [--swift-part-power <int>] [--swift-proxy-hostname <hostname>] [--swift-encryption-key-id <UUID>] [--swift-disable-encryption <yes/no>] [--amp-secgroup-list <SECGROUP-UUID-LIST>] [--amp-boot-network-list <AMP_BOOT_NETWORK_LIST>] [--disable-notifications <yes/no>] [--enable-monitoring-graphs <yes/no>] [--monitoring-graphite-host <hostname>] [--monitoring-graphite-port <port>] [--statsd-hostname <hostname>] [--extswift-use-external <yes/no>] [--extswift-auth-url <https://api.example.com/identity/v3>] [--extswift-proxy-url <https://prx.example.com/object/v1/AUTH_>] [--extswift-project-name <myproj>] [--extswift-project-domain-name <default>] [--extswift-user-name <myuser>] [--extswift-use-domain-name <default>] [--extswift-password <password>] [--self-signed-api-cert <yes/no>] [--use-ovs-ifaces <yes/no>] [--cpu-mode <host-model/host-passthrough/custom>] [--cpu-model <MODEL>] [--cpu-model-extra-flags <FLAG1,FLAG2>] [--nested-virt <yes/no>] [--first-master <SERIAL>] [--nameserver-v4-primary <IPv4>] [--nameserver-v4-secondary <IPv4>] [--nameserver-v6-primary <IPv6>] [--nameserver-v6-secondary <IPv6>] [--cephosd-automatic-provisionning <yes/no>] [--haproxy-custom-url <url>]

    Set variables for a cluster.

--time-server-host <time-server-hostname>
    Set the time server to be setup in the chrony client of each node. Defaults to 0.debian.pool.ntp.org if not set.

[--vip-hostname <hostname>]
    Defines the hostname of the OpenStack API if it is needed to override it. Default to <cluster-name>-api.example.com.

[--swift-part-power <int>]
    This parameter controls the total number of partitions in the swift ring when building the initial swift ring. The integer is a power of 2. For example, if setting 18 (which is the default), there will be 2^18 partitions in the ring (which is a good enough value for about 7000 disks, and it's also small enough for smaller clusters).

[--swift-proxy-hostname <hostname>]
    If not set, the URL of the swift proxies will be the one of the OpenStack API, and haproxy there will forward to the swift proxies. If you have a busy swift cluster, then it is recommended to setup more than one swift proxy, using a round-robin DNS entry to point to them. In such case, you can then set the swift proxies hostname, and then clients will connect to them directly instead of going through the HAproxy in the controllers. With an empty string (which is the default), clients will connect through the controller nodes.

[--swift-encryption-key-id <UUID>]
    Set the barbican secret for the swift on-disk encryption. This key must be stored in Barbican before setting this value. [--swift-disable-encryption <yes/no>] If set to yes, there will be no on-disk encryption in the Swift cluster. This is the default. Set the encryption key before setting-up this to no.

[--amp-secgroup-list <SECGROUP-UUID-LIST>]
    List of security groups to be assigned to Octavia amphora. These security groups must be created before setting this value. See the oci-octavia-amphora-secgroups-sshkey-lbrole-and-network utility to create this.

[--amp-boot-network-list <AMP_BOOT_NETWORK_LIST>]
    List of networks to use when booting-up the Octavia Amphora image. See oci-octavia-amphora-secgroups-sshkey-lbrole-and-network utility to create this.

[--disable-notifications <yes/no>]
    If set to yes, there will be no notification transport set in all of the OpenStack services. This is useful if you don't need the metrics to be reported back to the Telemetry project (ie: Ceilometer / Gnocchi).

[--enable-monitoring-graphs <yes/no>]
    Enable Swift reporting of statistics.

[--monitoring-graphite-host <hostname>]
    Hostname of the graphite server to use in Swift nodes to report statistics.

[--monitoring-graphite-port <port>]
    Port number of the graphite server to use in the Swift nodes to report statistics.

[--statsd-hostname <hostname>]
    Hostname of the statsd server to use in the Swift nodes to report statistics. As this improves performances, a collectd server is installed on each nodes, which then reports to graphite. Therefore localhost is a correct value here.

[--extswift-use-external <yes/no>]
    Set to yes to use an external swift for cinder-backup and glance. Use this if you have setup a swift cluster outside of this cluster.

[--extswift-auth-url <https://api.example.com/identity/v3>]
    Auth URL for the external swift.

[--extswift-proxy-url <https://prx.example.com/object/v1/AUTH_>]
    URL of the external swift proxy.

[--extswift-project-name <myproj>]
    Project name of the external swift cluster.

[--extswift-project-domain-name <default>]
    Project domain name of the external swift cluster.

[--extswift-user-name <myuser>]
    User name of the external swift cluster.

[--extswift-user-domain-name <default>]
    User domain name of the external swift cluster.

[--extswift-password <password>]
    Password of the external swift cluster.

[--self-signed-api-cert <yes/no>]
    If set to yes (the default), the API URL will use a self-signed certificate. Therefore, in all of the OpenStack configuration, there will be added some configuration to use the ROOT CA generated by OCI when contacting the API. This ROOT CA will also be used as environment variable by the puppet agent.

[--use-ovs-ifaces <yes/no>]
    If set to no (the default), the network interfaces of compute and network nodes (and the controllers if they act as network nodes, which is the case when no network nodes are provisioned) will use standard kernel network interfaces. If set to yes, then a OVS bridge (and eventually an OVS bond) will be setup instead.

[--cpu-mode <host-model/host-passthrough/custom>]
    This parameter controls the CPU emulation type used in the compute nodes of the cluster. This can be overriden on each compute node.

[--cpu-model <MODEL>]
    This parameter controls the CPU model to use if using host-model.

[--cpu-model-extra-flags <FLAG1,FLAG2>]
    If using host-model, it's possible to add extra CPU features to Qemu. See the Qemu documentation or lscpu for a list of available CPU features.

[--nested-virt <yes/no>]
    If set to yes, nested virtualization will be configured in each compute nodes. Note that with nested virtualization in use, it is impossible to live migrate a VM.

[--first-master <SERIAL>]
    Set which of the 3 (or more) controllers is to be considered "first master". While the system is fully HA, OCI still needs to have a single server that it considers as "first master". The "first master" of the cluster is the machine where Keystone fernet tokens will be rotated (and then synched to other controllers), and where the Glance API will be in used (if neither Swift or Ceph backend is available, other nodes are only Glance API backups if that one fails). This is also the machine where the initial database creation happens.

[--nameserver-v4-primary <IPv4>]
    Configure the primary name server (IPv4) for the cluster. This is currently not in use yet and has no effect.

[--nameserver-v4-secondary <IPv4>]
    Configure the secondary name server (IPv4) for the cluster. This is currently not in use yet and has no effect.

[--nameserver-v6-primary <IPv6>]
    Configure the primary name server (IPv6) for the cluster. This is currently not in use yet and has no effect.

[--nameserver-v6-secondary <IPv6>]
    Configure the secondary name server (IPv6) for the cluster. This is currently not in use yet and has no effect.

[--cephosd-automatic-provisionning <yes/no>]
    Should Ceph OSD be automatically setup after the provisionning of the nodes?

[--haproxy-custom-url <URL>]
    Set redirection URL when calling the root URL of haproxy for the OpenStack API.

cluster-show-networks <cluster-name>

    Show all networks attached to a cluster

cluster-show-machines <cluster-name>

    Show all machines attached to a cluster (ie: do not display machines attached to another cluster, or machines not yet attached anywhere).

cluster-show-ips <cluster-name>

    Display a list of IP addresses assigned in a cluster and the matching hostname where they are assigned.

cluster-install <cluster-name>

    Install the system on all computers of a cluster. The installation is made in this order: first cephmons, then cephosds, then controllers, then network nodes, then everything else. ocicli will wait until the controllers puppet run is done until it installs everyting else. Note that if for a reason, one of the steps didn't work, it's ok to restart a cluster-install command to finish the job, as server install will not be attempted if a machine isn't running live.

cluster-rolecounts-list <cluster-name>

    Display the current role counts for a given cluster.

cluster-rolecounts-set <cluster-name> <count>

    Set the role count for a given cluster and a given role.

cluster-reset <cluster-name>

    Reset all machines that aren't running Debian live into live mode using IPMI commands.

role-list

    List all roles currently defined in OCI.

role-create <name>

    Create a new role.

role-delete <name>

    Delete a role.

filebeat-output-host-list <cluster-name>

    List all filebeat output hosts for a given cluster.

filebeat-output-host-create <cluster-name> <hostname> <port>

    Add a new filebeat output host to a cluster.

filebeat-output-host-delete <cluster-name> <hostname> <port>

    Delete a new filebeat output host from a cluster.

AUTHORS
ocicli has been written by Thomas Goirand <zigo@debian.org>.