Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP
LIO already support iser (starting kernel 3.10), and its implementation can accept rdma or tcp in the same target -Original Message- From: Eric Harney [mailto:ehar...@redhat.com] Sent: Wednesday, March 26, 2014 20:22 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP On 03/25/2014 11:07 AM, Shlomi Sasson wrote: I am not sure what will be the right approach to handle this, I already have the code, should I open a bug or blueprint to track this issue? Best Regards, Shlomi A blueprint around this would be appreciated. I have had similar thoughts around this myself, that these should be options for the LVM iSCSI driver rather than different drivers. These options also mirror how we can choose between tgt/iet/lio in the LVM driver today. I've been assuming that RDMA support will be added to the LIO driver there at some point, and this seems like a nice way to enable that. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP
Of course I'm aware of that.. I'm the one who pushed it there in the first place :) But it was not the best way to handle this.. I think that the right/better approach is as suggested. I'm planning to remove the existing ISERDriver code, this will eliminate significant code and class duplication, and will work with all the iSCSI vendors who supports both tcp and rdma without the need to modify their plug-in drivers. From: John Griffith [mailto:john.griff...@solidfire.com] Sent: Wednesday, March 26, 2014 22:47 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP On Wed, Mar 26, 2014 at 12:18 PM, Eric Harney ehar...@redhat.commailto:ehar...@redhat.com wrote: On 03/25/2014 11:07 AM, Shlomi Sasson wrote: I am not sure what will be the right approach to handle this, I already have the code, should I open a bug or blueprint to track this issue? Best Regards, Shlomi A blueprint around this would be appreciated. I have had similar thoughts around this myself, that these should be options for the LVM iSCSI driver rather than different drivers. These options also mirror how we can choose between tgt/iet/lio in the LVM driver today. I've been assuming that RDMA support will be added to the LIO driver there at some point, and this seems like a nice way to enable that. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'm open to improving this, but I am curious you know there's an ISER subclass in iscsi for Cinder currently right? http://goo.gl/kQJoDO ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP
Hi Ramy, There is quite a bit of difference between FC and iSCSI (e.g. iqn vs WWN ..) While iSER is just an alternative iSCSI transport, and use the exact same tools on the initiator and target like iSCSI/TCP Most iSER capable iSCSI targets don't even have a separate configuration for TCP or RDMA, and would accept both transports options on a given logical iSCSI target (why we don't need a different plug-ins for targets with exception of STGT) On the initiator side the only difference between TCP and RDMA is in the interface flag (--interface=[iface]) e.g. iscsiadm -m discoverydb -t st -p ip:port -I iser --discover so we don't need a full new class to propagate a simple flag, and rather make this a simple parameter we also though of modifying the operation that default_rdma would mean try RDMA and if it fails fall back to TCP, to simplify operations. Shlomi From: Asselin, Ramy [mailto:ramy.asse...@hp.com] Sent: Tuesday, March 25, 2014 17:55 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP Hi Shlomi, Another solution to consider is to create a subclass per transport (iSCSI, iSER) which reference the same shared common code. This is the solution used for the 3PAR iSCSI FC transports. See these for reference: cinder/volume/drivers/san/hp/hp_3par_common.py cinder/volume/drivers/san/hp/hp_3par_fc.py cinder/volume/drivers/san/hp/hp_3par_iscsi.py Hope this helps. Ramy From: Shlomi Sasson [mailto:shlo...@mellanox.com] Sent: Tuesday, March 25, 2014 8:07 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP Hi, I want to share with the community the following challenge: Currently, Vendors who have their iSCSI driver, and want to add RDMA transport (iSER), cannot leverage their existing plug-in which inherit from iSCSI And must modify their driver or create an additional plug-in driver which inherit from iSER, and copy the exact same code. Instead I believe a simpler approach is to add a new attribute to ISCSIDriver to support other iSCSI transports besides TCP, which will allow minimal changes to support iSER. The existing ISERDriver code will be removed, this will eliminate significant code and class duplication, and will work with all the iSCSI vendors who supports both TCP and RDMA without the need to modify their plug-in drivers. To achieve that both cinder nova requires slight changes: For cinder, I wish to add a parameter called transport (default to iscsi) to distinguish between the transports and use the existing iscsi_ip_address parameter for any transport type connection. For nova, I wish to add a parameter called default_rdma (default to false) to enable initiator side. The outcome will avoid code duplication and the need to add more classes. I am not sure what will be the right approach to handle this, I already have the code, should I open a bug or blueprint to track this issue? Best Regards, Shlomi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP
Hi, I want to share with the community the following challenge: Currently, Vendors who have their iSCSI driver, and want to add RDMA transport (iSER), cannot leverage their existing plug-in which inherit from iSCSI And must modify their driver or create an additional plug-in driver which inherit from iSER, and copy the exact same code. Instead I believe a simpler approach is to add a new attribute to ISCSIDriver to support other iSCSI transports besides TCP, which will allow minimal changes to support iSER. The existing ISERDriver code will be removed, this will eliminate significant code and class duplication, and will work with all the iSCSI vendors who supports both TCP and RDMA without the need to modify their plug-in drivers. To achieve that both cinder nova requires slight changes: For cinder, I wish to add a parameter called transport (default to iscsi) to distinguish between the transports and use the existing iscsi_ip_address parameter for any transport type connection. For nova, I wish to add a parameter called default_rdma (default to false) to enable initiator side. The outcome will avoid code duplication and the need to add more classes. I am not sure what will be the right approach to handle this, I already have the code, should I open a bug or blueprint to track this issue? Best Regards, Shlomi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
