ocicli(1)

📦
version 43.0.10 · 2 versions
, in debian trixie

💖 NAME 💖

ocicli — that's the star of this page, straight out of the General Commands Manual section 1 — and what it does is configure your baremetal cluster through the OCI API. that's it. that's the whole job. she does one thing and she does it well 💅

✨ SYNOPSIS ✨

ocicli <command> [options]

🌸 DESCRIPTION 🌸

The ocicli shell script configures the cluster OCI drives. periodt. 💖

🦋 OUTPUT FORMAT 🦋

  • -csv — you can call ocicli with -csv as the first argument and it'll show you everything in csv output instead. csv girlies rise 🫶

👑 COMMANDS 👑

🌈 machine-list

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

Lists all the computers recorded in the OCI database. she understands a whole handful of flags, listed below 👇 and heads up, for each one there's a shorter version — first letter of the argument, single minus sign. iconic behaviour fr fr ✨

  • --all, -a — display all the fields, like every display option got passed at once. ngl this usually does NOT fit on a normal screen 😭 but it's lowkey super useful when you're parsing the output in CSV mode. slay.
  • --versions, -v — display the BIOS, Dell Lifecycle and IPMI firmware versions. firmware check bestie 💜
  • --status, -s — display the operating system installation and puppet run statuses. it also shows you the time of the last run of openstack-cluster-installer-agent. ⚠️ note that the agent only runs when the machine is running in Debian live, before being installed — so don't be shocked when it's empty on an installed box.
  • --zones, -z — display the cluster name, swift region and the location where the machine has been installed. 🌍
  • --network, -n — display the networking information, like IP addresses and that whole vibe. 🌐
  • --ethernet, -e — display the network interfaces with MAC addresses and speed, plus the switch name and interface connected to it. the full tea ☕
  • --hardware, -h — display the hardware configuration of the machine, including how much memory is available 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 one is here because the -e option can be very wide and just does not display well on smaller screens 😭 so if -e is giving chaos, use -l.
  • --filter <field=value>, -f <field=value> — filter the output by field and value. for example, if you wanna display only the servers in a datacenter called d4 and row b, here's exactly how you do it bestie:
ocicli machine-list -r -f loc_dc=4,loc_row=b

🌟 machine-show

machine-show <serial-num|hostname>

Show the details about a computer in the cluster. the ✨deep dive✨ on one machine.

💅 machine-ipmi-adopt

machine-ipmi-adopt <serial-num>

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

🎀 machine-guessed-profile

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 — yes, the scientific method, we love her 🔥

The -d or --debug option helps you design hardware-profiles.json, by showing how profiles are filtered. iykyk 👀

⭐ machine-check-megacli-applied

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. detective mode 🔍

🧚 machine-megacli-apply

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. let her cook 🍳

💜 machine-megacli-reset-raid

machine-megacli-reset-raid <machine_serial>

Reset the RAID configuration of a machine, removing all RAID devices. ⚠️ gone means gone bestie, no cap.

🌸 machine-guess-racking

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-auto-rack <machine_serial>

Fill up the racking information exactly as machine-guess-racking would guess it. guess → done, zero typing ✨

🦋 machine-auto-add

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). yeah she needs both files, don't @ me 🫶

🌈 machine-to-dns

machine-to-dns <machine_serial>

Record the machine hostname into an external DNS service. ⚠️ this only works 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-out-of-dns <machine_serial>

Delete the machine from DNS using the plugin script. bye bye 💨

💖 machine-to-monitoring

machine-to-monitoring <machine_serial>

Insert the machine into the monitoring system. ⚠️ this only works 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-out-of-monitoring <machine_serial>

Delete the machine from monitoring using the plugin script. she's off the grid now 📉

🔥 machine-gen-root-pass

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. and ngl, it is adviced to use something like Hashicorp Vault or OpenStack Barbican for storing these root passwords — please please please don't just leave root passwords lying around 😭

🧚 machine-forget-root-pass

machine-forget-root-pass <machine_serial>

Remove the root password from the password store, using the plugin script. memory wipe 💫

👑 machine-set

machine-set <serial-num> [options]

Set properties of a computer in the cluster. Options are as below. this is the glow-up command, she changes everything 💅

  • --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 you're using IPMI and serial over LAN 🔌 it influences both the way grub is configured and the 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. set it early or cry later 😭
  • --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 you're 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.

More flags, bestie — we're still deep in the options 💅 buckle up.

  • --lvm-backend-name — Sets the name of the LVM backend. Only applies to Cinder volume nodes. Super handy when you've got two different backends and you need to tell them apart — like one being SSD and the other being HDD. iykyk
  • --ipmi-use <yes/no> — If you set this, the computer uses IPMI. That's it, that's the flag. 🫶
  • --ipmi-call-chassis-bootdev <yes/no> — Set this and the 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. Don't forget it, bestie, or nothing happens!!

  • --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. again, please run it, I'm begging 🥺

  • --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 is acting as a Ceph OSD, its OSDs get set up once on the first puppet runs, and then automatically that's disabled. This parameter makes it possible to force the setup to run again — for example if you added a new block device to the host. It is recommended to leave this not activated in production, so broken block devices get handled gracefully. lowkey important.
  • --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 🌟

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

