From e634b830228b5eaace9faa7bb6ff622572c8c0fc Mon Sep 17 00:00:00 2001
From: licanwei
Date: Mon, 12 Aug 2019 19:45:41 +0800
Subject: [PATCH] node resource consolidation spec
Partially Implements: blueprint node-resource-consolidation
Change-Id: I010b340cb3a715f39de726d1ec0c94659b337cd4
---
.../approved/node-resource-consolidation.rst | 164 ++++++++++++++++++
1 file changed, 164 insertions(+)
create mode 100644 specs/train/approved/node-resource-consolidation.rst
diff --git a/specs/train/approved/node-resource-consolidation.rst b/specs/train/approved/node-resource-consolidation.rst
new file mode 100644
index 0000000..8363df9
--- /dev/null
+++ b/specs/train/approved/node-resource-consolidation.rst
@@ -0,0 +1,164 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+===========================
+Node Resource Consolidation
+===========================
+
+https://blueprints.launchpad.net/watcher/+spec/node-resource-consolidation
+
+
+Problem description
+===================
+
+In the edge computing system, the edge nodes are distributed in different
+locations. Although the total number of edge nodes may be large, the number
+of edge nodes in each location is limited, so the resources(VCPU, memory)
+are limited. An application scenario is to dynamically create VM(application)
+processing service. After the processing is complete, the VM is deleted and
+the resource is released. During this process(creating and deleting VM on
+different nodes), resource fragments are generated. For example, if two nodes
+each have two free VCPUs, even if the total VCPUs is enough, creating a VM
+with four VCPUs will still fail.
+
+Use Cases
+----------
+
+As a Watcher user, I wish Watcher provides a strategy which can eliminate
+resource fragmentation by consolidating resources on nodes.
+
+
+Proposed change
+===============
+
+* Add a new strategy: Node Resource Consolidation
+
+* One input parameter: host_choice(specify/auto). This parameter
+ determines how to select the server migration destination node.
+ The value `auto` means that Nova schedular selects the destination node,
+ and `specify` means the strategy specifies the destination.
+ The default value is `auto`.
+
+* The algorithm of this strategy:
+
+ * Caculating the used resources of compute nodes
+ * Sorting compute nodes by the used resources percent
+ * Dividing compute nodes into source group and destination group.
+ The process: For sorted compute nodes, from the one that uses least
+ resources, if all servers can be migrated to other compute nodes,
+ we put this node into source group, and other nodes into destination
+ group. repeating this process until all compute nodes are placed in
+ the source or destination group.
+ For `continuous` audit, if there is server that had failed during previous
+ actionplan, we should put this compute node to the destination group.
+ * Creating strategy solution:
+ If the parameter `host_choice` is `auto`, creating a migration action for
+ each VM in the source group and compute nodes in source should be disabled
+ before server migration and be enabled after finishing the migration.
+ If the parameter `host_choice` is `specify`, the nodes in the destination
+ group are sorted by free resources. Then, for each VM on the source node,
+ select a node that is most suitable for the VM from the destination group
+ as the destination node of the migration. Repeat this process (reordering
+ the destination group by free resources each time), until all VMs have
+ destination or there is insufficient resources.
+
+Alternatives
+------------
+
+None
+
+Data model impact
+-----------------
+
+None
+
+REST API impact
+---------------
+
+None
+
+Security impact
+---------------
+
+None
+
+Notifications impact
+--------------------
+
+None
+
+Other end user impact
+---------------------
+
+None
+
+Performance Impact
+------------------
+
+None
+
+Other deployer impact
+---------------------
+
+None
+
+Developer impact
+----------------
+
+None
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+ licanwei
+
+Work Items
+----------
+
+* Add a new parameter `audit` to the method do_execute of strategy.
+* Add the new strategy.
+
+
+Dependencies
+============
+
+None
+
+
+Testing
+=======
+
+Unit and functional test are needed.
+
+
+Documentation Impact
+====================
+
+Add docs on how to use this strategy.
+
+
+References
+==========
+
+None
+
+
+History
+=======
+
+.. list-table:: Revisions
+ :header-rows: 1
+
+ * - Release Name
+ - Description
+ * - Train
+ - Introduced
+