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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
