[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]
Inspecting and manipulating the inventory¶
Warning
Never edit or delete the files
/etc/openstack_deploy/openstack_inventory.json
or
/etc/openstack_deploy/openstack_hostnames_ips.yml
. This can
lead to file corruptions, and problems with the inventory: hosts
and container could disappear and new ones would appear,
breaking your existing deployment.
The file scripts/inventory-manage.py
is used to produce human readable
output based on the /etc/openstack_deploy/openstack_inventory.json
file.
The same script can be used to safely remove hosts from the inventory, export the inventory based on hosts, and clear IP addresses from containers within the inventory files.
Operations taken by this script only affect the
/etc/opentstack_deploy/openstack_inventory.json
file; any new or removed
information must be set by running playbooks.
Viewing the inventory¶
The /etc/openstack_deploy/openstack_inventory.json
file is read by default.
An alternative file can be specified with --file
.
A list of all hosts can be seen with the --list-host/-l
argument
To see a listing of hosts and containers by their group, use
--list-groups/-g
.
To see all of the containers, use --list-containers/-G
.
Removing a host¶
A host can be removed with the --remove-item/-r
parameter.
Use the host’s name as an argument.
Exporting host information¶
Information on a per-host basis can be obtained with the --export/-e
parameter.
This JSON output has two top-level keys: hosts
and all
.
hosts
contains a map of a host’s name to its variable and group data.
all
contains global network information such as the load balancer IPs and
provider network metadata.
Clearing existing container IP addresses¶
The --clear-ips
parameter can be used to remove all container IP address
information from the openstack_inventory.json
file. Baremetal hosts will
not be changed.
This will not change the LXC configuration until the associated playbooks are run and the containers restarted, which will result in API downtime.
Any changes to the containers must also be reflected in the deployment’s load balancer.