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
This commit is contained in:
Balazs Gibizer
173
specs/kilo/approved/soft-affinity-for-server-group.rst
Normal file
173
specs/kilo/approved/soft-affinity-for-server-group.rst
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user