Updating your inventory file

We use a standard Ansible inventory file with some semantic conventions applied to Ansible groups. The semantic model applied to the Ansible inventory file is described in the following sections.

Ansible Inventory Files

Ansible provides rich semantics for inventory files. We leverage the ansible model by applying a semantic convention that is based on the Apigee Private Cloud domain model for referencing server nodes as collections of planets and regions. This means that the normal Ansible inventory files are used as is with the exception of the semantic conventions for inventory group names.

Inventory File Conventions

These roles depend on use of conventions in the inventory file. Specifically inventory file conventions are ansible groups names that are defined around Apigee semantics. These ansible groups are semantically linked to the documentation. The ansible groups used as conventions correspond to the installation roles and server categorizations called out in the Apigee Private Cloud Installation and Configuration Guide. It has been useful to use planet and region designations combined with the documented installation role names to create categorization semantics that should be fairly intuitive once you read the Apigee Private Cloud Installation and Configuration Guide.

Inventory Planet, Region and Installation Role Conventions

A planet refers to all server nodes across all data centers. These semantics are held via the use of group names for all nodes that fulfill a specific purpose. The installation roles provide the semantic model we followed. The inventory file group names for planet level semantics are listed in the template inventory file below.

A region represents subset of a planet. The semantics used for installation roles are congruent with a region. Region have been referenced as data centers. The internal configurations of OPDK and BaaS support many regions as dc-1, dc-2 and so forth. Following this historical precedent we also define the regions with their corresponding installation role to provide a semantic model as follows:

# Listing that references all data centers that compose a planet. 
[planet]
dc-1

[dc-1]
# Listing of all nodes in data center 1 (dc-1)

[ds:children]
# Listing of all the Cassandra and Zookeeper nodes across the planet
dc-1-ds

[dc-1-ds]
# Listing of all the Cassandra and Zookeeper nodes in dc-1

[dc-1-ms]
# Listing of all the Management Server nodes in dc-1
 
[dc-1-ldap]
# Listing of all OpenLDAP nodes in dc-1

[dc-1-rmp]
# Listing of all Router and Message Processor nodes in dc-1

[dc-1-qpid]
# Listing of all Qpid nodes in dc-1

[dc-1-pg]
# Listing of all Postgres nodes in dc-1

[dc-1-pgmaster]
# Listing of the single Postgres master node in dc-1

[dc-1-pgstandby]
# Listing of the single Postgres standby node in dc-1

[dc-1-ui]
# Listing of the UI node in dc-1

Zookeeper Observer Nodes

Zookeeper nodes can be designated as an observer node. Ansible inventory files allow variables to be assigned to servers. These roles will update the silent installation configuration file correctly for any zookeeper node that is assigned the variable zk_observer.

 zk_observer=true