Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP
Hello, Shlomi. On Tue, Mar 25, 2014 at 7:07 PM, Shlomi Sasson wrote: > > 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. > > I remember Ann working on https://review.openstack.org/#/c/45393 and it has landed since. That change leaves ISERDriver just for backward compatibility and allows ISCSIDriver and any its descendant to use iscsi_helper='iseradm' to provide iSER usage. Aren't those changes enough for this? What else is needed here? -- Kind regards, Yuriy. ___ 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
On Thu, Mar 27, 2014 at 10:45 AM, Shlomi Sasson wrote: > Of course I’m aware of that.. I’m the one who pushed it there in the > first place J > > 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 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.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 > > Hi Shlomis, I started working on something similar to this that decouples data-path and control-plan for the backend devices and threw some ideas out in Cinder channel this morning. Luckily some folks remembered this post and pointed me to it :) Wondering did you ever post anything here? Would you be interested in collaborating on this and sharing ideas? I'm planning to have a prototype ready to share later this week, but it sounds like you may already have a lot of this done so it would be cool if we worked together on it. Thanks, John ___ 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 mailto: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.org<mailto: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
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
On Wed, Mar 26, 2014 at 12:18 PM, Eric Harney 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.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
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
Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP
This all makes sense to me. I would suggest a blueprint and a pull request as soon as Juno opens. Vish On Mar 25, 2014, at 8:07 AM, Shlomi Sasson wrote: > 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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.org<mailto: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
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.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
