From fbdbed180df4fe9b01dd4e5053ac8fdda4f897f9 Mon Sep 17 00:00:00 2001 From: Balazs Gibizer Date: Fri, 11 Apr 2014 09:47:02 +0200 Subject: [PATCH] Add soft policies for server-group feature This spec describes the need and a possible implementation of soft-affinty and soft-anti-affinty policies for the server group feature. bp soft-affinity-for-server-group Change-Id: I92c20913c11476722f2ab79233352bafb9705bfd --- .../soft-affinity-for-server-group.rst | 173 ++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 specs/kilo/approved/soft-affinity-for-server-group.rst diff --git a/specs/kilo/approved/soft-affinity-for-server-group.rst b/specs/kilo/approved/soft-affinity-for-server-group.rst new file mode 100644 index 000000000..2cecf12f5 --- /dev/null +++ b/specs/kilo/approved/soft-affinity-for-server-group.rst @@ -0,0 +1,173 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +============================================= +Add soft affinity support for server group +============================================= + +https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group + +As a tenant I would like to schedule instances on the same host if possible, +so that I can achieve collocation. However if it is not possible to schedule +some instance to the same host then I still want that the subsequent +instances are scheduled together on another host. In this way I can express +a good-to-have relationship between a group of instances. + +As a tenant I would like to schedule instances on different hosts if possible. +However if it is not possible I still want my instances to be scheduled even +if it means that some of them are placed on a host where another instances +are running from the same group. + + +Problem description +=================== + +Use Cases +---------- + +End User might want to have a less strict affinity and anti-affinity +rule than what is today available in server-group API extension. +With the proposed good-to-have affinity rule the End User can request nova +to schedule the instance to the same host if possible. However if it is not +possible (e.g. due to resource limitations) then End User still wants to keep +the instances on a small amount of different host. +With the proposed good-to-have anti-affinity rule the End User can request +nova to spread the instances in the same group as much as possible. + +Project Priority +----------------- +Not a priority in kilo + +Proposed change +=============== + +This change would extend the existing server-group API extension with two new +policies soft-affinity and soft-anti-affinity. +When a instance is booted into a group with soft-affinity policy the scheduler +will use a new weight AffinityWeight to sort the available hosts according to +the number of instances running on them from the same server-group in a +descending order. +When an instance is booted into a group with soft-anti-affinity policy the +scheduler will use a new weight AntiAffinityWeight to sort the available hosts +according to the number of instances running on them from the same +server-group in a ascending order. + +The two new weights will get the necessary information about the number of +instances per host through the weight_properties (filter_properties) in +a similar way as the GroupAntiAffinityFilter gets the list of hosts used by +a group via the filter_properties. + +These new soft-affinity and soft-anti-affinity policies are mutually exclusive +with each other and with the other existing server-group policies. + +If the scheduler sees a request which requires any of the new weigh classes but +those classes are not configured then the scheduler will reject the request +with an exception similarly to the case when affinity policy is requested but +ServerGroupAffinityFilter is not configured. + +Alternatives +------------ + +Alternatively End User can use the server-group with affinity policy and if +the instance cannot be scheduled because the host associated to the group is +full then End User can create a new server-group for the subsequent instances. +However with large amount of instances that occupy many hosts this manual +process can become quite cumbersome. + +Data model impact +----------------- + +No schema change is needed. + +There will be two new possible values soft-affinity and soft-anti-affinity for +the policy column of the instance_group_policy table. + +REST API impact +--------------- + +POST: v2/{tenant-id}/os-server-groups + The value of the policy request parameter can be soft-affinity and + soft-anti-affinity as well. + +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: + balazs-gibizer + + +Work Items +---------- + +* Add two new weights to the filter scheduler. These weights will + sort the available hosts by the number of instances from the same + server-group. +* Update FilterScheduler to use to reject the request if the new policy is + requested but the related weigh is not configured +* Update the server-group API extension to allow soft-affinity and + soft-anti-affinity as the policy of a group. + + +Dependencies +============ + +None + +Testing +======= + +Unit test coverage will be provided. + +New tempest test case will be provided that will try to boot two servers into +the same server group with soft-anti-affinity policy. The boot shall be +successful even if we have only one compute host. + +Documentation Impact +==================== + +New weights need to be described in filter_scheduler.rst + + +References +========== + +* instance-group-api-extension BP + https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension +* Group API wiki + https://wiki.openstack.org/wiki/GroupApiExtension