Adds a machine to a cluster. The networks attached to the location you specify get automatically assigned to that computer (ie: IP addresses will be reserved for that machine). If it's a network node (or a controller that acts as a network node when no network nodes are defined on the cluster) or a compute node — if it exists — then the vm-net also gets added to the machine. And if it's a cephosd node and a ceph network exists, that gets added to the machine too. 🎀

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. no stealing IPs bestie.

machine-remove 🌟

machine-remove <serial-num>

Removes a machine from a network, and makes it available so it can be added again in a cluster. bye for now, not forever 🫶

machine-destroy 🌟

machine-destroy <serial-num>

Completely removes 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 🌟

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

SSHes into the machine, and makes it (cleanly) reboot on the HDD. 🖥️

machine-reboot-on-live 🌟

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

SSHes into the machine, and makes it (cleanly) reboot on the Debian live hardware discovery system. ✨

machine-ipmi-reboot-on-hdd 🌟

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

Issues an IPMI reboot command, and makes the computer reboot on its installed operating system. 👑

machine-ipmi-reboot-on-live 🌟

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

Issues an IPMI reboot command, and makes the computer reboot on the Debian live hardware discovery system. 🦋

machine-hpe-ilo-license-install 🌟

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

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

machine-activate-ipmi-over-lan 🌟

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

This activates IPMI over LAN. Depending on what server type it is, 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. different strokes for different vendors fr fr

machine-ipmi-cmd 🌟

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

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

machine-ipmi-assign-ip 🌟

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

Assigns 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 that. 🙈

machine-install-os 🌟

machine-install-os <serial-num>

Installs Debian on the target computer, reboots the machine, and applies its puppet configuration to it. 🔥

machine-install-log 🌟

machine-install-log <serial-num>

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

machine-apply-ipmi 🌟

machine-apply-ipmi <serial-num>

Applies the IPMI configuration to a machine (ie: runs the ipmitool commands). the moment we've all been waiting for 💖

machine-set-ipmi 🌟

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>

Sets 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 🌟

machine-console <serial-num>

Displays 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 🌟

machine-wipe <serial-num>

Wipes the beginning of all HDDs of the machine with /dev/urandom values. this one is literally irreversible bestie, be so careful 💀

machine-ip-list 🌟

machine-ip-list <serial-num>

Displays a list of network names and IP address of a computer. 🎀

machine-ip-add 🌟

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

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

machine-ip-remove 🌟

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

Removes an IP address from a computer. 🦋

machine-report-counter-reset 🌟

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

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

machine-renew-ipmi-password 🌟

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

Changes the IPMI password of a server, and records it in the OCI db. 🔐

machine-replace-hardware 🌟

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

Replaces a defective machine with a new one. This assumes that all hard drives have been moved from the old machine to the new one, and that the old hardware is being destroyed. 👑

password-list 🌟

password-list [--lter FILTER_STATEMENT]

Lists 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 🌟

password-show <id>

Shows a password. 👀

password-set 🌟

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

Sets 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 🌟

ipmi-assign-check

This command will check if the currently assigned IPMI address of every machine matches 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 you're 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 🌟

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 🌟

network-list

Lists all networks. 🕸️

network-set 🌟

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]

Sets 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 used to set the role of the network. These roles are currently available in OCI: ovs-bridge, ceph-cluster, vm-net and ipmi. If you're 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. 💅

  • --vip-usage — sets the role of a VIP network, bestie. This is what OCI uses to pick the right network when it's choosing a VIP. Valid values are: controller, messaging, sql or sqlmsg. 💅
  • --lldp-match — lets you filter ethernet cards based on the switch hostname they're plugged into, as reported by lldp. So like, if you write d1-mgmt%, OCI will match cards plugged into switches whose hostname starts with d1-mgmt. Cute, right? 🦋
  • [--mtu MTU] and [--vlan VLAN_NUM] — these set the MTU and the VLAN number of a network, and they only apply during the installation of a server. So no cap, this value does not touch servers that are already installed — those you gotta tweak by hand. 😭
  • [--bridge-name NAME] — controls the name of the bridge, but only when the network role is set to ovs-bridge. 🌉
  • [--is-public yes/no] — use this one on the network that hosts the OpenStack API. ✨
  • [--ipmi-match-addr IPADDR] and [--ipmi-match-cidr CIDR] — these are only for when the network role is set to "ipmi". Here's the tea: if in /etc/openstack-cluster-installer/openstack-cluster-installer.conf the parameter automatic_ipmi_numbering=yes is set, then OCI will try to match the DHCP IP address with the network described by these two parameters. The default is 0.0.0.0/0, so it'll match by default. And if you have more than one DHCP network, you can assign different IPMI address ranges depending on which DHCP network gets matched by this rule. For example — say you have 2 DHCP networks, one set to PXE boot servers on 10.0.10.0/24, and for the machines on that DHCP network the IPMI addresses should live in the pool 192.168.10.0/24, then you do it like this:
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 you set it to ocimanaged, OCI manages a pool of IP addresses in its own database and hands a free IP address to any new server (until that server gets destroyed with ocicli machine-destroy). 🪦

