Re: Running iscsiadm in containers
On Sunday, December 16, 2018 at 5:14:03 PM UTC-8, m...@datera.io wrote: > > As a baseline here are the previous threads discussing this issue > including the RFC from Chris Leech. > > https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/P8-oUDkb14YJ > https://groups.google.com/forum/#!msg/open-iscsi/kgjck_GixsM/U_FqTbYhCgAJ > > I think we should try and move Chris's implementation forward if > possible. Many organizations are hitting real pain-points not having a > container-compatible open-iscsi implementation, especially with the advent > of the ubiquity of containers within the storage vendor world. > > On Tuesday, October 23, 2018 at 9:03:01 AM UTC-7, Shailesh Mittal wrote: >> >> Hi there, >> >> I understand that it was the topic of discussion earlier. As containers >> are getting used more and more to run applications, there are frameworks >> like Kubernetes (and more) where the calls to talk to scsi storage devices >> are being made through a container. >> >> Here, vendors are in flux as they need to execute iscsiadm commands to >> connect their iscsi based storage to the application-containers. These >> caller modules (responsible for connecting to the remote storage) are >> running in the containers and thus have no choice but executing iscsiadm >> commands from the containers itself. >> >> Is there a well understood way to implement this? I remember the thread >> from Chris Leech talking about containerizing iscsid but not sure the >> end-result of that. ( >> https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/NdZPh33ed0oJ >> ) >> >> Any help/direction here is much appreciated. >> >> Thanks, >> Shailesh Mittal. >> > Yes, after reviewing the thread, I'd like to move forward with these changes as well. Chris, do you have time to move forward with this? I'd be glad to help. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
As a baseline here are the previous threads discussing this issue including the RFC from Chris Leech. https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/P8-oUDkb14YJ https://groups.google.com/forum/#!msg/open-iscsi/kgjck_GixsM/U_FqTbYhCgAJ I think we should try and move Chris's implementation forward if possible. Many organizations are hitting real pain-points not having a container-compatible open-iscsi implementation, especially with the advent of the ubiquity of containers within the storage vendor world. On Tuesday, October 23, 2018 at 9:03:01 AM UTC-7, Shailesh Mittal wrote: > > Hi there, > > I understand that it was the topic of discussion earlier. As containers > are getting used more and more to run applications, there are frameworks > like Kubernetes (and more) where the calls to talk to scsi storage devices > are being made through a container. > > Here, vendors are in flux as they need to execute iscsiadm commands to > connect their iscsi based storage to the application-containers. These > caller modules (responsible for connecting to the remote storage) are > running in the containers and thus have no choice but executing iscsiadm > commands from the containers itself. > > Is there a well understood way to implement this? I remember the thread > from Chris Leech talking about containerizing iscsid but not sure the > end-result of that. ( > https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/NdZPh33ed0oJ) > > Any help/direction here is much appreciated. > > Thanks, > Shailesh Mittal. > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
On 12/11, The Lee-Man wrote: > On Wednesday, November 7, 2018 at 1:09:32 PM UTC-8, Shailesh Mittal wrote: > > > > Thanks for the reply. Does that mean that we need to disable the iscsid > > running on the host or can they co-exist (one running on the host and other > > running in container)? > > > > Thanks, > > Shailesh. > > > > On Monday, October 29, 2018 at 10:57:06 AM UTC-7, The Lee-Man wrote: > >> > >> On Monday, October 29, 2018 at 10:40:07 AM UTC-7, dat...@gmail.com wrote: > >>> > >>> Thanks for the reply. We are facing issues when we run iscsiadm in the > >>> container and iscsid on the host. At that time, iscsiadm can't reach to > >>> iscsid at all and all iscsiadm commands fail. > >>> > >>> If we run iscsiadm and iscsid in the same container, it works but we > >>> don't know if this is how it is designed to run. So few specific > >>> questions; > >>> > >>> > I _believe_ they are separated, using different network namespaces, thanks > to some changes from Chris, but I can't seem to find them at the moment. > @cleech ?? > The namespace patches were proposed last year [1], and it's worth noticing Chris' note: The iSCSI transport objects are filtered, but not the SCSI or block layer devices. So while iSCSI hosts and sessions become limited to a network namespace, any attached devices remain visible system wide. [1]: https://groups.google.com/d/topic/open-iscsi/cZxHpzqT3K8/discussion > > 1. If we run iscsid in container, do we need to shut the the iscsid that > >>> is running on host? > >>> 2. iscsid running in the container, requires kernel module iscsi_tcp to > >>> be part of the container image. Is this ok? > >>> 3. What is the standard topology for dealing with iscsi from > >>> containerized environments? > >>> > >>> Appreciate your help here. > >>> > >>> Thanks, > >>> Shailesh. > >>> > >>> > >>> You need to run either "iscsid and iscsiadm" or "iscsistart" in each > >> container. The "iscsistart" command is meant to be used as a replacement > >> for the iscsid/iscsiadm pair at startup time. > >> > >> Yes, using iscsi_tcp (the iscsi transport) is required. I guess that > >> means it's ok. > >> > >> I have no idea about what is standard in a containerized environment for > >> topology. Generally, iscsi doesn't use any directory service (since people > >> don't like iSNS). > >> > > > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to open-iscsi+unsubscr...@googlegroups.com. > To post to this group, send email to open-iscsi@googlegroups.com. > Visit this group at https://groups.google.com/group/open-iscsi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
On Wednesday, November 7, 2018 at 1:09:32 PM UTC-8, Shailesh Mittal wrote: > > Thanks for the reply. Does that mean that we need to disable the iscsid > running on the host or can they co-exist (one running on the host and other > running in container)? > > Thanks, > Shailesh. > > On Monday, October 29, 2018 at 10:57:06 AM UTC-7, The Lee-Man wrote: >> >> On Monday, October 29, 2018 at 10:40:07 AM UTC-7, dat...@gmail.com wrote: >>> >>> Thanks for the reply. We are facing issues when we run iscsiadm in the >>> container and iscsid on the host. At that time, iscsiadm can't reach to >>> iscsid at all and all iscsiadm commands fail. >>> >>> If we run iscsiadm and iscsid in the same container, it works but we >>> don't know if this is how it is designed to run. So few specific questions; >>> >>> I _believe_ they are separated, using different network namespaces, thanks to some changes from Chris, but I can't seem to find them at the moment. @cleech ?? > 1. If we run iscsid in container, do we need to shut the the iscsid that >>> is running on host? >>> 2. iscsid running in the container, requires kernel module iscsi_tcp to >>> be part of the container image. Is this ok? >>> 3. What is the standard topology for dealing with iscsi from >>> containerized environments? >>> >>> Appreciate your help here. >>> >>> Thanks, >>> Shailesh. >>> >>> >>> You need to run either "iscsid and iscsiadm" or "iscsistart" in each >> container. The "iscsistart" command is meant to be used as a replacement >> for the iscsid/iscsiadm pair at startup time. >> >> Yes, using iscsi_tcp (the iscsi transport) is required. I guess that >> means it's ok. >> >> I have no idea about what is standard in a containerized environment for >> topology. Generally, iscsi doesn't use any directory service (since people >> don't like iSNS). >> > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
Thanks for the reply. Does that mean that we need to disable the iscsid running on the host or can they co-exist (one running on the host and other running in container)? Thanks, Shailesh. On Monday, October 29, 2018 at 10:57:06 AM UTC-7, The Lee-Man wrote: > > On Monday, October 29, 2018 at 10:40:07 AM UTC-7, dat...@gmail.com > wrote: >> >> Thanks for the reply. We are facing issues when we run iscsiadm in the >> container and iscsid on the host. At that time, iscsiadm can't reach to >> iscsid at all and all iscsiadm commands fail. >> >> If we run iscsiadm and iscsid in the same container, it works but we >> don't know if this is how it is designed to run. So few specific questions; >> >> 1. If we run iscsid in container, do we need to shut the the iscsid that >> is running on host? >> 2. iscsid running in the container, requires kernel module iscsi_tcp to >> be part of the container image. Is this ok? >> 3. What is the standard topology for dealing with iscsi from >> containerized environments? >> >> Appreciate your help here. >> >> Thanks, >> Shailesh. >> >> >> You need to run either "iscsid and iscsiadm" or "iscsistart" in each > container. The "iscsistart" command is meant to be used as a replacement > for the iscsid/iscsiadm pair at startup time. > > Yes, using iscsi_tcp (the iscsi transport) is required. I guess that means > it's ok. > > I have no idea about what is standard in a containerized environment for > topology. Generally, iscsi doesn't use any directory service (since people > don't like iSNS). > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
On Monday, October 29, 2018 at 10:40:07 AM UTC-7, dat@gmail.com wrote: > > Thanks for the reply. We are facing issues when we run iscsiadm in the > container and iscsid on the host. At that time, iscsiadm can't reach to > iscsid at all and all iscsiadm commands fail. > > If we run iscsiadm and iscsid in the same container, it works but we don't > know if this is how it is designed to run. So few specific questions; > > 1. If we run iscsid in container, do we need to shut the the iscsid that > is running on host? > 2. iscsid running in the container, requires kernel module iscsi_tcp to > be part of the container image. Is this ok? > 3. What is the standard topology for dealing with iscsi from containerized > environments? > > Appreciate your help here. > > Thanks, > Shailesh. > > > You need to run either "iscsid and iscsiadm" or "iscsistart" in each container. The "iscsistart" command is meant to be used as a replacement for the iscsid/iscsiadm pair at startup time. Yes, using iscsi_tcp (the iscsi transport) is required. I guess that means it's ok. I have no idea about what is standard in a containerized environment for topology. Generally, iscsi doesn't use any directory service (since people don't like iSNS). -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
Thanks for the reply. We are facing issues when we run iscsiadm in the container and iscsid on the host. At that time, iscsiadm can't reach to iscsid at all and all iscsiadm commands fail. If we run iscsiadm and iscsid in the same container, it works but we don't know if this is how it is designed to run. So few specific questions; 1. If we run iscsid in container, do we need to shut the the iscsid that is running on host? 2. iscsid running in the container, requires kernel module iscsi_tcp to be part of the container image. Is this ok? 3. What is the standard topology for dealing with iscsi from containerized environments? Appreciate your help here. Thanks, Shailesh. On Wednesday, October 24, 2018 at 1:28:11 PM UTC-7, The Lee-Man wrote: > > Sorry, I should have asked: what issues have you experienced with > containers? > > On Wednesday, October 24, 2018 at 1:27:43 PM UTC-7, The Lee-Man wrote: >> >> On Tuesday, October 23, 2018 at 9:03:01 AM UTC-7, Shailesh Mittal wrote: >>> >>> Hi there, >>> >>> I understand that it was the topic of discussion earlier. As containers >>> are getting used more and more to run applications, there are frameworks >>> like Kubernetes (and more) where the calls to talk to scsi storage devices >>> are being made through a container. >>> >>> Here, vendors are in flux as they need to execute iscsiadm commands to >>> connect their iscsi based storage to the application-containers. These >>> caller modules (responsible for connecting to the remote storage) are >>> running in the containers and thus have no choice but executing iscsiadm >>> commands from the containers itself. >>> >>> Is there a well understood way to implement this? I remember the thread >>> from Chris Leech talking about containerizing iscsid but not sure the >>> end-result of that. ( >>> https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/NdZPh33ed0oJ >>> ) >>> >>> Any help/direction here is much appreciated. >>> >>> Thanks, >>> Shailesh Mittal. >>> >> >> I have never messed with containers w/r/t iscsi, but I was under the >> impression Chris got this working. @Chris >> > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
Sorry, I should have asked: what issues have you experienced with containers? On Wednesday, October 24, 2018 at 1:27:43 PM UTC-7, The Lee-Man wrote: > > On Tuesday, October 23, 2018 at 9:03:01 AM UTC-7, Shailesh Mittal wrote: >> >> Hi there, >> >> I understand that it was the topic of discussion earlier. As containers >> are getting used more and more to run applications, there are frameworks >> like Kubernetes (and more) where the calls to talk to scsi storage devices >> are being made through a container. >> >> Here, vendors are in flux as they need to execute iscsiadm commands to >> connect their iscsi based storage to the application-containers. These >> caller modules (responsible for connecting to the remote storage) are >> running in the containers and thus have no choice but executing iscsiadm >> commands from the containers itself. >> >> Is there a well understood way to implement this? I remember the thread >> from Chris Leech talking about containerizing iscsid but not sure the >> end-result of that. ( >> https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/NdZPh33ed0oJ >> ) >> >> Any help/direction here is much appreciated. >> >> Thanks, >> Shailesh Mittal. >> > > I have never messed with containers w/r/t iscsi, but I was under the > impression Chris got this working. @Chris > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Re: Running iscsiadm in containers
On Tuesday, October 23, 2018 at 9:03:01 AM UTC-7, Shailesh Mittal wrote: > > Hi there, > > I understand that it was the topic of discussion earlier. As containers > are getting used more and more to run applications, there are frameworks > like Kubernetes (and more) where the calls to talk to scsi storage devices > are being made through a container. > > Here, vendors are in flux as they need to execute iscsiadm commands to > connect their iscsi based storage to the application-containers. These > caller modules (responsible for connecting to the remote storage) are > running in the containers and thus have no choice but executing iscsiadm > commands from the containers itself. > > Is there a well understood way to implement this? I remember the thread > from Chris Leech talking about containerizing iscsid but not sure the > end-result of that. ( > https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/NdZPh33ed0oJ) > > Any help/direction here is much appreciated. > > Thanks, > Shailesh Mittal. > I have never messed with containers w/r/t iscsi, but I was under the impression Chris got this working. @Chris -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
Running iscsiadm in containers
Hi there, I understand that it was the topic of discussion earlier. As containers are getting used more and more to run applications, there are frameworks like Kubernetes (and more) where the calls to talk to scsi storage devices are being made through a container. Here, vendors are in flux as they need to execute iscsiadm commands to connect their iscsi based storage to the application-containers. These caller modules (responsible for connecting to the remote storage) are running in the containers and thus have no choice but executing iscsiadm commands from the containers itself. Is there a well understood way to implement this? I remember the thread from Chris Leech talking about containerizing iscsid but not sure the end-result of that. (https://groups.google.com/forum/#!msg/open-iscsi/vWbi_LTMEeM/NdZPh33ed0oJ) Any help/direction here is much appreciated. Thanks, Shailesh Mittal. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
