Move design_docs into docs/design

Change HTML theme for sphinx
Fix makefile reference to old design_docs dir

Change-Id: I848115c5901db8dc33aa4157bdbc8af430695f31
Signed-off-by: blsaws <blsaws@hotmail.com>

1 files changed, 0 insertions, 167 deletions

diff --git a/design_docs/usecases.rst b/design_docs/usecases.rst
deleted file mode 100644
index c4e6abd..0000000
--- a/design_docs/usecases.rst
+++ /dev/null
@@ -1,167 +0,0 @@
-Use Cases
-=========
-
-Resource Requirements
-+++++++++++++++++++++
-
-Workload Placement
-------------------
-
-Affinity
-........
-
-Ensures that the VM instance is launched "with affinity to" specific resources, e.g. within a compute or storage cluster. This is analogous to the affinity rules in `VMWare vSphere DRS <https://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.resmgmt.doc_50/GUID-FF28F29C-8B67-4EFF-A2EF-63B3537E6934.html>`_. Examples include: "Same Host Filter", i.e. place on the same compute node as a given set of instances, e.g. as defined in a scheduler hint list.
-
-As implemented by OpenStack Heat using server groups:
-
-*Note: untested example...*
-
-.. code::
-
-	resources: 
-	  servgrp1: 
-		type: OS::Nova::ServerGroup
-		properties: 
-		  policies: 
-		  - affinity
-		  serv1:
-			type: OS::Nova::Server
-			properties:
-				image: { get_param: image }
-				flavor: { get_param: flavor }
-				networks:
-					- network: {get_param: network}
-		  serv2:
-			type: OS::Nova::Server
-			properties:
-				image: { get_param: image }
-				flavor: { get_param: flavor }
-				networks:
-					- network: {get_param: network}
-
-Anti-Affinity
-.............
-
-Ensures that the VM instance is launched "with anti-affinity to" specific resources, e.g. outside a compute or storage cluster, or geographic location. This filter is analogous to the anti-affinity rules in vSphere DRS. Examples include: "Different Host Filter", i.e. ensures that the VM instance is launched on a different compute node from a given set of instances, as defined in a scheduler hint list.
-
-As implemented by OpenStack Heat using scheduler hints:
-
-*Note: untested example...*
-
-.. code::
-
-	heat template version: 2013-05-23
-	parameters:
-	  image:
-		type: string
-		default: TestVM
-	  flavor:
-		type: string
-		default: m1.micro
-	  network:
-		type: string
-		default: cirros_net2
-	resources:
-	  serv1:
-		type: OS::Nova::Server
-		properties:
-			image: { get_param: image }
-			flavor: { get_param: flavor }
-			networks:
-				- network: {get_param: network}
-			scheduler_hints: {different_host: {get_resource: serv2}}
-	  serv2:
-		type: OS::Nova::Server
-		properties:
-			image: { get_param: image }
-			flavor: { get_param: flavor }
-			networks:
-				- network: {get_param: network}
-			scheduler_hints: {different_host: {get_resource: serv1}}
-
-DMZ Deployment
-..............
-As a service provider, I need to ensure that applications which have not been designed for exposure in a DMZ zone, are not attached to DMZ networks.
-
-Configuration Auditing
-----------------------
-
-As a service provider or tenant, I need to periodically verify that resource configuration requirements have not been violated, as a backup means to proactive or reactive policy enforcement.
-
-Generic Policy Requirements
-+++++++++++++++++++++++++++
-
-NFVI Self-Service Constraints
------------------------------
-
-As an NFVI provider, I need to ensure that my self-service tenants are not able to configure their VNFs in ways that would impact other tenants or the reliability, security, etc of the NFVI.
-
-Network Access Control
-......................
-
-Networks connected to VMs must be public, or owned by someone in the VM owner's group.
-
-This use case captures the intent of the following sub-use-cases:
-
-  * Link Mirroring: As a troubleshooter, I need to mirror traffic from physical or virtual network ports so that I can investigate trouble reports.
-  * Link Mirroring: As a NFVaaS tenant, I need to be able to mirror traffic on my virtual network ports so that I can investigate trouble reports.
-  * Unauthorized Link Mirroring Prevention: As a NFVaaS tenant, I need to be able to prevent other tenants from mirroring traffic on my virtual network ports so that I can protect the privacy of my service users.
-  * Link Mirroring Delegation: As a NFVaaS tenant, I need to be able to allow my NFVaaS SP customer support to mirror traffic on my virtual network ports so that they can assist in investigating trouble reports.
-
-As implemented through OpenStack Congress: 
-
-.. code:: 
-
-   error :- 
-   nova:vm(vm), 
-   neutron:network(network), 
-   nova:network(vm, network), 
-   neutron:private(network), 
-   nova:owner(vm, vm-own), 
-   neutron:owner(network, net-own), 
-   -same-group(vm-own, net-own)
-		 
-   same-group(user1, user2) :- 
-   ldap:group(user1, g), 
-   ldap:group(user2, g)
-   
-
-Storage Access Control
-......................
-
-Storage resources connected to VMs must be owned by someone in the VM owner's group.
-
-As implemented through OpenStack Congress: 
-
-.. code:: 
-
-  error :- 
-  nova:vm(vm), 
-  cinder:volumes(volume), 
-  nova:volume(vm, volume), 
-  nova:owner(vm, vm-own), 
-  neutron:owner(volume, vol-own), 
-  -same-group(vm-own, vol-own)
- 
-  same-group(user1, user2) :- 
-  ldap:group(user1, g), 
-  ldap:group(user2, g)
-
-Resource Reclamation
---------------------
-
-As a service provider or tenant, I need to be informed of VMs that are under-utilized so that I can reclaim the VI resources. (example from `RuleYourCloud blog <http://ruleyourcloud.com/2015/03/12/scaling-up-congress.html>`_) 
-
-As implemented through OpenStack Congress: 
-
-.. code:: 
-
-  reclaim_server(vm) :-
-  ceilometer:stats("cpu_util",vm, avg_cpu),
-  lessthan(avg_cpu, 1)
-
-  error(user_id, email, vm_name) :-
-  reclaim_server(vm),
-  nova:servers(vm, vm_name, user_id),
-  keystone:users(user_id, email)
-