updated readme
diff --git a/README.md b/README.md index dd04b16..604c83f 100644 --- a/README.md +++ b/README.md
@@ -11,7 +11,7 @@ [Apigee Setup Ansible](https://github.com/carlosfrias/apigee-opdk-playbook-setup-ansible) project for details. * Install Apigee OPDK ansible roles. * Update ~/.apigee/credentials.yml. -* Update your inventory file. +* Update your inventory file [Updating your Inventory File](https://github.com/carlosfrias/apigee-opdk-playbook-setup-ansible/inventory.md). * Update your ansible configuration file with your inventory file or folder name, the remote-user and ssh private_key_file. Functionality Available @@ -96,78 +96,4 @@ You can dispose of the VM to recover disk space with: vagrant destroy -f - -Updating your inventory file -============================ - -We use a standard Ansible inventory file with some semantic conventions applied to it. 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 + \ No newline at end of file
diff --git a/inventory.md b/inventory.md new file mode 100644 index 0000000..2ffce66 --- /dev/null +++ b/inventory.md
@@ -0,0 +1,86 @@ +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