Consolidate Technical Requirements in Arch Guide

Collects technical requirements information from various
chapters in the Architecture Design Guide and consolidates
them into a single Functional technical requirements chapter.

Change-Id: I9df8be788f941a58e9a9fa92f77905c7d18aaae4
Closes-bug: #1548154
Implements: blueprint archguide-mitaka-reorg

doc/arch-design-draft/source/functional-requirements.rst

@@ -1,9 +0,0 @@
-=======================
-Functional requirements
-=======================
-
-.. toctree::
-   :maxdepth: 2
-
-
-

doc/arch-design-draft/source/index.rst

@@ -25,7 +25,7 @@ Contents
    common/conventions.rst
    introduction.rst
    identifying-stakeholders.rst
-   functional-requirements.rst
+   technical-requirements.rst
    customer-requirements.rst
    operator-requirements.rst
    capacity-planning-scaling.rst

doc/arch-design-draft/source/introduction.rst

@@ -34,8 +34,9 @@ developing cloud architecture design documents. The sections covered are:
    different business requirements and architecture design based on different
    internal and external stakeholders.
 
-*  :doc:`Functional requirements <functional-requirements>`: Information for
-   SMEs on deployment methods and how they will affect deployment cost.
+*  :doc:`Technical requirements <technical-requirements>`:
+   Information for SMEs on deployment methods and how they will affect
+   deployment cost.
 
 *  :doc:`Customer requirements <customer-requirements>`: Information for SMEs
    on business and technical requirements.

doc/arch-design-draft/source/operator-requirements-licensing.rst

@@ -1,33 +0,0 @@
-=========
-Licensing
-=========
-
-The many different forms of license agreements for software are often written
-with the use of dedicated hardware in mind.  This model is relevant for the
-cloud platform itself, including the hypervisor operating system, supporting
-software for items such as database, RPC, backup, and so on.  Consideration
-must be made when offering Compute service instances and applications to end
-users of the cloud, since the license terms for that software may need some
-adjustment to be able to operate economically in the cloud.
-
-Multi-site OpenStack deployments present additional licensing
-considerations over and above regular OpenStack clouds, particularly
-where site licenses are in use to provide cost efficient access to
-software licenses. The licensing for host operating systems, guest
-operating systems, OpenStack distributions (if applicable),
-software-defined infrastructure including network controllers and
-storage systems, and even individual applications need to be evaluated.
-
-Topics to consider include:
-
-* The definition of what constitutes a site in the relevant licenses,
-  as the term does not necessarily denote a geographic or otherwise
-  physically isolated location.
-
-* Differentiations between "hot" (active) and "cold" (inactive) sites,
-  where significant savings may be made in situations where one site is
-  a cold standby for disaster recovery purposes only.
-
-* Certain locations might require local vendors to provide support and
-  services for each site which may vary with the licensing agreement in
-  place.

doc/arch-design-draft/source/operator-requirements.rst

@@ -6,15 +6,10 @@ Operator requirements
    :maxdepth: 2
 
    operator-requirements-sla.rst
-   operator-requirements-logging-monitoring.rst
-   operator-requirements-network-design.rst
-   operator-requirements-licensing.rst
    operator-requirements-support-maintenance.rst
    operator-requirements-ops-access.rst
    operator-requirements-quota-management.rst
    operator-requirements-policy-management.rst
-   operator-requirements-hardware-selection.rst
-   operator-requirements-software-selection.rst
    operator-requirements-external-idp.rst
    operator-requirements-upgrades.rst
    operator-requirements-bleeding-edge.rst

doc/arch-design-draft/source/technical-requirements-software-selection.rst

@@ -224,3 +224,37 @@ solutions has an impact on the design:
 * OpenStack design, generally, does not include shared storage.
   However, for some high availability designs, certain components might
   require it depending on the specific implementation.
+
+
+Licensing
+~~~~~~~~~
+
+The many different forms of license agreements for software are often written
+with the use of dedicated hardware in mind.  This model is relevant for the
+cloud platform itself, including the hypervisor operating system, supporting
+software for items such as database, RPC, backup, and so on.  Consideration
+must be made when offering Compute service instances and applications to end
+users of the cloud, since the license terms for that software may need some
+adjustment to be able to operate economically in the cloud.
+
+Multi-site OpenStack deployments present additional licensing
+considerations over and above regular OpenStack clouds, particularly
+where site licenses are in use to provide cost efficient access to
+software licenses. The licensing for host operating systems, guest
+operating systems, OpenStack distributions (if applicable),
+software-defined infrastructure including network controllers and
+storage systems, and even individual applications need to be evaluated.
+
+Topics to consider include:
+
+* The definition of what constitutes a site in the relevant licenses,
+  as the term does not necessarily denote a geographic or otherwise
+  physically isolated location.
+
+* Differentiations between "hot" (active) and "cold" (inactive) sites,
+  where significant savings may be made in situations where one site is
+  a cold standby for disaster recovery purposes only.
+
+* Certain locations might require local vendors to provide support and
+  services for each site which may vary with the licensing agreement in
+  place.

doc/arch-design-draft/source/technical-requirements.rst

@@ -0,0 +1,61 @@
+======================
+Technical requirements
+======================
+
+.. toctree::
+   :maxdepth: 2
+
+   technical-requirements-software-selection.rst
+   technical-requirements-hardware-selection.rst
+   technical-requirements-network-design.rst
+   technical-requirements-logging-monitoring.rst
+
+Any given cloud deployment is expected to include these base services:
+
+* Compute
+
+* Networking
+
+* Storage
+
+Each of these services have different software and hardware resource
+requirements.
+As a result, you must make design decisions relating directly
+to the service, as well as provide a balanced infrastructure for all services.
+
+There are many ways to split out an OpenStack deployment, but a two box
+deployment typically consists of:
+
+* A controller node
+* A compute node
+
+The controller node will typically host:
+
+* Identity service (for authentication)
+* Image service (for image storage)
+* Block Storage
+* Networking service (the ``nova-network`` service may be used instead)
+* Compute service API, conductor, and scheduling services
+* Supporting services like the message broker (RabbitMQ)
+  and database (MySQL or PostgreSQL)
+
+The compute node will typically host:
+
+* Nova compute
+* A networking agent, if using OpenStack Networking
+
+To provide additional block storage in a small environment, you may also
+choose to deploy ``cinder-volume`` on the compute node.
+You may also choose to run ``nova-compute`` on the controller itself to
+allow you to run virtual machines on both hosts in a small environments.
+
+To expand such an environment you would add additional compute nodes,
+a separate networking node, and eventually a second controller for high
+availability. You might also split out storage to dedicated nodes.
+
+The OpenStack Installation guides provide some guidance on getting a basic
+2-3 node deployment installed and running:
+
+* `OpenStack Installation Guide for Ubuntu <http://docs.openstack.org/mitaka/install-guide-ubuntu/>`_
+* `OpenStack Installation Guide for Red Hat Enterprise Linux and CentOS <http://docs.openstack.org/mikata/install-guide-rdo/>`_
+* `OpenStack Installation Guide for openSUSE and SUSE Linux Enterprise <http://docs.openstack.org/mitaka/install-guide-obs/>`_