<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 12, 2016 at 11:30 PM, Prasanna Kalever <span dir="ltr">&lt;<a href="mailto:pkalever@redhat.com" target="_blank">pkalever@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace;font-size:small"><div>Hi all, </div><div><br></div><div>This mail is open for discussion on gluster block store integration with heketi and its REST API interface design constraints.</div><div><br></div><div><br></div><div>                         ___ Volume Request ...</div><div>                        | </div><div>                        |                                  </div><div>PVC claim -&gt; Heketi ---&gt;|</div><div>                        |</div><div>                        |</div><div><div><div><div>                        |</div><div>                        |</div>                        |                            __ BlockCreate</div><div>                        |                           |</div>                        |                           |__ BlockInfo</div><div>                        |                           |</div></div><div>                        |___ Block Request (APIS)-&gt; |__ BlockResize</div><div>                                                    |</div><div>                                                    |__ BlockList</div><div style="font-size:12.8px"><div>                                                    |</div><div>                                                    |__ BlockDelete</div><div><br></div><div>Heketi will have block API and volume API, when user submit a Persistent volume claim, Kubernetes provisioner based on the storage class(from PVC) talks to heketi for storage, heketi intern calls block or volume API&#39;s based on request.</div></div></div></div></blockquote><div><br></div><div>This is probably wrong. It won&#39;t be Heketi calling block or volume APIs. It would be Kubernetes calling block or volume API *of* Heketi. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace;font-size:small"><div style="font-size:12.8px"><div><div><br></div><div>With my limited understanding, heketi currently creates clusters from provided nodes, creates volumes and handover them to the user.<br></div><div>For block related API&#39;s, it has to deal with files right ? <br></div><div><br></div><div>Here is how block API&#39;s look like in short-</div></div><div>Create: heketi has to create file in the volume and export it as a iscsi target device and hand it over to user.</div><div>Info: show block stores information across all the clusters, connection info, size etc.</div><div>resize: resize the file in the volume, refresh connections from initiator side</div><div>List: List the connections</div><div>Delete: logout the connections and delete the file in the gluster volume</div></div><div><br></div><div>Couple of questions:<br></div><div>1. Should Block API have sub API&#39;s such as FileCreate, FileList, FileResize, File delete and etc then get it used in Block API as they mostly deal with files.</div></div></div></blockquote><div> </div><div>IMO, Heketi should not expose any File related API. It should only have APIs to service request for block devices; how the block devices are created and modified is an implementation detail.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace;font-size:small"><div>2. How do we create the actual file in the volume, meaning using FUSE mount (which may involve an extra process running) or gfapi, again if gfapi should we go with c API&#39;s, python bindings or go bindings ?<span style="font-family:arial,sans-serif"> </span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace;font-size:small"><div>3. Should we get targetcli related (LUN exporting) setup done from heketi or do we seek help from gdeploy for this ?     </div></div></div></blockquote><div><br></div><div>I would prefer to either have it in Heketi or in Kubernetes. If the API in Heketi promises just the creation of block device, then the rest of the implementation should be in Kubernetes(the export part). If the API in Heketi promises create and export both, I would say Heketi should have the implementation within itself.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace;font-size:small"><div><br></div><div><br></div><div>Thoughts?<br></div><div><br></div><div>Note: nothing is fixed as put in this mail, its all just part of initial discussions.<br></div><div><br></div><div><br></div><div>Cheers,</div><div style="font-family:arial,sans-serif;font-size:12.8px"><div dir="ltr"><font face="monospace, monospace">--<br>Prasanna</font></div></div></div>
</div>
<br>______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br></blockquote></div><br></div></div>