4.3 KiB
Support filter backend based on operation type
https://blueprints.launchpad.net/cinder/+spec/support-mark-pool-sold-out
This blueprint proposes to support filter backend based on operation type.
Problem description
Now our filter and weigher plugins' algorithm are all designed based on two factors, backend information and user input. But there could be another factor that may also affect the scheduler result, operation type. For instance, if administrators want to disable some of the backend pool only for creating new volume operation, it's impossible based on our current logic.
Use Cases
We have discussed the concept of sold out during Rocky PTG [1] and that word is more related to administrative operation, when most of an specific pool's capacity has been consumed, administrators need the functionality to mark the backend pool sold out, that is to say, it will become unavailable for allocating new volumes, but end users still can perform any operations on their existing resources (extend volume, create snapshot).
Adding this feature in cinder will help cloud vendors write their own plugins which can filter backend based on the operation type as well as backend information.
Proposed change
New attribute operation
will be added into
RequestSpec
object and plugins can filter backend based on
backend states as well as request type:
def backend_passes(self, backend_state, filter_properties):
#get request type from filter_properties
= filter_properties.get('request_spec', {})
spec = spec.get('operation', None)
request_type if request_type in ['create_volume']:
#check backend state when request is for creating new volume
return backend_state.free_capacity_gb > MIN_REQUIRED_GB
if request_type in ['extend_volume', 'retype_volume']
#perform other validation when request is ......
NOTE: This spec doesn't propose to update any
plugin's logic, the code above only intends to demonstrate how the
operation
can be used.
Based on our current features, the value of operation
can be one of these below:
- create_group
- manage_existing
- extend_volume
- create_volume
- create_snapshot
- migrate_volume
- retype_volume
- manage_existing_snapshot
And we will inject scheduler manager's corresponding methods in order
to append this info to RequestSpec
automatically:
@append_operation
def extend_volume(self, context, volume, new_size, reservations,
=None, filter_properties=None):
request_spec#other existing codes
Alternatives
The alternative is to implement a custom scheduler manager and
configure it in scheduler_manager
and then use either a
custom filter or the JSON filter.
Data model impact
RequestSpec
will be updated to store this new
attribute.
REST API impact
None
Cinder-client impact
None
Security impact
None
Notifications impact
None
Other end user impact
None
Performance Impact
None
Other deployer impact
None
Developer impact
Developers can develop new scheduler plugins based on backend state as well as request type.
Implementation
Assignee(s)
- Primary assignee:
-
tommylikehu(tommylikehu@gmail.com)
Work Items
- Add
operation
to those actions which will be scheduled to scheduler to perform filtering and weighing logic.
Dependencies
None
Testing
- Add unit tests to cover this change.
Documentation Impact
- Update the developer document to mention the new attribute will be delivered to scheduler plugins as well.
References
_`[1]: https://etherpad.openstack.org/p/cinder-ptg-rocky-wednesday _[2]`: https://review.openstack.org/#/c/308869/