<div dir="ltr"><div>+ rhs-containers list</div><div><br></div><div>Also, some important requirements to figure out/think about are:</div><div><br></div>- How are you managing locking a block device against a container (or a host?)<div>- Will your implementation work with OpenShift volume security for block devices (FSGroups + Recursive chown, chmod and SELinux labeling)</div><div><br></div><div>If these aren't already figured out, would it be possible to create separate cards in your trello board so we can track the progress on the resolution of these two topics?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 13, 2016 at 11:06 AM, Luis Pabón <span dir="ltr"><<a href="mailto:lpabon@redhat.com" target="_blank">lpabon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Very good points. Thanks Prasanna for putting this together. I agree with<br>
your comments in that Heketi is the high level abstraction API and it should have<br>
an API similar of what is described by Prasanna.<br>
<br>
I definitely do not think any File Api should be available in Heketi,<br>
because that is an implementation of the Block API. The Heketi API should<br>
be similar to something like OpenStack Cinder.<br>
<br>
I think that the actual management of the Volumes used for Block storage<br>
and the files in them should be all managed by Heketi. How they are<br>
actually created is still to be determined, but we could have Heketi<br>
create them, or have helper programs do that.<br>
<br>
We also need to document the exact workflow to enable a file in<br>
a Gluster volume to be exposed as a block device. This will help<br>
determine where the creation of the file could take place.<br>
<br>
We can capture our decisions from these discussions in the<br>
following page:<br>
<br>
<a href="https://github.com/heketi/heketi/wiki/Proposed-Changes" rel="noreferrer" target="_blank">https://github.com/heketi/<wbr>heketi/wiki/Proposed-Changes</a><br>
<span class="HOEnZb"><font color="#888888"><br>
- Luis<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
----- Original Message -----<br>
From: "Humble Chirammal" <<a href="mailto:hchiramm@redhat.com">hchiramm@redhat.com</a>><br>
To: "Raghavendra Talur" <<a href="mailto:rtalur@redhat.com">rtalur@redhat.com</a>><br>
Cc: "Prasanna Kalever" <<a href="mailto:pkalever@redhat.com">pkalever@redhat.com</a>>, "gluster-devel" <<a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>>, "Stephen Watt" <<a href="mailto:swatt@redhat.com">swatt@redhat.com</a>>, "Luis Pabon" <<a href="mailto:lpabon@redhat.com">lpabon@redhat.com</a>>, "Michael Adam" <<a href="mailto:madam@redhat.com">madam@redhat.com</a>>, "Ramakrishna Yekulla" <<a href="mailto:rreddy@redhat.com">rreddy@redhat.com</a>>, "Mohamed Ashiq Liyazudeen" <<a href="mailto:mliyazud@redhat.com">mliyazud@redhat.com</a>><br>
Sent: Tuesday, September 13, 2016 2:23:39 AM<br>
Subject: Re: [Gluster-devel] [Heketi] Block store related API design discussion<br>
<br>
<br>
<br>
<br>
<br>
----- Original Message -----<br>
| From: "Raghavendra Talur" <<a href="mailto:rtalur@redhat.com">rtalur@redhat.com</a>><br>
| To: "Prasanna Kalever" <<a href="mailto:pkalever@redhat.com">pkalever@redhat.com</a>><br>
| Cc: "gluster-devel" <<a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>>, "Stephen Watt" <<a href="mailto:swatt@redhat.com">swatt@redhat.com</a>>, "Luis Pabon" <<a href="mailto:lpabon@redhat.com">lpabon@redhat.com</a>>,<br>
| "Michael Adam" <<a href="mailto:madam@redhat.com">madam@redhat.com</a>>, "Humble Chirammal" <<a href="mailto:hchiramm@redhat.com">hchiramm@redhat.com</a>>, "Ramakrishna Yekulla"<br>
| <<a href="mailto:rreddy@redhat.com">rreddy@redhat.com</a>>, "Mohamed Ashiq Liyazudeen" <<a href="mailto:mliyazud@redhat.com">mliyazud@redhat.com</a>><br>
| Sent: Tuesday, September 13, 2016 11:08:44 AM<br>
| Subject: Re: [Gluster-devel] [Heketi] Block store related API design discussion<br>
|<br>
| On Mon, Sep 12, 2016 at 11:30 PM, Prasanna Kalever <<a href="mailto:pkalever@redhat.com">pkalever@redhat.com</a>><br>
| wrote:<br>
|<br>
| > Hi all,<br>
| ><br>
| > This mail is open for discussion on gluster block store integration with<br>
| > heketi and its REST API interface design constraints.<br>
| ><br>
| ><br>
| > ___ Volume Request ...<br>
| > |<br>
| > |<br>
| > PVC claim -> Heketi --->|<br>
| > |<br>
| > |<br>
| > |<br>
| > |<br>
| > | __ BlockCreate<br>
| > | |<br>
| > | |__ BlockInfo<br>
| > | |<br>
| > |___ Block Request (APIS)-> |__ BlockResize<br>
| > |<br>
| > |__ BlockList<br>
| > |<br>
| > |__ BlockDelete<br>
| ><br>
| > Heketi will have block API and volume API, when user submit a Persistent<br>
| > volume claim, Kubernetes provisioner based on the storage class(from PVC)<br>
| > talks to heketi for storage, heketi intern calls block or volume API's<br>
| > based on request.<br>
| ><br>
|<br>
| This is probably wrong. It won't be Heketi calling block or volume APIs. It<br>
| would be Kubernetes calling block or volume API *of* Heketi.<br>
|<br>
|<br>
| > With my limited understanding, heketi currently creates clusters from<br>
| > provided nodes, creates volumes and handover them to the user.<br>
| > For block related API's, it has to deal with files right ?<br>
| ><br>
| > Here is how block API's look like in short-<br>
| > Create: heketi has to create file in the volume and export it as a iscsi<br>
| > target device and hand it over to user.<br>
| > Info: show block stores information across all the clusters, connection<br>
| > info, size etc.<br>
| > resize: resize the file in the volume, refresh connections from initiator<br>
| > side<br>
| > List: List the connections<br>
| > Delete: logout the connections and delete the file in the gluster volume<br>
| ><br>
| > Couple of questions:<br>
| > 1. Should Block API have sub API's such as FileCreate, FileList,<br>
| > FileResize, File delete and etc then get it used in Block API as they<br>
| > mostly deal with files.<br>
| ><br>
|<br>
| IMO, Heketi should not expose any File related API. It should only have<br>
| APIs to service request for block devices; how the block devices are<br>
| created and modified is an implementation detail.<br>
|<br>
|<br>
| > 2. How do we create the actual file in the volume, meaning using FUSE<br>
| > mount (which may involve an extra process running) or gfapi, again if gfapi<br>
| > should we go with c API's, python bindings or go bindings ?<br>
| ><br>
| 3. Should we get targetcli related (LUN exporting) setup done from heketi<br>
| > or do we seek help from gdeploy for this ?<br>
| ><br>
|<br>
| I would prefer to either have it in Heketi or in Kubernetes. If the API in<br>
| Heketi promises just the creation of block device, then the rest of the<br>
| implementation should be in Kubernetes(the export part). If the API in<br>
| Heketi promises create and export both, I would say Heketi should have the<br>
| implementation within itself.<br>
|<br>
|<br>
<br>
IMO, we should not think about how the clients ( ex: k8s) use it, because there may be different clients.<br>
We should concentrate mainly on 'in/out' of block API in Heketi. Regardless of which client, the API should act the same way.<br>
<br>
--Humble<br>
</div></div></blockquote></div><br></div>