openstack team mailing list archive

[Blair Bethwaite <blair.bethwaite@xxxxxxxxx>]

Hi John,

Sounds sensible. I think this post kind of diverged from what Tim was
asking, which seems to have been more about backend devices...?

Should this page be removed then, and a summary of what you wrote added to
the Cinder wiki page (including any exceptions for current core drivers)?

(On a related note, I don't think "List Snapshots" should be there, IIUC
that is not a function of the driver and rather about looking in the DB at
data produced by create/delete snapshot driver calls.)

Cheers,


On 1 February 2013 04:12, John Griffith <john.griffith@xxxxxxxxxxxxx> wrote:

>
>
> On Thu, Jan 31, 2013 at 8:56 AM, Koert van der Veer <koert@xxxxxxxxxxxx>wrote:
>
>>  In that case, it is probably best to transpose the table, with series
>> included, the number of products will yield too many columns to be workable.
>>
>> Also: Do blank spaces indicate "not supported" or "unknown"?
>>
>> koert
>>
>>
>> On 01/31/2013 04:47 PM, Shake Chen wrote:
>>
>> I think need add Vendor storage series.
>>
>> like not all the EMC storage would support Cinder.
>>
>>
>>
>>  On Thu, Jan 31, 2013 at 11:19 PM, Sébastien Han <han.sebastien@xxxxxxxxx
>> > wrote:
>>
>>> Just added some stuff about RBD where E refers to Essex.
>>>
>>> --
>>> Regards,
>>> Sébastien Han.
>>>
>>>
>>> On Thu, Jan 31, 2013 at 11:20 AM, Avishay Traeger <AVISHAY@xxxxxxxxxx>
>>> wrote:
>>> > openstack-bounces+avishay=il.ibm.com@xxxxxxxxxxxxxxxxxxx wrote on
>>> > 01/31/2013 12:37:07 AM:
>>> >> From: Tom Fifield <fifieldt@xxxxxxxxxxxxxx>
>>> >> To: openstack@xxxxxxxxxxxxxxxxxxx,
>>> >> Date: 01/31/2013 12:38 AM
>>> >> Subject: Re: [Openstack] List of Cinder compatible devices
>>> >> Sent by: openstack-bounces+avishay=il.ibm.com@xxxxxxxxxxxxxxxxxxx
>>> >>
>>> >> Here's a starting point:
>>> >>
>>> >> http://wiki.openstack.org/CinderSupportMatrix
>>> >>
>>> >> Regards,
>>> >>
>>> >> Tom
>>> >
>>> > Tom,
>>> > Thanks for doing this.  I recommend that instead of "Y", we should put
>>> the
>>> > letter of the version in which the feature first appeared.  So for
>>> example,
>>> > "E", "F", "G", ...
>>> >
>>> > Thanks,
>>> > Avishay
>>> >
>>> >
>>> > _______________________________________________
>>> > Mailing list: https://launchpad.net/~openstack
>>> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~openstack
>>> > More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> --
>> Shake Chen
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>> So thanks for putting this together but this brings something up that
> I've been meaning to raise on the dev-list anyway.  In my opinion it should
> be a requirement that for a driver to be accepted in Cinder it implements
> all of the functionality of the base LVM driver (ie all of the rows listed
> in the matrix here).
>
> Having to go through and determine what feature is or is not supported per
> driver is EXACTLY what I want to avoid. If we go down the path of building
> a matrix and allowing partial integration it's going to create a huge mess
> and IMO the user experience is going to suffer greatly.  Of course a driver
> can do more than what's on the list, but I think this is the minimum
> requirement and I've been pushing back on submissions based on this.
>
> The only exceptions have been some of the newer Grizzly features, but
> that's only because we're moving those up to generalized cases that folks
> can inherit from if they use iSCSI.  For those that want to do FC or AOE
> drivers however they're going to need to have a solution of their own.
>
> My thought is there should be a simple list of back-end device and version
> and whether it's supported in Grizzly or Folsom or .....  All API features
> should be assumed available.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Cheers,
~Blairo