Open Stack

On Dec 10, 2015 06:34, Mike Perez wrote:
> On 09:27 Dec 09, John Griffith wrote:
>> On Tue, Dec 8, 2015 at 9:10 PM, Li, Xiaoyan <xiaoyan.li at intel.com>
> wrote:
> 
> <snip>
> 
>>> As a result, this raises two concerns here:
>>> 1. Let such operations behavior same in Cinder.
>>> 2. I prefer to let storage driver decide the dependencies, not in
>>> the general core codes.
>>> 
>> 
>> ​I have and always will strongly disagree with this approach and your
>> proposal.  Sadly we've already started to allow more and more vendor
>> drivers just "do their own thing" and implement their own special API
>> methods.  This is in my opinion a horrible path and defeats the entire
>> purpose of have a Cinder abstraction layer.
>> 
>> This will make it impossible to have compatibility between clouds for
>> those that care about it, it will make it impossible for
>> operators/deployers to understand exactly what they can and should
>> expect in terms of the usage of their cloud.  Finally, it will also
>> mean that not OpenStack API functionality is COMPLETELY dependent on
>> backend device.  I know people are sick of hearing me say this, so I'll
>> keep it short and say it one more time: "Compatibility in the API
>> matters and should always be our priority"
> 
> +1
>

This seems that cinder needs to take more and more works, and vendor storages do what cinder asks them to. 
For example, cinder supports full and incremental snapshots in core codes, and it keeps the dependencies like backups. 

More general example is that storage vendors supports kinds of volumes, like normal, provisioned, and compressed etc. 
Cinder needs to implement such functions in core codes. Every storage vendor report their capability to cinder scheduler. 
When users create a volume, scheduler finds a storage vendor based on their capacities. 
(Of course these functions in cinder should be general and implemented by most of vendor storages. )

But currently cinder core codes do little, lots of this are in extra_specs, conf file which are handled in vendor drivers. 

This leads to a problem like extending volume. Extending a volume in an incremental snapshot fails
in vendor storage.  And then the cinder volume goes into error_extending status. From my opinion this is not good. 

Best wishes
Lisa