If you set it to externaldhcp, the server IPMI gets its IPMI address from DHCP instead. When the server DHCP boot gets matched (see the --ipmi-match-addr and --ipmi-match-cidr options up there ⬆️), OCI fetches the current IPMI username for user 2, sets a password, and records username, password and IP address of the IPMI in its database. In this mode it's recommended that the DHCP address of servers for IPMI never changes. One way to do that is either through a MAC address reservation, or a per-port never-changing IP address (i.e.: 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>

Makes a brand new network in the database. Heads up though: after the network is created, it must be added to a cluster to actually be effective. And also, location-name has to exist before you create the network. Order matters, bestie. 💖

network-delete <network-name>

Deletes a network from the db. gone. poof. 🫥

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

Adds a network to a cluster. slay 🔥

network-remove <network-name>

Removes a network from a cluster.

location-list

Lists all locations of the database. 📍

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

Creates a new location in the OCI database. Note that swiftregion-name has to exist before creating the location. And yes, you still need to create a swiftregion-name even if your cluster doesn't use swift — in that case the swiftregion-name just won't be used. 🙈

location-delete <location-name>

Deletes a location from the database. Note that no check is being done if the record is used anywhere. yolo, basically. 💀

swift-region-list

Lists all swiftregion from the database.

swift-region-create <swiftregion-name>

Creates a new Swift region. 🌈

swift-region-delete <swiftregion-name>

Deletes 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]]]

Calculates the Swift ring for a new cluster. Beware: you should never call this when a cluster has already been deployed. Instead, modify the existing ring, and distribute it to all nodes. do not do the thing. 😤

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>

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

cluster-list

Lists all clusters in the database.

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

Creates a new cluster with name cluster-name and with domain name example.com. 👑

cluster-delete <cluster-name>

Deletes a cluster from 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>

Displays the information about a cluster and shows 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>]

Sets variables for a cluster. this is the big one, bestie, buckle up 💖

  • --time-server-host <time-server-hostname> — sets the time server that gets set up in the chrony client of each node. Defaults to 0.debian.pool.ntp.org if it's not set. ⏰
  • [--vip-hostname <hostname>] — defines the hostname of the OpenStack API, in case you need to override it. Defaults to <cluster-name>-api.example.com.
  • [--swift-part-power <int>] — this one controls the total number of partitions in the swift ring when building the initial swift ring. The integer is a power of 2. So for example, if you set 18 (which is the default), there'll 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. cute and versatile. 🎀
  • [--swift-proxy-hostname <hostname>] — if this isn't 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've got a busy swift cluster, then it's recommended to set up more than one swift proxy, using a round-robin DNS entry to point to them. In that case you can 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>] — sets 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 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 the 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 (i.e.: Ceilometer / Gnocchi). 🤫
  • [--enable-monitoring-graphs <yes/no>] — enables 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. Since this improves performances, a collectd server is installed on each node, which then reports to graphite. So 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've set up 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.

and the option list keeps going, bestie 💅 no cap, here's the rest:

  • [--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. keep it secret, keep it safe 🔐
  • [--self-signed-api-cert <yes/no>] — if you set this to yes (which is the default, bestie), the API URL will use a self-signed certificate. Therefore, in all of the OpenStack configuration, some configuration gets added to use the ROOT CA generated by OCI when contacting the API. That ROOT CA will also be used as an 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 an OVS bridge (and eventually an OVS bond) will be set up instead. vibe check 💅
  • [--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 overridden 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 node. > note: 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 "first master". The "first master" of the cluster is the machine where Keystone fernet tokens will be rotated (and then synced to other controllers), and where the Glance API will be in use (if neither Swift nor 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. > currently not in use yet and has no effect. 🙈
  • [--nameserver-v4-secondary <IPv4>] — configure the secondary name server (IPv4) for the cluster. > currently not in use yet and has no effect. 🙈
  • [--nameserver-v6-primary <IPv6>] — configure the primary name server (IPv6) for the cluster. > currently not in use yet and has no effect. 🙈
  • [--nameserver-v6-secondary <IPv6>] — configure the secondary name server (IPv6) for the cluster. > currently not in use yet and has no effect. 🙈
  • [--cephosd-automatic-provisionning <yes/no>] — should Ceph OSD be automatically set up after the provisioning 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 everything else. 😭

note: 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. yes, bestie, that's what it says. 💅

✨ AUTHORS ✨

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

and that's the ocicli(1) manual, bestie — the footer says ocicli(1), which is the source/version/date flex. periodt. 💖✨

📦 where this page comes from