[arch-design-draft] Migrate specialized use cases

Migrate specialized use case content to the new
structure. Content will be revised at a later date.

Change-Id: I49f5cedc646d86764fef57cb38041a688fab05ef
Implements: blueprint arch-guide-restructure

doc/arch-design-draft/source/arch-guide-draft-mitaka/customer-requirements-business-considerations.rst

@@ -1,147 +0,0 @@
-=======================
-Business considerations
-=======================
-
-Cost
-~~~~
-
-Financial factors are a primary concern for any organization. Cost
-considerations may influence the type of cloud that you build.
-For example, a general purpose cloud is unlikely to be the most
-cost-effective environment for specialized applications.
-Unless business needs dictate that cost is a critical factor,
-cost should not be the sole consideration when choosing or designing a cloud.
-
-As a general guideline, increasing the complexity of a cloud architecture
-increases the cost of building and maintaining it. For example, a hybrid or
-multi-site cloud architecture involving multiple vendors and technical
-architectures may require higher setup and operational costs because of the
-need for more sophisticated orchestration and brokerage tools than in other
-architectures. However, overall operational costs might be lower by virtue of
-using a cloud brokerage tool to deploy the workloads to the most cost effective
-platform.
-
-Consider the following costs categories when designing a cloud:
-
-*  Compute resources
-
-*  Networking resources
-
-*  Replication
-
-*  Storage
-
-*  Management
-
-*  Operational costs
-
-It is also important to consider how costs will increase as your cloud scales.
-Choices that have a negligible impact in small systems may considerably
-increase costs in large systems. In these cases, it is important to minimize
-capital expenditure (CapEx) at all layers of the stack. Operators of massively
-scalable OpenStack clouds require the use of dependable commodity hardware and
-freely available open source software components to reduce deployment costs and
-operational expenses. Initiatives like OpenCompute (more information available
-at http://www.opencompute.org) provide additional information and pointers.
-Factors to consider include power, cooling, and the physical design of the
-chassis. Through customization, it is possible to optimize your hardware and
-systems for specific types of workloads when working at scale.
-
-
-Time-to-market
-~~~~~~~~~~~~~~
-
-The ability to deliver services or products within a flexible time
-frame is a common business factor when building a cloud. Allowing users to
-self-provision and gain access to compute, network, and
-storage resources on-demand may decrease time-to-market for new products
-and applications.
-
-You must balance the time required to build a new cloud platform against the
-time saved by migrating users away from legacy platforms. In some cases,
-existing infrastructure may influence your architecture choices. For example,
-using multiple cloud platforms may be a good option when there is an existing
-investment in several applications, as it could be faster to tie the
-investments together rather than migrating the components and refactoring them
-to a single platform.
-
-
-Revenue opportunity
-~~~~~~~~~~~~~~~~~~~
-
-Revenue opportunities vary based on the intent and use case of the cloud.
-The requirements of a commercial, customer-facing product are often very
-different from an internal, private cloud. You must consider what features
-make your design most attractive to your users.
-
-
-Compliance and geo-location
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-An organization may have certain legal obligations and regulatory
-compliance measures which could require certain workloads or data to not
-be located in certain regions. See :ref:`legal-requirements`.
-
-Compliance considerations are particularly important for multi-site clouds.
-Considerations include:
-
-- federal legal requirements
-- local jurisdictional legal and compliance requirements
-- image consistency and availability
-- storage replication and availability (both block and file/object storage)
-- authentication, authorization, and auditing (AAA)
-
-Geographical considerations may also impact the cost of building or leasing
-data centers. Considerations include:
-
-- floor space
-- floor weight
-- rack height and type
-- environmental considerations
-- power usage and power usage efficiency (PUE)
-- physical security
-
-
-Auditing
-~~~~~~~~
-
-A well-considered auditing plan is essential for quickly finding issues.
-Keeping track of changes made to security groups and tenant changes can be
-useful in rolling back the changes if they affect production. For example,
-if all security group rules for a tenant disappeared, the ability to quickly
-track down the issue would be important for operational and legal reasons.
-
-
-Security
-~~~~~~~~
-
-The importance of security varies based on the type of organization using
-a cloud. For example, government and financial institutions often have
-very high security requirements. Security should be implemented according to
-asset, threat, and vulnerability risk assessment matrices.
-See :ref:`security-requirements`.
-
-
-Service level agreements
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Service level agreements (SLA) must be developed in conjunction with business,
-technical, and legal input. Small, private clouds may operate under an informal
-SLA, but hybrid or public clouds generally require more formal agreements with
-their users.
-
-For a user of a massively scalable OpenStack public cloud, there are no
-expectations for control over security, performance, or availability. Users
-expect only SLAs related to uptime of API services, and very basic SLAs for
-services offered. It is the user's responsibility to address these issues on
-their own. The exception to this expectation is the rare case of a massively
-scalable cloud infrastructure built for a private or government organization
-that has specific requirements.
-
-High performance systems have SLA requirements for a minimum :term:`quality of
-service (QoS)` with regard to guaranteed uptime, latency, and bandwidth. The
-level of the SLA can have a significant impact on the network architecture and
-requirements for redundancy in the systems.
-
-Hybrid cloud designs must accommodate differences in SLAs between providers,
-and consider their enforceability.

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

@@ -1,56 +0,0 @@
-.. meta::
-   :description: This guide targets OpenStack Architects
-                 for architectural design
-   :keywords: Architecture, OpenStack
-
-===================================
-OpenStack Architecture Design Guide
-===================================
-
-Abstract
-~~~~~~~~
-
-To reap the benefits of OpenStack, you should plan, design,
-and architect your cloud properly, taking user's needs into
-account and understanding the use cases.
-
-.. TODO rewrite the abstract
-
-Contents
-~~~~~~~~
-
-.. toctree::
-   :maxdepth: 2
-
-   common/conventions.rst
-   introduction.rst
-   identifying-stakeholders.rst
-   technical-requirements.rst
-   customer-requirements.rst
-   operator-requirements.rst
-   capacity-planning-scaling.rst
-   high-availability.rst
-   security-requirements.rst
-   legal-requirements.rst
-   arch-examples.rst
-
-Appendix
-~~~~~~~~
-
-.. toctree::
-   :maxdepth: 1
-
-   common/app_support.rst
-
-Glossary
-~~~~~~~~
-
-.. toctree::
-   :maxdepth: 1
-
-   common/glossary.rst
-
-Search in this guide
-~~~~~~~~~~~~~~~~~~~~
-
-* :ref:`search`

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

@@ -1,59 +0,0 @@
-=====================
-Operator requirements
-=====================
-
-.. toctree::
-   :maxdepth: 2
-
-   operator-requirements-sla.rst
-   operator-requirements-support-maintenance.rst
-   operator-requirements-ops-access.rst
-   operator-requirements-quota-management.rst
-   operator-requirements-policy-management.rst
-   operator-requirements-external-idp.rst
-   operator-requirements-upgrades.rst
-   operator-requirements-bleeding-edge.rst
-   operator-requirements-skills-training.rst
-
-Several operational factors affect the design choices for a general
-purpose cloud. Operations staff receive tasks regarding the maintenance
-of cloud environments, including:
-
-Maintenance tasks
-    Operating system patching, hardware/firmware upgrades, and datacenter
-    related changes, as well as minor and release upgrades to OpenStack
-    components are all ongoing operational tasks. In particular, the six
-    monthly release cycle of the OpenStack projects needs to be considered as
-    part of the cost of ongoing maintenance. The solution should take into
-    account storage and network maintenance and the impact on underlying
-    workloads.
-
-Reliability and availability
-    Reliability and availability depend on the many supporting components'
-    availability and on the level of precautions taken by the service provider.
-    This includes network, storage systems, datacenter, and operating systems.
-
-In order to run efficiently, automate as many of the operational processes as
-possible. Automation includes the configuration of provisioning, monitoring and
-alerting systems. Part of the automation process includes the capability to
-determine when human intervention is required and who should act. The
-objective is to increase the ratio of operational staff to running systems as
-much as possible in order to reduce maintenance costs. In a massively scaled
-environment, it is very difficult for staff to give each system individual
-care.
-
-Configuration management tools such as Ansible, Puppet, and Chef enable
-operations staff to categorize systems into groups based on their roles and
-thus create configurations and system states that the provisioning system
-enforces. Systems that fall out of the defined state due to errors or failures
-are quickly removed from the pool of active nodes and replaced.
-
-At large scale, the resource cost of diagnosing failed individual systems is
-far greater than the cost of replacement. It is more economical to replace the
-failed system with a new system, provisioning and configuring it automatically
-and adding it to the pool of active nodes. By automating tasks that are
-labor-intensive, repetitive, and critical to operations, cloud operations
-teams can work more efficiently because fewer resources are required for these
-common tasks. Administrators are then free to tackle tasks that are not easy
-to automate and that have longer-term impact on the business, for example,
-capacity planning.

doc/arch-design-draft/source/use-cases.rst

@@ -14,3 +14,4 @@ Use cases
    use-cases/use-case-storage
    use-cases/use-case-multisite
    use-cases/use-case-nfv
+   use-cases/use-cases-specialized

doc/arch-design-draft/source/use-cases/specialized-desktop-as-a-service.rst

@@ -44,4 +44,4 @@ would not suffice for a large scale, enterprise solution.
 Diagram
 ~~~~~~~
 
-.. figure:: figures/Specialized_VDI1.png
+.. figure:: ../figures/Specialized_VDI1.png

doc/arch-design-draft/source/use-cases/specialized-hardware.rst

@@ -39,5 +39,5 @@ implementing and using it, is available at
 `https://wiki.openstack.org/wiki/Pci_passthrough <https://wiki.openstack.org/
 wiki/Pci_passthrough#How_to_check_PCI_status_with_PCI_api_patches>`_.
 
-.. figure:: figures/Specialized_Hardware2.png
+.. figure:: ../figures/Specialized_Hardware2.png
    :width: 100%

doc/arch-design-draft/source/use-cases/specialized-multi-hypervisor.rst

@@ -16,7 +16,7 @@ on ESXi. The remaining 250 or so have more flexible requirements.
 The financial company decides to manage the
 overall system with a common OpenStack platform.
 
-.. figure:: figures/Compute_NSX.png
+.. figure:: ../figures/Compute_NSX.png
    :width: 100%
 
 Architecture planning teams decided to run a host aggregate

doc/arch-design-draft/source/use-cases/specialized-openstack-on-openstack.rst

@@ -66,5 +66,5 @@ complex solution for such a use case.
 Diagram
 ~~~~~~~
 
-.. figure:: figures/Specialized_OOO.png
+.. figure:: ../figures/Specialized_OOO.png
    :width: 100%

doc/arch-design-draft/source/use-cases/specialized-software-defined-networking.rst

@@ -38,9 +38,9 @@ Diagram
 
 OpenStack hosted SDN controller:
 
-.. figure:: figures/Specialized_SDN_hosted.png
+.. figure:: ../figures/Specialized_SDN_hosted.png
 
 OpenStack participating in an SDN controller network:
 
-.. figure:: figures/Specialized_SDN_external.png
+.. figure:: ../figures/Specialized_SDN_external.png
 

doc/arch-design-draft/source/use-cases/use-cases-specialized.rst

@@ -1,6 +1,6 @@
-=================
-Specialized cases
-=================
+=====================
+Specialized use cases
+=====================
 
 .. toctree::
    :maxdepth: 2
@@ -15,13 +15,9 @@ Specialized cases
    specialized-add-region.rst
    specialized-scaling-multiple-cells.rst
 
-Although OpenStack architecture designs have been described
-in seven major scenarios outlined in other sections
-(compute focused, network focused, storage focused, general
-purpose, multi-site, hybrid cloud, and massively scalable),
-there are a few use cases that do not fit into these categories.
-This section discusses these specialized cases and provide some
-additional details and design considerations for each use case:
+
+This section provides details and design considerations for
+specialized cases:
 
 * :doc:`Specialized networking <specialized-networking>`:
   describes running networking-oriented software that may involve reading