Open Stack

On Thu, Jan 31, 2013 at 8:56 AM, Koert van der Veer <koert at cloudvps.com>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 at gmail.com>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 at il.ibm.com>
>> wrote:
>> > openstack-bounces+avishay=il.ibm.com at lists.launchpad.net wrote on
>> > 01/31/2013 12:37:07 AM:
>> >> From: Tom Fifield <fifieldt at unimelb.edu.au>
>> >> To: openstack at lists.launchpad.net,
>> >> Date: 01/31/2013 12:38 AM
>> >> Subject: Re: [Openstack] List of Cinder compatible devices
>> >> Sent by: openstack-bounces+avishay=il.ibm.com at lists.launchpad.net
>> >>
>> >> 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 at lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Shake Chen
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130131/39351006/attachment.html>