<div dir="ltr">This looks great.  Thanks for the state machine diagram.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 9, 2017 at 11:06 AM, Raghavendra Talur <span dir="ltr">&lt;<a href="mailto:rtalur@redhat.com" target="_blank">rtalur@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">The PR now has the API changes requested.<div><br></div><div>Before review, here is the current state diagram</div><div><br></div><div><br></div><div><br></div><div><pre class="m_-8753482691564330645gmail-result--content--pre" style="margin-top:0px;margin-bottom:0px;padding:0px;overflow:hidden;line-height:1.2em;color:rgb(0,0,0)">+-----------------+     disable/offline  +------------------+ 
|                 |---------------------&gt;|                  | 
|                 |                      | Offline/Disabled | 
| Online/Enabled  |&lt;---------------------|                  | 
|                 |      enable/online   |                  | 
+-----------------+                      +------------------+ 
      ^                                          ^        |      
      |                                          |        |remove
      |                                   offline|        |      
      |add                                       |        |      
      |                                          |        |      
      |                                          |        |      
      |                                          |        v      
+------------------+                     +-------------------+
|                  |                     |                   |
| Deleted          |                     |   Failed/Removed  |
|                  |&lt;--------------------|                   |
|                  |          delete     |                   |
+------------------+                     +-------------------+</pre>​</div><div><br></div><div>The current implementation *requires* the device to be in &quot;Offline&quot; state before it can be removed. Some of the operations shown above aren&#39;t implemented yet.</div><div>Is this acceptable to all ? Are there any concerns or suggestions?</div><div><br></div><div>Thanks,</div><div>Raghavendra Talur</div><div><div class="h5"><div><br><br>On Thu, Mar 9, 2017 at 10:43 AM, Luis Pabon &lt;<a href="mailto:lpabon@chrysalix.org" target="_blank">lpabon@chrysalix.org</a>&gt; wrote:<br>&gt; Awesome.  I&#39;ll definitely review tomorrow.<br>&gt;<br>&gt; - Luis<br>&gt;<br>&gt; On Wed, Mar 8, 2017 at 7:59 PM, Raghavendra Talur &lt;<a href="mailto:rtalur@redhat.com" target="_blank">rtalur@redhat.com</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; Hi Luis,<br>&gt;&gt;<br>&gt;&gt; Please have a look at PR 710 which has changes that you requested.<br>&gt;&gt;<br>&gt;&gt; I have followed the revert of revert model for merge commits as<br>&gt;&gt; suggested by Linus in<br>&gt;&gt;<br>&gt;&gt; <a href="https://raw.githubusercontent.com/git/git/master/Documentation/howto/revert-a-faulty-merge.txt" target="_blank">https://raw.githubusercontent.<wbr>com/git/git/master/<wbr>Documentation/howto/revert-a-<wbr>faulty-merge.txt</a><br>&gt;&gt; for create a new PR.<br>&gt;&gt;<br>&gt;&gt; If you prefer it to be in any other way, please let us know.<br>&gt;&gt;<br>&gt;&gt; Also, these changes don&#39;t have API+Async changes and Refactored code<br>&gt;&gt; from allocator.<br>&gt;&gt; I will send them in a few hours. Meanwhile I wanted to put the simpler<br>&gt;&gt; stuff out for review.<br>&gt;&gt;<br>&gt;&gt; Thanks,<br>&gt;&gt; Raghavendra Talur<br>&gt;&gt;<br>&gt;&gt; On Wed, Feb 22, 2017 at 2:01 PM, Mohamed Ashiq Liyazudeen<br>&gt;&gt; &lt;<a href="mailto:mliyazud@redhat.com" target="_blank">mliyazud@redhat.com</a>&gt; wrote:<br>&gt;&gt; &gt; Hi,<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; New commit addresses all the comments. Please Review and comment on the<br>&gt;&gt; &gt; PR.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Prerequisites, Done:<br>&gt;&gt; &gt; We now added VolumeId in BrickEntry and VolumeInfo Executor call which<br>&gt;&gt; &gt; will<br>&gt;&gt; &gt; return Whole information of volume from gluster Itself(instead of saving<br>&gt;&gt; &gt; the<br>&gt;&gt; &gt; brick peer(brickset), we generate the brick peers from this<br>&gt;&gt; &gt; information).<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; How does this work:<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; For a Device to be remove.<br>&gt;&gt; &gt; First If the Device is Empty then Return ok to remove.<br>&gt;&gt; &gt; Else<br>&gt;&gt; &gt; Get the bricklist for bricks in device to be removed and its appropriate<br>&gt;&gt; &gt; volumeEntrylist for bricks.<br>&gt;&gt; &gt; Call Replace brick for a volume with the brickId.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; In Replace Brick Logic:<br>&gt;&gt; &gt; 1)First we Find the BrickSet(a set in which brick belongs, For Example<br>&gt;&gt; &gt; in<br>&gt;&gt; &gt; Distribute-Replicate 2x3 [A(A1,A2,A3), B(B1,B2,B3)], B2 is on set B) in<br>&gt;&gt; &gt; which the brick to be replaced is present.<br>&gt;&gt; &gt; Reason to find this is we should not place the brick with another brick<br>&gt;&gt; &gt; of<br>&gt;&gt; &gt; same set(which will cause Quorum to be met if one node is down and also<br>&gt;&gt; &gt; not<br>&gt;&gt; &gt; a good design).<br>&gt;&gt; &gt; 2) Call the allocator to give out devices for the same cluster.<br>&gt;&gt; &gt; 3)Ignore the Device IF:<br>&gt;&gt; &gt; a)Same Device to be removed<br>&gt;&gt; &gt; b)Device belongs to same Node where one of the other bricks in Set is<br>&gt;&gt; &gt; present<br>&gt;&gt; &gt; 4) With above logic We can still use the logic of simpleAllocator ring<br>&gt;&gt; &gt; to<br>&gt;&gt; &gt; decide the brick placement with single Zone and Multiple zones.<br>&gt;&gt; &gt; 5) On Failure returns Err and In case of NoSpaceError, We Respond<br>&gt;&gt; &gt; Replacementnotfound.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Note:<br>&gt;&gt; &gt; Few basic tests added for New VolumeId for BrickEntry and all the<br>&gt;&gt; &gt; failure<br>&gt;&gt; &gt; based on executor.SimpleVolumeInfo change from executor.VolumeInfo has<br>&gt;&gt; &gt; been<br>&gt;&gt; &gt; fixed.<br>&gt;&gt; &gt; Kept Device Remove modular so that can be used for Node Remove.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; To Be Done:<br>&gt;&gt; &gt; Tests to be Added.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; [1] <a href="https://github.com/heketi/heketi/pull/676" target="_blank">https://github.com/heketi/<wbr>heketi/pull/676</a><br>&gt;&gt; &gt;<br>&gt;&gt; &gt; -- Ashiq,Talur<br>&gt;&gt; &gt; ______________________________<wbr>__<br>&gt;&gt; &gt; From: &quot;Luis Pabon&quot; &lt;<a href="mailto:lpabon@chrysalix.org" target="_blank">lpabon@chrysalix.org</a>&gt;<br>&gt;&gt; &gt; To: &quot;Mohamed Ashiq Liyazudeen&quot; &lt;<a href="mailto:mliyazud@redhat.com" target="_blank">mliyazud@redhat.com</a>&gt;<br>&gt;&gt; &gt; Cc: <a href="mailto:heketi-devel@gluster.org" target="_blank">heketi-devel@gluster.org</a><br>&gt;&gt; &gt; Sent: Friday, February 17, 2017 1:49:32 AM<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Subject: Re: [heketi-devel] Remove Device: Used to distribute all the<br>&gt;&gt; &gt; bricks<br>&gt;&gt; &gt; from device to other devices<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; FYI, unless by some miracle there is no way this feature will be in by<br>&gt;&gt; &gt; Sunday.  This feature is one of the hardest part of Heketi which is why<br>&gt;&gt; &gt; <a href="https://github.com/heketi/heketi/issues/161" target="_blank">https://github.com/heketi/<wbr>heketi/issues/161</a> has taken so long.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; The brick set is the heart of this change.  A brick set is how Heketi<br>&gt;&gt; &gt; sets<br>&gt;&gt; &gt; up the replicas in a ring.  For example: in a distributed replicated<br>&gt;&gt; &gt; 2x3,<br>&gt;&gt; &gt; brick A would need A1 and A2 as replicas.  Therefore, A,A1,A2 are a set.<br>&gt;&gt; &gt; Same applies for B,B1,B2.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Replacing a device which contains B1 (for example), would need a<br>&gt;&gt; &gt; replacement<br>&gt;&gt; &gt; brick which satisfies B and B2 for the set to be complete.  Same thing<br>&gt;&gt; &gt; applies for EC where it is A,A1...A(n).<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; This is a big change, which requires a good algorithm, execution, and<br>&gt;&gt; &gt; testing.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; - Luis<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; On Thu, Feb 16, 2017 at 2:25 PM, Mohamed Ashiq Liyazudeen<br>&gt;&gt; &gt; &lt;<a href="mailto:mliyazud@redhat.com" target="_blank">mliyazud@redhat.com</a>&gt; wrote:<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Hi Luis,<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; I agree on adding the VolumeId part to db for bricks. I didn&#39;t get what<br>&gt;&gt; &gt;&gt; you mean by brick peers?<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; I wanted to know better about the allocator behaviors based on number<br>&gt;&gt; &gt;&gt; of<br>&gt;&gt; &gt;&gt; zones. If you see our example topology file, It has 4 nodes with<br>&gt;&gt; &gt;&gt; multiple<br>&gt;&gt; &gt;&gt; devices but 2 nodes are associated to a zone. There are only two zones<br>&gt;&gt; &gt;&gt; now<br>&gt;&gt; &gt;&gt; and while creating replica three volume how is the allocator creates<br>&gt;&gt; &gt;&gt; ring of<br>&gt;&gt; &gt;&gt; devices? Mainly in this case we can not ignore both zones.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Also wanted to know in case of volume expand how are we approaching. I<br>&gt;&gt; &gt;&gt; thought it will be using something similar to give the state(where the<br>&gt;&gt; &gt;&gt; present brick are) of existing volume  to allocator and allocator will<br>&gt;&gt; &gt;&gt; give<br>&gt;&gt; &gt;&gt; back ring without those zones or nodes. But I think (correct me if I am<br>&gt;&gt; &gt;&gt; wrong) Volume is changed by adding appropriate bricks, In the sense<br>&gt;&gt; &gt;&gt; replica<br>&gt;&gt; &gt;&gt; 3(3x1) is added bricks and made distribute replica 3(3x2). I agree this<br>&gt;&gt; &gt;&gt; is<br>&gt;&gt; &gt;&gt; the way to go, just trying to understand allocator better.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; We need this feature to be in by Sunday. I will be working on it<br>&gt;&gt; &gt;&gt; mostly,<br>&gt;&gt; &gt;&gt; Will definitely mail but is there any place to chat with you in case of<br>&gt;&gt; &gt;&gt; doubts and quick answers?<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; Tomorrow as first thing will add the VolumeId and brick peers(not sure<br>&gt;&gt; &gt;&gt; what is it exactly).<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; --<br>&gt;&gt; &gt;&gt; Ashiq<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; ----- Original Message -----<br>&gt;&gt; &gt;&gt; From: &quot;Luis Pabon&quot; &lt;<a href="mailto:lpabon@chrysalix.org" target="_blank">lpabon@chrysalix.org</a>&gt;<br>&gt;&gt; &gt;&gt; To: &quot;Mohamed Ashiq Liyazudeen&quot; &lt;<a href="mailto:mliyazud@redhat.com" target="_blank">mliyazud@redhat.com</a>&gt;<br>&gt;&gt; &gt;&gt; Cc: <a href="mailto:heketi-devel@gluster.org" target="_blank">heketi-devel@gluster.org</a><br>&gt;&gt; &gt;&gt; Sent: Thursday, February 16, 2017 11:32:55 PM<br>&gt;&gt; &gt;&gt; Subject: Re: [heketi-devel] Remove Device: Used to distribute all the<br>&gt;&gt; &gt;&gt; bricks from device to other devices<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; After we agree on the algorithm, the first PR would be to add the<br>&gt;&gt; &gt;&gt; necessary<br>&gt;&gt; &gt;&gt; framework to the DB to support #676.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; - Luis<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; On Thu, Feb 16, 2017 at 1:00 PM, Luis Pabon &lt;<a href="mailto:lpabon@chrysalix.org" target="_blank">lpabon@chrysalix.org</a>&gt;<br>&gt;&gt; &gt;&gt; wrote:<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt; Great summary.  Yes, the next step should be to figure out how to<br>&gt;&gt; &gt;&gt; &gt; enhance<br>&gt;&gt; &gt;&gt; &gt; the ring to return a brick for another zone.  It could be as simple<br>&gt;&gt; &gt;&gt; &gt; as:<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt; If current bricks in set are in different zones:<br>&gt;&gt; &gt;&gt; &gt;     Get a ring<br>&gt;&gt; &gt;&gt; &gt;     Remove disks from the ring in zones already used<br>&gt;&gt; &gt;&gt; &gt;     Return devices until one is found with the appropriate size<br>&gt;&gt; &gt;&gt; &gt; else:<br>&gt;&gt; &gt;&gt; &gt;    Get a ring<br>&gt;&gt; &gt;&gt; &gt;    Return devices until one is found with the appropriate size<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt; Also, order of the disks may matter.  This part I am not sure of,<br>&gt;&gt; &gt;&gt; &gt; but,<br>&gt;&gt; &gt;&gt; &gt; we<br>&gt;&gt; &gt;&gt; &gt; may need to make sure of the order of the bricks were added to the<br>&gt;&gt; &gt;&gt; &gt; volume<br>&gt;&gt; &gt;&gt; &gt; during &#39;create&#39;.  This may be necessary to determine which of the<br>&gt;&gt; &gt;&gt; &gt; bricks<br>&gt;&gt; &gt;&gt; &gt; in<br>&gt;&gt; &gt;&gt; &gt; the brick set are in different zones.<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt; We may have to add a new DB entry in the Brick Entry.  For example:<br>&gt;&gt; &gt;&gt; &gt; Brick<br>&gt;&gt; &gt;&gt; &gt; peers, and Volume ID<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt; - Luis<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt; On Wed, Feb 15, 2017 at 2:17 PM, Mohamed Ashiq Liyazudeen &lt;<br>&gt;&gt; &gt;&gt; &gt; <a href="mailto:mliyazud@redhat.com" target="_blank">mliyazud@redhat.com</a>&gt; wrote:<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; Hi,<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; This mail talks about the PR[1]<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; Let me start off with what is planned to do in this.<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; We only support this feature for Replicate and Distribute Replicate<br>&gt;&gt; &gt;&gt; &gt;&gt; Volume.<br>&gt;&gt; &gt;&gt; &gt;&gt; Refer: <a href="https://gluster.readthedocs.io/en/latest/Administrator%20Gui" target="_blank">https://gluster.readthedocs.<wbr>io/en/latest/Administrator%<wbr>20Gui</a><br>&gt;&gt; &gt;&gt; &gt;&gt; de/Managing%20Volumes/#<wbr>replace-brick<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; Removes all the brick from the device and start these bricks on<br>&gt;&gt; &gt;&gt; &gt;&gt; other<br>&gt;&gt; &gt;&gt; &gt;&gt; devices based on allocator. Heal is triggered automatically for<br>&gt;&gt; &gt;&gt; &gt;&gt; replicate<br>&gt;&gt; &gt;&gt; &gt;&gt; volumes on replace brick. Allocate and create new brick to replace.<br>&gt;&gt; &gt;&gt; &gt;&gt; It<br>&gt;&gt; &gt;&gt; &gt;&gt; stops the brick to be replaced, If it is not already down(kill the<br>&gt;&gt; &gt;&gt; &gt;&gt; brick<br>&gt;&gt; &gt;&gt; &gt;&gt; process). Then gluster replace brick which will replace the brick<br>&gt;&gt; &gt;&gt; &gt;&gt; with<br>&gt;&gt; &gt;&gt; &gt;&gt; new<br>&gt;&gt; &gt;&gt; &gt;&gt; one and also starts the heals.<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; If other nodes does not have sufficient storage then this command<br>&gt;&gt; &gt;&gt; &gt;&gt; should<br>&gt;&gt; &gt;&gt; &gt;&gt; fail.<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; 1) If there are no bricks then tell user, It is clean to remove the<br>&gt;&gt; &gt;&gt; &gt;&gt; device.<br>&gt;&gt; &gt;&gt; &gt;&gt; 2) If there are bricks in the device, then find the volume they are<br>&gt;&gt; &gt;&gt; &gt;&gt; related to from the list of volumes. Brickentry does not have the<br>&gt;&gt; &gt;&gt; &gt;&gt; volume<br>&gt;&gt; &gt;&gt; &gt;&gt; name it is associated to.<br>&gt;&gt; &gt;&gt; &gt;&gt; 3) move the bricks to other devices by calling the allocator for the<br>&gt;&gt; &gt;&gt; &gt;&gt; devices.<br>&gt;&gt; &gt;&gt; &gt;&gt; 4) eliminate the device to be removed and all the nodes which are<br>&gt;&gt; &gt;&gt; &gt;&gt; associated the volume already.<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; We missed on the zone handling part. If there is a way to give the<br>&gt;&gt; &gt;&gt; &gt;&gt; already used zone and node for the volume to allocator. Then<br>&gt;&gt; &gt;&gt; &gt;&gt; allocator<br>&gt;&gt; &gt;&gt; &gt;&gt; can<br>&gt;&gt; &gt;&gt; &gt;&gt; return the devices which will be from different zone&#39;s node. I think<br>&gt;&gt; &gt;&gt; &gt;&gt; 2,3,4<br>&gt;&gt; &gt;&gt; &gt;&gt; will handle if there is only one zone. Let us know if there are any<br>&gt;&gt; &gt;&gt; &gt;&gt; other<br>&gt;&gt; &gt;&gt; &gt;&gt; risks or better ways to use allocator.<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; [1] <a href="https://github.com/heketi/heketi/pull/676" target="_blank">https://github.com/heketi/<wbr>heketi/pull/676</a><br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; --<br>&gt;&gt; &gt;&gt; &gt;&gt; Regards,<br>&gt;&gt; &gt;&gt; &gt;&gt; Mohamed Ashiq.L<br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;&gt; ______________________________<wbr>_________________<br>&gt;&gt; &gt;&gt; &gt;&gt; heketi-devel mailing list<br>&gt;&gt; &gt;&gt; &gt;&gt; <a href="mailto:heketi-devel@gluster.org" target="_blank">heketi-devel@gluster.org</a><br>&gt;&gt; &gt;&gt; &gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/heketi-devel" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/heketi-devel</a><br>&gt;&gt; &gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; --<br>&gt;&gt; &gt;&gt; Regards,<br>&gt;&gt; &gt;&gt; Mohamed Ashiq.L<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; ______________________________<wbr>_________________<br>&gt;&gt; &gt;&gt; heketi-devel mailing list<br>&gt;&gt; &gt;&gt; <a href="mailto:heketi-devel@gluster.org" target="_blank">heketi-devel@gluster.org</a><br>&gt;&gt; &gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/heketi-devel" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/heketi-devel</a><br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; --<br>&gt;&gt; &gt; Regards,<br>&gt;&gt; &gt; Mohamed Ashiq.L<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; ______________________________<wbr>_________________<br>&gt;&gt; &gt; heketi-devel mailing list<br>&gt;&gt; &gt; <a href="mailto:heketi-devel@gluster.org" target="_blank">heketi-devel@gluster.org</a><br>&gt;&gt; &gt; <a href="http://lists.gluster.org/mailman/listinfo/heketi-devel" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/heketi-devel</a><br>&gt;&gt; &gt;<br>&gt;&gt; ______________________________<wbr>_________________<br>&gt;&gt; heketi-devel mailing list<br>&gt;&gt; <a href="mailto:heketi-devel@gluster.org" target="_blank">heketi-devel@gluster.org</a><br>&gt;&gt; <a href="http://lists.gluster.org/mailman/listinfo/heketi-devel" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/heketi-devel</a><br>&gt;<br>&gt;<br><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
heketi-devel mailing list<br>
<a href="mailto:heketi-devel@gluster.org">heketi-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/heketi-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/heketi-devel</a><br>
<br></blockquote></div><br></div>