Added deployment_install AIO-SX combo manual

First draft of the combined deployment and installation
instructions for the AIO-SX StarlingX configuration.

Change-Id: Ib5bb6753aa1ed384c87e44b3c4d88945f2ed187a
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>

doc/source/deploy_install_guides/index.rst

@@ -0,0 +1,77 @@
+==================================
+Deployment and installation guides
+==================================
+
+Deployment and installation guides for StarlingX are release-specific.
+Each guide provides instruction on a specific StarlingX configuration
+(e.g. All-in-one Simplex).
+
+The following list provides help on choosing the correct deployment guide:
+
+.. toctree::
+   :maxdepth: 1
+
+   latest/aio_simplex/index
+
+- Following are deployment and installation guides for past StartlingX
+  releases that have been archived:
+
+  * Currently, no archived deployment guides exist.
+
+
+.. Steps you must take when a new release of the deployment and installation
+   guides occurs:
+
+.. 1. Archive the "current" release:
+         1. Rename the "current" folder to the release name using the <Year_Month> convention (e.g. 2018_10).
+         2. Get inside your new folder (i.e. the old "current" folder) and update all links in the *.rst
+         files to use the new path (e.g. :doc:`Libvirt/QEMU </installation_guide/current/installation_libvirt_qemu>`
+         becomes
+         :doc:`Libvirt/QEMU </installation_guide/<Year_Month>/installation_libvirt_qemu>`
+         3. You might want to change your working directory to /<Year_Month> and use Git to grep for
+         the "current" string (i.e. 'git grep "current" *').  For each applicable occurence, make
+         the call whether or not to convert the string to the actual archived string "<Year_Month>".
+         Be sure to scrub all files for the "current" string in both the "installation_guide"
+         and "developer_guide" folders downward.
+   2. Add the new "current" release:
+         1. Rename the existing "latest" folders to "current".  This assumes that "latest" represented
+         the under-development release that just officially released.
+         2. Get inside your new folder (i.e. the old "latest" folder) and update all links in the *.rst
+         files to use the new path (e.g. :doc:`Libvirt/QEMU </installation_guide/latest/installation_libvirt_qemu>`
+         becomes
+         :doc:`Libvirt/QEMU </installation_guide/current/installation_libvirt_qemu>`
+         3. You might want to change your working directory to the "current" directory and use Git to grep for
+         the "latest" string (i.e. 'git grep "latest" *').  For each applicable occurence, make
+         the call whether or not to convert the string to "current".
+         Be sure to scrub all files for the "latest" string in both the "installation_guide"
+         and "developer_guide" folders downward.
+         4. Because the "current" release is now available, make sure to update these pages:
+            - index
+            - installation guide
+            - developer guide
+            - release notes
+   3. Create a new "latest" release, which are the installation and developer guides under development:
+         1. Copy your "current" folders and rename them "latest".
+         2. Make sure the new files have the correct version in the page title and intro
+         sentence (e.g. '2019.10.rc1 Installation Guide').
+         3. Make sure all files in new "latest" link to the correct versions of supporting
+         docs.  You do this through the doc link, so that it resolves to the top of the page
+         (e.g. :doc:`/installation_guide/latest/index`)
+         4. Make sure the new release index is labeled with the correct version name
+         (e.g .. _index-2019-05:)
+         5. Add the archived version to the toctree on this page.  You want all possible versions
+         to build.
+         6. Since you are adding a new version ("latest") *before* it is available
+         (e.g. to begin work on new docs), make sure page text still directs user to the
+         "current" release and not to the under development version of the manuals.
+
+
+
+
+
+
+
+
+
+
+

doc/source/deploy_install_guides/latest/deployment_terminology.rst

@@ -0,0 +1,119 @@
+.. _incl-simplex-deployment-terminology:
+
+**All-in-one controller node**
+    A single physical node that provides a controller function, compute
+    function, and storage function.
+
+.. _incl-simplex-deployment-terminology-end:
+
+
+.. _incl-standard-controller-deployment-terminology:
+
+**Controller node / function**
+    A node that runs cloud control function for managing cloud resources.
+
+    - Runs cloud control functions for managing cloud resources.
+    - Runs all OpenStack control functions (e.g. managing images, virtual
+      volumes, virtual network, and virtual machines).
+    - Can be part of a two-node HA control node cluster for running control
+      functions either active/active or active/standby.
+
+**Compute ( & network ) node / function**
+    A node that hosts applications in virtual machines using compute resources
+    such as CPU, memory, and disk.
+
+    - Runs virtual switch for realizing virtual networks.
+    - Provides L3 routing and NET services.
+
+.. _incl-standard-controller-deployment-terminology-end:
+
+
+.. _incl-dedicated-storage-deployment-terminology:
+
+**Storage node / function**
+    A node that contains a set of disks (e.g. SATA, SAS, SSD, and/or NVMe).
+
+    - Runs CEPH distributed storage software.
+    - Part of an HA multi-node CEPH storage cluster supporting a replication
+      factor of two or three, journal caching, and class tiering.
+    - Provides HA persistent storage for images, virtual volumes
+      (i.e. block storage), and object storage.
+
+.. _incl-dedicated-storage-deployment-terminology-end:
+
+.. _incl-common-deployment-terminology:
+
+**OAM network**
+    The network on which all external StarlingX platform APIs are exposed,
+    (i.e. REST APIs, Horizon web server, SSH, and SNMP), typically 1GE.
+
+    Only controller type nodes are required to be connected to the OAM
+    network.
+
+**Management network**
+    A private network (i.e. not connected externally), tipically 10GE,
+    used for the following:
+
+    - Internal OpenStack / StarlingX monitoring and control.
+    - VM I/O access to a storage cluster.
+
+    All nodes are required to be connected to the management network.
+
+**Data network(s)**
+    Networks on which the OpenStack / Neutron provider networks are realized
+    and become the VM tenant networks.
+
+    Only compute type and all-in-one type nodes are required to be connected
+    to the data network(s); these node types require one or more interface(s)
+    on the data network(s).
+
+**IPMI network**
+    An optional network on which IPMI interfaces of all nodes are connected.
+    The network must be reachable using L3/IP from the controller's OAM
+    interfaces.
+
+    You can optionally connect all node types to the IPMI network.
+
+**PXEBoot network**
+    An optional network for controllers to boot/install other nodes over the
+    network.
+
+    By default, controllers use the management network for boot/install of other
+    nodes in the openstack cloud. If this optional network is used, all node
+    types are required to be connected to the PXEBoot network.
+
+    A PXEBoot network is required for a variety of special case situations:
+
+    - Cases where the management network must be IPv6:
+
+      - IPv6 does not support PXEBoot. Therefore, IPv4 PXEBoot network must be
+        configured.
+
+    - Cases where the management network must be VLAN tagged:
+
+      - Most server's BIOS do not support PXEBooting over tagged networks.
+        Therefore, you must configure an untagged PXEBoot network.
+
+    - Cases where a management network must be shared across regions but
+      individual regions' controllers want to only network boot/install nodes
+      of their own region:
+
+      - You must configure separate, per-region PXEBoot networks.
+
+**Infra network**
+    A deprecated optional network that was historically used for access to the
+    storage cluster.
+
+    If this optional network is used, all node types are required to be
+    connected to the INFRA network,
+
+**Node interfaces**
+    All nodes' network interfaces can, in general, optionally be either:
+
+    - Untagged single port.
+    - Untagged two-port LAG and optionally split between redudant L2 switches
+      running vPC (Virtual Port-Channel), also known as multichassis
+      EtherChannel (MEC).
+    - VLAN on either single-port ETH interface or two-port LAG interface.
+
+.. _incl-common-deployment-terminology-end:

doc/source/index.rst

@@ -23,6 +23,7 @@ Sections
    contributor/index
    releasenotes/index
    developer_resources/index
+   deploy_install_guides/index
 
 --------
 Projects