Dynamic multiple service pools per backend

The scheduler is designed to take provisioning decisions based on the statistics reported by back ends periodically. Any back end is assumed to be a single discrete unit with specific set of capabilities and capacities offered and also these characteristics are constant through out the boundary of the storage addressed/managed by the back end. In reality this assumption is not true for many storage providers and the storage managed by a particular back end instance may be further sub divided or partitioned to offer completely different set of capabilities and capacities and hence is a combination of storage pools rather than a single homogenous storage provider. Hence it is important to develop or extend cinder to be able to detect storage pools within a back end and also represent them as separate storage entities within cinder vol and scheduler to make efficient and correct provisioning decisions.

The aim of this blueprint is to address the following:

1. Ability to detect storage pools within a back end.
2. Provide a mechanism to represent discovered storage pools as separate storage entities within cinder. Hence separate the capabilities and capacities offered by them.
3. Provide flexibility to vendors to define their own storage pools and also the boundary of a storage pool. So if a vendor does not support or defines pools, let him continue with his regular back end.
4. Provide the ability to dynamically discover new storage pools within a back end.
5. While achieving the above, try to minimize the resource utilization on the cinder node even on low end servers.
6. Provide a mechanism to seamlessly upgrade/transform the running cinder service/back end holding volumes into new world of pools.