Bug 1041712

Summary: [RFE][cinder]: Multiple Capability Sets Per Backend
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: openstack-cinderAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact: Dafna Ron <dron>
Severity: low Docs Contact:
Priority: medium    
Version: unspecifiedCC: eharney, markmc, scohen, yeylon
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/cinder/+spec/multiple-capability-sets-per-backend
Whiteboard: upstream_milestone_next upstream_status_started upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-30 19:26:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 18:46:14 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/cinder/+spec/multiple-capability-sets-per-backend.

Description:

Currently backends can only return one number for "free space" and a set of capabilities. If the backend actually manages a device with two pools of storage with different capabilities, there is no way to report the free space for those two pools other than to setup two whole backends managing the same device.

This proposal is to make a small tweak to the get_volume_stats() driver entry point to allow it return a list of dicts rather than a single dict. Existing driver can easily be updated to return singleton lists to achieve the exact same behavior that exists today. On the scheduler side, new logic will be needed to handle an additional level of indirection, so the scheduler can perform scheduling across the "pools" and after the right pool is selected, the request will be forwarded onto the backend associated with that pool.

This proposal was discussed in HK as part of my vendor-neutral-extra-specs talk. Obviously we won't be pursuing standardization of extra_specs any further, but this small proposal was not controversial at that time.

Specification URL (additional information):

None

Comment 2 Sean Cohen 2015-06-30 19:26:02 UTC
No update on this one for 2 years now, closing upstream