From e954dd42e44e845af5b068a9333c9da81c9117fb Mon Sep 17 00:00:00 2001 From: Alexandra Date: Wed, 13 Apr 2016 16:27:32 +1000 Subject: [PATCH] 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 --- .../source/functional-requirements.rst | 9 --- doc/arch-design-draft/source/index.rst | 2 +- doc/arch-design-draft/source/introduction.rst | 5 +- .../operator-requirements-licensing.rst | 33 ---------- .../source/operator-requirements.rst | 5 -- ...nical-requirements-hardware-selection.rst} | 0 ...nical-requirements-logging-monitoring.rst} | 0 ...technical-requirements-network-design.rst} | 0 ...nical-requirements-software-selection.rst} | 34 +++++++++++ .../source/technical-requirements.rst | 61 +++++++++++++++++++ 10 files changed, 99 insertions(+), 50 deletions(-) delete mode 100644 doc/arch-design-draft/source/functional-requirements.rst delete mode 100644 doc/arch-design-draft/source/operator-requirements-licensing.rst rename doc/arch-design-draft/source/{operator-requirements-hardware-selection.rst => technical-requirements-hardware-selection.rst} (100%) rename doc/arch-design-draft/source/{operator-requirements-logging-monitoring.rst => technical-requirements-logging-monitoring.rst} (100%) rename doc/arch-design-draft/source/{operator-requirements-network-design.rst => technical-requirements-network-design.rst} (100%) rename doc/arch-design-draft/source/{operator-requirements-software-selection.rst => technical-requirements-software-selection.rst} (84%) create mode 100644 doc/arch-design-draft/source/technical-requirements.rst diff --git a/doc/arch-design-draft/source/functional-requirements.rst b/doc/arch-design-draft/source/functional-requirements.rst deleted file mode 100644 index 6f91ebd156..0000000000 --- a/doc/arch-design-draft/source/functional-requirements.rst +++ /dev/null @@ -1,9 +0,0 @@ -======================= -Functional requirements -======================= - -.. toctree:: - :maxdepth: 2 - - - diff --git a/doc/arch-design-draft/source/index.rst b/doc/arch-design-draft/source/index.rst index 19920b818a..0d14b56c1b 100644 --- a/doc/arch-design-draft/source/index.rst +++ b/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 diff --git a/doc/arch-design-draft/source/introduction.rst b/doc/arch-design-draft/source/introduction.rst index a8802fe450..9cff71f50d 100644 --- a/doc/arch-design-draft/source/introduction.rst +++ b/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 `: Information for - SMEs on deployment methods and how they will affect deployment cost. +* :doc:`Technical requirements `: + Information for SMEs on deployment methods and how they will affect + deployment cost. * :doc:`Customer requirements `: Information for SMEs on business and technical requirements. diff --git a/doc/arch-design-draft/source/operator-requirements-licensing.rst b/doc/arch-design-draft/source/operator-requirements-licensing.rst deleted file mode 100644 index b48f8774cf..0000000000 --- a/doc/arch-design-draft/source/operator-requirements-licensing.rst +++ /dev/null @@ -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. diff --git a/doc/arch-design-draft/source/operator-requirements.rst b/doc/arch-design-draft/source/operator-requirements.rst index be7a0baf0f..f4e9ba7bd9 100644 --- a/doc/arch-design-draft/source/operator-requirements.rst +++ b/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 diff --git a/doc/arch-design-draft/source/operator-requirements-hardware-selection.rst b/doc/arch-design-draft/source/technical-requirements-hardware-selection.rst similarity index 100% rename from doc/arch-design-draft/source/operator-requirements-hardware-selection.rst rename to doc/arch-design-draft/source/technical-requirements-hardware-selection.rst diff --git a/doc/arch-design-draft/source/operator-requirements-logging-monitoring.rst b/doc/arch-design-draft/source/technical-requirements-logging-monitoring.rst similarity index 100% rename from doc/arch-design-draft/source/operator-requirements-logging-monitoring.rst rename to doc/arch-design-draft/source/technical-requirements-logging-monitoring.rst diff --git a/doc/arch-design-draft/source/operator-requirements-network-design.rst b/doc/arch-design-draft/source/technical-requirements-network-design.rst similarity index 100% rename from doc/arch-design-draft/source/operator-requirements-network-design.rst rename to doc/arch-design-draft/source/technical-requirements-network-design.rst diff --git a/doc/arch-design-draft/source/operator-requirements-software-selection.rst b/doc/arch-design-draft/source/technical-requirements-software-selection.rst similarity index 84% rename from doc/arch-design-draft/source/operator-requirements-software-selection.rst rename to doc/arch-design-draft/source/technical-requirements-software-selection.rst index e5c007e587..784ecb0848 100644 --- a/doc/arch-design-draft/source/operator-requirements-software-selection.rst +++ b/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. diff --git a/doc/arch-design-draft/source/technical-requirements.rst b/doc/arch-design-draft/source/technical-requirements.rst new file mode 100644 index 0000000000..36605ae2b7 --- /dev/null +++ b/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 `_ +* `OpenStack Installation Guide for Red Hat Enterprise Linux and CentOS `_ +* `OpenStack Installation Guide for openSUSE and SUSE Linux Enterprise `_