From shtripat at redhat.com Fri Nov 8 01:37:37 2013 Content-Type: multipart/mixed; boundary="===============2669700212703000856==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Fri, 08 Nov 2013 12:07:30 +0530 Message-ID: <527C86AA.7010904@redhat.com> In-Reply-To: 527C7DDF.2050308@redhat.com --===============2669700212703000856== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------010703000301070404040104 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi All, There is a DELETE action defined at collection level for Gluster Bricks = with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to = remove migrated bricks we introduced a DELETE action [1] which accepts a = boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens = without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant = for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action = with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible = scenarios with below input structure - / //// // true/false// // // // // // //brick1-name// // brick2-name// // // // // /// BUT after these change backward compatibility is broken and the old api = does not work. If we try invoking old DELETE with bricks as input parameter as below, = it still invokes the new api and gives an error saying "Invalid parameter". / // // / Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level = (//api/clusters//glustervolumes//bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu --------------010703000301070404040104 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi All,

There is a DELETE action defined at collection level for Gluster Bricks with signature -

@DELETE
public Response remove= (GlusterBricks<= /span> bricks);

Recently we had needed a commit action to remove migrated bricks.
After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce.
If the parameter is set to true, forced deletion of bricks happens without any data migration.
And if the parameter is not set or set to false, the deletion is meant for a brick on which migration has already taken place.

To achieve the above functionality we introduced another DELETE action with new signature as below and <= span class=3D"pun">also marked the first action as deprecated -

@DELETE
public Response remove(Action action= );

The problem arises now as the new api works fine for all possible scenarios with below input structure -

<action>
    <force>true/false</force>=
    <bricks>
        <brick><= i>
           = <name>brick1-name</name>
&n= bsp;           <name>brick2-= name</name>
        </brick>= ;
    </bricks>
</action>

BUT after these change backward compatibility is broken and the old api does not work.
If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "Invalid parameter".

<bricks>
    <brick id=3D"brick1-id"/>
=    = ; <brick id=3D"brick2-id"/>=
</bricks>

Kindly suggest a solution around the same.

PS: Both the actions are defined at collection level (/api/clusters/<cluster-id>/glustervo= lumes/<volume-id>/bricks)

[1]: http://gerrit.ovirt= .org/#/c/21043/

Thanks and Regards,
Shubhendu

--------------010703000301070404040104-- --===============2669700212703000856== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wMTA3MDMwMDAzMDEwNzA0MDQwNDAxMDQKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGkgQWxsLAoKVGhlcmUgaXMgYSBERUxFVEUgYWN0aW9uIGRlZmluZWQgYXQgY29sbGVj dGlvbiBsZXZlbCBmb3IgR2x1c3RlciBCcmlja3MgCndpdGggc2lnbmF0dXJlIC0KCi9AREVMRVRF CnB1YmxpYy8vLy9SZXNwb25zZS8vcmVtb3ZlLy8oLy9HbHVzdGVyQnJpY2tzLy9icmlja3MvLyk7 LwoKUmVjZW50bHkgd2UgaGFkIG5lZWRlZCBhIGNvbW1pdCBhY3Rpb24gdG8gcmVtb3ZlIG1pZ3Jh dGVkIGJyaWNrcy4KQWZ0ZXIgbXVsdGlwbGUgcm91bmRzIG9mIGRpc2N1c3Npb24gb24gaW50cm9k dWNpbmcgYSBjb21taXQgYWN0aW9uIHRvIApyZW1vdmUgbWlncmF0ZWQgYnJpY2tzIHdlIGludHJv ZHVjZWQgYSBERUxFVEUgYWN0aW9uIFsxXSB3aGljaCBhY2NlcHRzIGEgCmJvb2xlYW4gcGFyYW1l dGVyIGlzRm9yY2UuCklmIHRoZSBwYXJhbWV0ZXIgaXMgc2V0IHRvIC90cnVlLywgZm9yY2VkIGRl bGV0aW9uIG9mIGJyaWNrcyBoYXBwZW5zIAp3aXRob3V0IGFueSBkYXRhIG1pZ3JhdGlvbi4KQW5k IGlmIHRoZSBwYXJhbWV0ZXIgaXMgbm90IHNldCBvciBzZXQgdG8gL2ZhbHNlLC8gdGhlIGRlbGV0 aW9uIGlzIG1lYW50IApmb3IgYSBicmljayBvbiB3aGljaCBtaWdyYXRpb24gaGFzIGFscmVhZHkg dGFrZW4gcGxhY2UuCgpUbyBhY2hpZXZlIHRoZSBhYm92ZSBmdW5jdGlvbmFsaXR5IHdlIGludHJv ZHVjZWQgYW5vdGhlciBERUxFVEUgYWN0aW9uIAp3aXRoIG5ldyBzaWduYXR1cmUgYXMgYmVsb3cg YW5kIGFsc28gbWFya2VkIHRoZSBmaXJzdCBhY3Rpb24gYXMgZGVwcmVjYXRlZCAtCgovQERFTEVU RQpwdWJsaWMvLy8vUmVzcG9uc2UvL3JlbW92ZS8vKC8vQWN0aW9uLy9hY3Rpb24vLyk7LwoKVGhl IHByb2JsZW0gYXJpc2VzIG5vdyBhcyB0aGUgbmV3IGFwaSB3b3JrcyBmaW5lIGZvciBhbGwgcG9z c2libGUgCnNjZW5hcmlvcyB3aXRoIGJlbG93IGlucHV0IHN0cnVjdHVyZSAtCi8KLy88YWN0aW9u Pi8vCi8vICAgIDxmb3JjZT50cnVlL2ZhbHNlPC9mb3JjZT4vLwovLyAgICA8YnJpY2tzPi8vCi8v ICAgICAgICA8YnJpY2s+Ly8KLy8gICAgICAgICAgICA8bmFtZT4vL2JyaWNrMS1uYW1lPC9uYW1l Pi8vCi8vICAgICAgICA8bmFtZT5icmljazItbmFtZTwvbmFtZT4vLwovLyAgICAgICAgPC9icmlj az4vLwovLyAgICA8L2JyaWNrcz4vLwovLzwvYWN0aW9uPi8KCkJVVCBhZnRlciB0aGVzZSBjaGFu Z2UgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyBicm9rZW4gYW5kIHRoZSBvbGQgYXBpIApkb2Vz IG5vdCB3b3JrLgpJZiB3ZSB0cnkgaW52b2tpbmcgb2xkIERFTEVURSB3aXRoIGJyaWNrcyBhcyBp bnB1dCBwYXJhbWV0ZXIgYXMgYmVsb3csIAppdCBzdGlsbCBpbnZva2VzIHRoZSBuZXcgYXBpIGFu ZCBnaXZlcyBhbiBlcnJvciBzYXlpbmcgIkludmFsaWQgcGFyYW1ldGVyIi4KLwovLzxicmlja3M+ CiAgICAgPGJyaWNrIGlkPSJicmljazEtaWQiLz4KLy8gICAgPGJyaWNrIGlkPSJicmljazItaWQi Lz4KPC9icmlja3M+LwoKS2luZGx5IHN1Z2dlc3QgYSBzb2x1dGlvbiBhcm91bmQgdGhlIHNhbWUu CgoqUFM6KiBCb3RoIHRoZSBhY3Rpb25zIGFyZSBkZWZpbmVkIGF0IGNvbGxlY3Rpb24gbGV2ZWwg CigvL2FwaS9jbHVzdGVycy88Y2x1c3Rlci1pZD4vZ2x1c3RlcnZvbHVtZXMvPHZvbHVtZS1pZD4v YnJpY2tzLykKClsxXTogaHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzIxMDQzLwoKVGhhbmtz IGFuZCBSZWdhcmRzLApTaHViaGVuZHUKCgoKCgotLS0tLS0tLS0tLS0tLTAxMDcwMzAwMDMwMTA3 MDQwNDA0MDEwNApDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xCkNv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKCjxodG1sPgogIDxoZWFkPgoKICAgIDxtZXRh IGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlT Ty04ODU5LTEiPgogIDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAw MDAwIj4KICAgIEhpIEFsbCw8YnI+CiAgICA8ZGl2IGNsYXNzPSJtb3otZm9yd2FyZC1jb250YWlu ZXIiPiA8YnI+CiAgICAgIFRoZXJlIGlzIGEgREVMRVRFIGFjdGlvbiBkZWZpbmVkIGF0IGNvbGxl Y3Rpb24gbGV2ZWwgZm9yIEdsdXN0ZXIKICAgICAgQnJpY2tzIHdpdGggc2lnbmF0dXJlIC08YnI+ CiAgICAgIDxicj4KICAgICAgPGZvbnQgY29sb3I9IiMzMzMzZmYiPjxpPjxzcGFuIGNsYXNzPSJr d2QiPkBERUxFVEU8YnI+CiAgICAgICAgICAgIHB1YmxpYzwvc3Bhbj48L2k+PGk+PHNwYW4gY2xh c3M9InBsbiI+IDwvc3Bhbj48L2k+PGk+PHNwYW4KICAgICAgICAgICAgY2xhc3M9InR5cCI+UmVz cG9uc2U8L3NwYW4+PC9pPjxpPjxzcGFuIGNsYXNzPSJwbG4iPiByZW1vdmU8L3NwYW4+PC9pPjxp PjxzcGFuCiAgICAgICAgICAgIGNsYXNzPSJwdW4iPig8L3NwYW4+PC9pPjxpPjxzcGFuIGNsYXNz PSJ0eXAiPkdsdXN0ZXJCcmlja3M8L3NwYW4+PC9pPjxpPjxzcGFuCiAgICAgICAgICAgIGNsYXNz PSJwbG4iPiBicmlja3M8L3NwYW4+PC9pPjwvZm9udD48c3BhbiBjbGFzcz0icHVuIj48Zm9udAog ICAgICAgICAgY29sb3I9IiMzMzMzZmYiPjxpPik7PC9pPjwvZm9udD48YnI+CiAgICAgICAgPGJy PgogICAgICAgIFJlY2VudGx5IHdlIGhhZCBuZWVkZWQgYSBjb21taXQgYWN0aW9uIHRvIHJlbW92 ZSBtaWdyYXRlZAogICAgICAgIGJyaWNrcy4gPGJyPgogICAgICAgIEFmdGVyIG11bHRpcGxlIHJv dW5kcyBvZiBkaXNjdXNzaW9uIG9uIGludHJvZHVjaW5nIGEgY29tbWl0CiAgICAgICAgYWN0aW9u IHRvIHJlbW92ZSBtaWdyYXRlZCBicmlja3Mgd2UgaW50cm9kdWNlZCBhIERFTEVURSBhY3Rpb24K ICAgICAgICBbMV0gd2hpY2ggYWNjZXB0cyBhIGJvb2xlYW4gcGFyYW1ldGVyIGlzRm9yY2UuPGJy PgogICAgICAgIElmIHRoZSBwYXJhbWV0ZXIgaXMgc2V0IHRvIDxpPnRydWU8L2k+LCBmb3JjZWQg ZGVsZXRpb24gb2YKICAgICAgICBicmlja3MgaGFwcGVucyB3aXRob3V0IGFueSBkYXRhIG1pZ3Jh dGlvbi48YnI+CiAgICAgICAgQW5kIGlmIHRoZSBwYXJhbWV0ZXIgaXMgbm90IHNldCBvciBzZXQg dG8gPGk+ZmFsc2UsPC9pPiB0aGUKICAgICAgICBkZWxldGlvbiBpcyBtZWFudCBmb3IgYSBicmlj ayBvbiB3aGljaCBtaWdyYXRpb24gaGFzIGFscmVhZHkKICAgICAgICB0YWtlbiBwbGFjZS48YnI+ CiAgICAgICAgPGJyPgogICAgICAgIFRvIGFjaGlldmUgdGhlIGFib3ZlIGZ1bmN0aW9uYWxpdHkg d2UgaW50cm9kdWNlZCBhbm90aGVyIERFTEVURQogICAgICAgIGFjdGlvbiB3aXRoIG5ldyBzaWdu YXR1cmUgYXMgYmVsb3cgYW5kIDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuIj48c3BhbgogICAgICAg ICAgY2xhc3M9InB1biI+PHNwYW4gY2xhc3M9InB1biI+YWxzbyBtYXJrZWQgdGhlIGZpcnN0IGFj dGlvbiBhcwogICAgICAgICAgICBkZXByZWNhdGVkPC9zcGFuPjwvc3Bhbj4gLTxicj4KICAgICAg ICA8YnI+CiAgICAgIDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuIj48Zm9udCBjb2xvcj0iIzMzMzNm ZiI+PGk+PHNwYW4KICAgICAgICAgICAgICBjbGFzcz0ia3dkIj5AREVMRVRFPGJyPgogICAgICAg ICAgICAgIHB1YmxpYzwvc3Bhbj48L2k+PGk+PHNwYW4gY2xhc3M9InBsbiI+IDwvc3Bhbj48L2k+ PGk+PHNwYW4KICAgICAgICAgICAgICBjbGFzcz0idHlwIj5SZXNwb25zZTwvc3Bhbj48L2k+PGk+ PHNwYW4gY2xhc3M9InBsbiI+CiAgICAgICAgICAgICAgcmVtb3ZlPC9zcGFuPjwvaT48aT48c3Bh biBjbGFzcz0icHVuIj4oPC9zcGFuPjwvaT48aT48c3BhbgogICAgICAgICAgICAgIGNsYXNzPSJ0 eXAiPkFjdGlvbjwvc3Bhbj48L2k+PGk+PHNwYW4gY2xhc3M9InBsbiI+IGFjdGlvbjwvc3Bhbj48 L2k+PC9mb250PjxzcGFuCiAgICAgICAgICBjbGFzcz0icHVuIj48Zm9udCBjb2xvcj0iIzMzMzNm ZiI+PGk+KTs8L2k+PC9mb250Pjxicj4KICAgICAgICAgIDxicj4KICAgICAgICAgIFRoZSBwcm9i bGVtIGFyaXNlcyBub3cgYXMgdGhlIG5ldyBhcGkgd29ya3MgZmluZSBmb3IgYWxsCiAgICAgICAg ICBwb3NzaWJsZSBzY2VuYXJpb3Mgd2l0aCBiZWxvdyBpbnB1dCBzdHJ1Y3R1cmUgLTxicj4KICAg ICAgICAgIDxmb250IGNvbG9yPSIjMzMzM2ZmIj48aT48YnI+CiAgICAgICAgICAgIDwvaT48aT4m bHQ7YWN0aW9uJmd0OzwvaT48aT48YnI+CiAgICAgICAgICAgIDwvaT48aT4mbmJzcDsmbmJzcDsm bmJzcDsgJmx0O2ZvcmNlJmd0O3RydWUvZmFsc2UmbHQ7L2ZvcmNlJmd0OzwvaT48aT48YnI+CiAg ICAgICAgICAgIDwvaT48aT4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2JyaWNrcyZndDs8L2k+PGk+ PGJyPgogICAgICAgICAgICA8L2k+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7YnJpY2smZ3Q7PC9pPjxpPjxicj4KICAgICAgICAgICAgPC9pPjxpPiZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtuYW1l Jmd0OzwvaT48aT5icmljazEtbmFtZSZsdDsvbmFtZSZndDs8L2k+PGk+PGJyPgogICAgICAgICAg ICA8L2k+PC9mb250Pjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9InB1biI+PHNwYW4gY2xhc3M9 InB1biI+PGZvbnQKICAgICAgICAgICAgY29sb3I9IiMzMzMzZmYiPjxpPjxzcGFuIGNsYXNzPSJw dW4iPjxzcGFuIGNsYXNzPSJwdW4iPiZuYnNwOyZuYnNwOyZuYnNwOwogICAgICAgICAgICAgICAg ICAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtuYW1lJmd0O2JyaWNr Mi1uYW1lJmx0Oy9uYW1lJmd0Ozwvc3Bhbj48L3NwYW4+PC9pPjxpPjxicj4KICAgICAgICAgICAg PC9pPjxpPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2Jy aWNrJmd0OzwvaT48aT48YnI+CiAgICAgICAgICAgIDwvaT48aT4mbmJzcDsmbmJzcDsmbmJzcDsg Jmx0Oy9icmlja3MmZ3Q7PC9pPjxpPjxicj4KICAgICAgICAgICAgPC9pPjxpPiZsdDsvYWN0aW9u Jmd0OzwvaT48L2ZvbnQ+PGJyPgogICAgICAgICAgPGJyPgogICAgICAgICAgQlVUIGFmdGVyIHRo ZXNlIGNoYW5nZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIGJyb2tlbiBhbmQKICAgICAgICAg IHRoZSBvbGQgYXBpIGRvZXMgbm90IHdvcmsuPGJyPgogICAgICAgICAgSWYgd2UgdHJ5IGludm9r aW5nIG9sZCBERUxFVEUgd2l0aCBicmlja3MgYXMgaW5wdXQgcGFyYW1ldGVyCiAgICAgICAgICBh cyBiZWxvdywgaXQgc3RpbGwgaW52b2tlcyB0aGUgbmV3IGFwaSBhbmQgZ2l2ZXMgYW4gZXJyb3IK ICAgICAgICAgIHNheWluZyAiPGZvbnQgY29sb3I9IiNmZjAwMDAiPkludmFsaWQgcGFyYW1ldGVy PC9mb250PiIuPGJyPgogICAgICAgICAgPGZvbnQgY29sb3I9IiMzMzMzZmYiPjxpPjxicj4KICAg ICAgICAgICAgPC9pPjwvZm9udD48L3NwYW4+PC9zcGFuPjxmb250IGNvbG9yPSIjMzMzM2ZmIj48 aT48c3BhbgogICAgICAgICAgICBjbGFzcz0icHVuIj48c3BhbiBjbGFzcz0icHVuIj48c3BhbiBj bGFzcz0icHVuIj48c3BhbgogICAgICAgICAgICAgICAgICBjbGFzcz0icHVuIj4mbHQ7YnJpY2tz Jmd0Ozxicj4KICAgICAgICAgICAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDticmljayBp ZD0iYnJpY2sxLWlkIi8mZ3Q7PGJyPgogICAgICAgICAgICAgICAgPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwvaT48L2ZvbnQ+PHNwYW4gY2xhc3M9InB1biI+PHNwYW4KICAgICAgICAgIGNs YXNzPSJwdW4iPjxmb250IGNvbG9yPSIjMzMzM2ZmIj48aT48c3BhbiBjbGFzcz0icHVuIj48c3Bh bgogICAgICAgICAgICAgICAgICBjbGFzcz0icHVuIj48c3BhbiBjbGFzcz0icHVuIj48c3BhbiBj bGFzcz0icHVuIj48c3BhbgogICAgICAgICAgICAgICAgICAgICAgICBjbGFzcz0icHVuIj48c3Bh biBjbGFzcz0icHVuIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2JyaWNrCiAgICAgICAgICAgICAg ICAgICAgICAgICAgaWQ9ImJyaWNrMi1pZCIvJmd0Ozwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvc3Bh bj48YnI+CiAgICAgICAgICAgICAgICAgICZsdDsvYnJpY2tzJmd0Ozwvc3Bhbj48L3NwYW4+PC9p PjwvZm9udD48YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgICBLaW5kbHkgc3VnZ2VzdCBhIHNv bHV0aW9uIGFyb3VuZCB0aGUgc2FtZS48YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgICA8Yj5Q Uzo8L2I+IEJvdGggdGhlIGFjdGlvbnMgYXJlIGRlZmluZWQgYXQgY29sbGVjdGlvbiBsZXZlbCAo PGZvbnQKICAgICAgICAgICAgY29sb3I9IiMzMzMzZmYiPjxpPi9hcGkvY2x1c3RlcnMvJmx0O2Ns dXN0ZXItaWQmZ3Q7L2dsdXN0ZXJ2b2x1bWVzLyZsdDt2b2x1bWUtaWQmZ3Q7L2JyaWNrczwvaT48 L2ZvbnQ+KTxicj4KICAgICAgICAgIDxicj4KICAgICAgICAgIFsxXTogPGEgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIgogICAgICAgICAgICBocmVmPSJodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8jL2Mv MjEwNDMvIj5odHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8jL2MvMjEwNDMvPC9hPjxicj4KICAgICAg ICAgIDxicj4KICAgICAgICAgIFRoYW5rcyBhbmQgUmVnYXJkcyw8YnI+CiAgICAgICAgICBTaHVi aGVuZHU8YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAgPC9zcGFuPjwv c3Bhbj4gPGJyPgogICAgPC9kaXY+CiAgICA8YnI+CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0t LS0tLS0tLTAxMDcwMzAwMDMwMTA3MDQwNDA0MDEwNC0tCg== --===============2669700212703000856==-- From shtripat at redhat.com Fri Nov 8 01:58:30 2013 Content-Type: multipart/mixed; boundary="===============5312201394906762651==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Fri, 08 Nov 2013 11:29:59 +0530 Message-ID: <527C7DDF.2050308@redhat.com> --===============5312201394906762651== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------050509030900000404030401 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi All, There is a DELETE action defined at collection level for Gluster Bricks = with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to = remove migrated bricks we introduced a DELETE action [1] which accepts a = boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens = without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant = for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action = with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible = scenarios with below input structure - / //// // true/false// // // // // // //brick1-name// // brick2-name// // // // // /// BUT after these change backward compatibility is broken and the old api = does not work. If we try invoking old DELETE with bricks as input parameter as below, = it still invokes the new api and gives an error saying "Invalid parameter". / // // / Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level = (//api/clusters//glustervolumes//bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu --------------050509030900000404030401 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi All,

There is a DELETE action defined at collection level for Gluster Bricks with signature -

@DELETE
public Response remove(GlusterBricks bricks);

Recently we had needed a commit action to remove migrated bricks.
After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce.
If the parameter is set to true, forced deletion of bricks happens without any data migration.
And if the parameter is not set or set to false, the deletion is meant for a brick on which migration has already taken place.

To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated -

@DELETE
public Response remove= (Action<= /i> action);

The problem arises now as the new api works fine for all possible scenarios with below input structure -

<action>
    <force>true/false</force>
    <bricks>
        <brick>=
            &= lt;name>brick1-name</name>
= &nbs= p;           <name>brick2-name</name>
        </brick><= /i>
    </bricks>
</action>

BUT after these change backward compatibility is broken and the old api does not work.
If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "Invalid parameter".

<bricks>
    <brick id=3D"brick1-id"/>
    = <brick id=3D"brick2-id"/> </bricks>

Kindly suggest a solution around the same.

PS: Both the actions are defined at collection level (/api/clusters/<cluster-id>/glustervolu= mes/<volume-id>/bricks)

[1]: http://gerrit.o= virt.org/#/c/21043/

Thanks and Regards,
Shubhendu


 --------------050509030900000404030401-- --===============5312201394906762651== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNTA1MDkwMzA5MDAwMDA0MDQwMzA0MDEKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGkgQWxsLAoKVGhlcmUgaXMgYSBERUxFVEUgYWN0aW9uIGRlZmluZWQgYXQgY29sbGVj dGlvbiBsZXZlbCBmb3IgR2x1c3RlciBCcmlja3MgCndpdGggc2lnbmF0dXJlIC0KCi9AREVMRVRF CnB1YmxpYy8vLy9SZXNwb25zZS8vcmVtb3ZlLy8oLy9HbHVzdGVyQnJpY2tzLy9icmlja3MvLyk7 LwoKUmVjZW50bHkgd2UgaGFkIG5lZWRlZCBhIGNvbW1pdCBhY3Rpb24gdG8gcmVtb3ZlIG1pZ3Jh dGVkIGJyaWNrcy4KQWZ0ZXIgbXVsdGlwbGUgcm91bmRzIG9mIGRpc2N1c3Npb24gb24gaW50cm9k dWNpbmcgYSBjb21taXQgYWN0aW9uIHRvIApyZW1vdmUgbWlncmF0ZWQgYnJpY2tzIHdlIGludHJv ZHVjZWQgYSBERUxFVEUgYWN0aW9uIFsxXSB3aGljaCBhY2NlcHRzIGEgCmJvb2xlYW4gcGFyYW1l dGVyIGlzRm9yY2UuCklmIHRoZSBwYXJhbWV0ZXIgaXMgc2V0IHRvIC90cnVlLywgZm9yY2VkIGRl bGV0aW9uIG9mIGJyaWNrcyBoYXBwZW5zIAp3aXRob3V0IGFueSBkYXRhIG1pZ3JhdGlvbi4KQW5k IGlmIHRoZSBwYXJhbWV0ZXIgaXMgbm90IHNldCBvciBzZXQgdG8gL2ZhbHNlLC8gdGhlIGRlbGV0 aW9uIGlzIG1lYW50IApmb3IgYSBicmljayBvbiB3aGljaCBtaWdyYXRpb24gaGFzIGFscmVhZHkg dGFrZW4gcGxhY2UuCgpUbyBhY2hpZXZlIHRoZSBhYm92ZSBmdW5jdGlvbmFsaXR5IHdlIGludHJv ZHVjZWQgYW5vdGhlciBERUxFVEUgYWN0aW9uIAp3aXRoIG5ldyBzaWduYXR1cmUgYXMgYmVsb3cg YW5kIGFsc28gbWFya2VkIHRoZSBmaXJzdCBhY3Rpb24gYXMgZGVwcmVjYXRlZCAtCgovQERFTEVU RQpwdWJsaWMvLy8vUmVzcG9uc2UvL3JlbW92ZS8vKC8vQWN0aW9uLy9hY3Rpb24vLyk7LwoKVGhl IHByb2JsZW0gYXJpc2VzIG5vdyBhcyB0aGUgbmV3IGFwaSB3b3JrcyBmaW5lIGZvciBhbGwgcG9z c2libGUgCnNjZW5hcmlvcyB3aXRoIGJlbG93IGlucHV0IHN0cnVjdHVyZSAtCi8KLy88YWN0aW9u Pi8vCi8vICAgIDxmb3JjZT50cnVlL2ZhbHNlPC9mb3JjZT4vLwovLyAgICA8YnJpY2tzPi8vCi8v ICAgICAgICA8YnJpY2s+Ly8KLy8gICAgICAgICAgICA8bmFtZT4vL2JyaWNrMS1uYW1lPC9uYW1l Pi8vCi8vICAgIDxuYW1lPmJyaWNrMi1uYW1lPC9uYW1lPi8vCi8vICAgICAgICA8L2JyaWNrPi8v Ci8vICAgIDwvYnJpY2tzPi8vCi8vPC9hY3Rpb24+LwoKQlVUIGFmdGVyIHRoZXNlIGNoYW5nZSBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIGJyb2tlbiBhbmQgdGhlIG9sZCBhcGkgCmRvZXMgbm90 IHdvcmsuCklmIHdlIHRyeSBpbnZva2luZyBvbGQgREVMRVRFIHdpdGggYnJpY2tzIGFzIGlucHV0 IHBhcmFtZXRlciBhcyBiZWxvdywgCml0IHN0aWxsIGludm9rZXMgdGhlIG5ldyBhcGkgYW5kIGdp dmVzIGFuIGVycm9yIHNheWluZyAiSW52YWxpZCBwYXJhbWV0ZXIiLgovCi8vPGJyaWNrcz4KICAg ICA8YnJpY2sgaWQ9ImJyaWNrMS1pZCIvPgovLyAgICA8YnJpY2sgaWQ9ImJyaWNrMi1pZCIvPgo8 L2JyaWNrcz4vCgpLaW5kbHkgc3VnZ2VzdCBhIHNvbHV0aW9uIGFyb3VuZCB0aGUgc2FtZS4KCipQ UzoqIEJvdGggdGhlIGFjdGlvbnMgYXJlIGRlZmluZWQgYXQgY29sbGVjdGlvbiBsZXZlbCAKKC8v YXBpL2NsdXN0ZXJzLzxjbHVzdGVyLWlkPi9nbHVzdGVydm9sdW1lcy88dm9sdW1lLWlkPi9icmlj a3MvKQoKWzFdOiBodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8jL2MvMjEwNDMvCgpUaGFua3MgYW5k IFJlZ2FyZHMsClNodWJoZW5kdQoKCgotLS0tLS0tLS0tLS0tLTA1MDUwOTAzMDkwMDAwMDQwNDAz MDQwMQpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xCkNvbnRlbnQt VHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKCjxodG1sPgogIDxoZWFkPgoKICAgIDxtZXRhIGh0dHAt ZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5 LTEiPgogIDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4K ICAgIEhpIEFsbCw8YnI+CiAgICA8YnI+CiAgICBUaGVyZSBpcyBhIERFTEVURSBhY3Rpb24gZGVm aW5lZCBhdCBjb2xsZWN0aW9uIGxldmVsIGZvciBHbHVzdGVyCiAgICBCcmlja3Mgd2l0aCBzaWdu YXR1cmUgLTxicj4KICAgIDxicj4KICAgIDxmb250IGNvbG9yPSIjMzMzM2ZmIj48aT48c3BhbiBj bGFzcz0ia3dkIj5AREVMRVRFPGJyPgogICAgICAgICAgcHVibGljPC9zcGFuPjwvaT48aT48c3Bh biBjbGFzcz0icGxuIj4gPC9zcGFuPjwvaT48aT48c3BhbgogICAgICAgICAgY2xhc3M9InR5cCI+ UmVzcG9uc2U8L3NwYW4+PC9pPjxpPjxzcGFuIGNsYXNzPSJwbG4iPiByZW1vdmU8L3NwYW4+PC9p PjxpPjxzcGFuCiAgICAgICAgICBjbGFzcz0icHVuIj4oPC9zcGFuPjwvaT48aT48c3BhbiBjbGFz cz0idHlwIj5HbHVzdGVyQnJpY2tzPC9zcGFuPjwvaT48aT48c3BhbgogICAgICAgICAgY2xhc3M9 InBsbiI+IGJyaWNrczwvc3Bhbj48L2k+PC9mb250PjxzcGFuIGNsYXNzPSJwdW4iPjxmb250CiAg ICAgICAgY29sb3I9IiMzMzMzZmYiPjxpPik7PC9pPjwvZm9udD48YnI+CiAgICAgIDxicj4KICAg ICAgUmVjZW50bHkgd2UgaGFkIG5lZWRlZCBhIGNvbW1pdCBhY3Rpb24gdG8gcmVtb3ZlIG1pZ3Jh dGVkIGJyaWNrcy4KICAgICAgPGJyPgogICAgICBBZnRlciBtdWx0aXBsZSByb3VuZHMgb2YgZGlz Y3Vzc2lvbiBvbiBpbnRyb2R1Y2luZyBhIGNvbW1pdCBhY3Rpb24KICAgICAgdG8gcmVtb3ZlIG1p Z3JhdGVkIGJyaWNrcyB3ZSBpbnRyb2R1Y2VkIGEgREVMRVRFIGFjdGlvbiBbMV0gd2hpY2gKICAg ICAgYWNjZXB0cyBhIGJvb2xlYW4gcGFyYW1ldGVyIGlzRm9yY2UuPGJyPgogICAgICBJZiB0aGUg cGFyYW1ldGVyIGlzIHNldCB0byA8aT50cnVlPC9pPiwgZm9yY2VkIGRlbGV0aW9uIG9mIGJyaWNr cwogICAgICBoYXBwZW5zIHdpdGhvdXQgYW55IGRhdGEgbWlncmF0aW9uLjxicj4KICAgICAgQW5k IGlmIHRoZSBwYXJhbWV0ZXIgaXMgbm90IHNldCBvciBzZXQgdG8gPGk+ZmFsc2UsPC9pPiB0aGUK ICAgICAgZGVsZXRpb24gaXMgbWVhbnQgZm9yIGEgYnJpY2sgb24gd2hpY2ggbWlncmF0aW9uIGhh cyBhbHJlYWR5IHRha2VuCiAgICAgIHBsYWNlLjxicj4KICAgICAgPGJyPgogICAgICBUbyBhY2hp ZXZlIHRoZSBhYm92ZSBmdW5jdGlvbmFsaXR5IHdlIGludHJvZHVjZWQgYW5vdGhlciBERUxFVEUK ICAgICAgYWN0aW9uIHdpdGggbmV3IHNpZ25hdHVyZSBhcyBiZWxvdyBhbmQgPC9zcGFuPjxzcGFu IGNsYXNzPSJwdW4iPjxzcGFuCiAgICAgICAgY2xhc3M9InB1biI+PHNwYW4gY2xhc3M9InB1biI+ YWxzbyBtYXJrZWQgdGhlIGZpcnN0IGFjdGlvbiBhcwogICAgICAgICAgZGVwcmVjYXRlZDwvc3Bh bj48L3NwYW4+IC08YnI+CiAgICAgIDxicj4KICAgIDwvc3Bhbj48c3BhbiBjbGFzcz0icHVuIj48 Zm9udCBjb2xvcj0iIzMzMzNmZiI+PGk+PHNwYW4gY2xhc3M9Imt3ZCI+QERFTEVURTxicj4KICAg ICAgICAgICAgcHVibGljPC9zcGFuPjwvaT48aT48c3BhbiBjbGFzcz0icGxuIj4gPC9zcGFuPjwv aT48aT48c3BhbgogICAgICAgICAgICBjbGFzcz0idHlwIj5SZXNwb25zZTwvc3Bhbj48L2k+PGk+ PHNwYW4gY2xhc3M9InBsbiI+IHJlbW92ZTwvc3Bhbj48L2k+PGk+PHNwYW4KICAgICAgICAgICAg Y2xhc3M9InB1biI+KDwvc3Bhbj48L2k+PGk+PHNwYW4gY2xhc3M9InR5cCI+QWN0aW9uPC9zcGFu PjwvaT48aT48c3BhbgogICAgICAgICAgICBjbGFzcz0icGxuIj4gYWN0aW9uPC9zcGFuPjwvaT48 L2ZvbnQ+PHNwYW4gY2xhc3M9InB1biI+PGZvbnQKICAgICAgICAgIGNvbG9yPSIjMzMzM2ZmIj48 aT4pOzwvaT48L2ZvbnQ+PGJyPgogICAgICAgIDxicj4KICAgICAgICBUaGUgcHJvYmxlbSBhcmlz ZXMgbm93IGFzIHRoZSBuZXcgYXBpIHdvcmtzIGZpbmUgZm9yIGFsbAogICAgICAgIHBvc3NpYmxl IHNjZW5hcmlvcyB3aXRoIGJlbG93IGlucHV0IHN0cnVjdHVyZSAtPGJyPgogICAgICAgIDxmb250 IGNvbG9yPSIjMzMzM2ZmIj48aT48YnI+CiAgICAgICAgICA8L2k+PGk+Jmx0O2FjdGlvbiZndDs8 L2k+PGk+PGJyPgogICAgICAgICAgPC9pPjxpPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7Zm9yY2Um Z3Q7dHJ1ZS9mYWxzZSZsdDsvZm9yY2UmZ3Q7PC9pPjxpPjxicj4KICAgICAgICAgIDwvaT48aT4m bmJzcDsmbmJzcDsmbmJzcDsgJmx0O2JyaWNrcyZndDs8L2k+PGk+PGJyPgogICAgICAgICAgPC9p PjxpPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2JyaWNrJmd0Ozwv aT48aT48YnI+CiAgICAgICAgICA8L2k+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O25hbWUmZ3Q7PC9pPjxpPmJyaWNrMS1uYW1l Jmx0Oy9uYW1lJmd0OzwvaT48aT48YnI+CiAgICAgICAgICA8L2k+PC9mb250Pjwvc3Bhbj48L3Nw YW4+PHNwYW4gY2xhc3M9InB1biI+PHNwYW4gY2xhc3M9InB1biI+PGZvbnQKICAgICAgICAgIGNv bG9yPSIjMzMzM2ZmIj48aT48c3BhbiBjbGFzcz0icHVuIj48c3BhbiBjbGFzcz0icHVuIj4mbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7CiAgICAgICAgICAgICAgICAmbmJzcDsm bmJzcDsmbmJzcDsgJmx0O25hbWUmZ3Q7YnJpY2syLW5hbWUmbHQ7L25hbWUmZ3Q7PC9zcGFuPjwv c3Bhbj48L2k+PGk+PGJyPgogICAgICAgICAgPC9pPjxpPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2JyaWNrJmd0OzwvaT48aT48YnI+CiAgICAgICAgICA8 L2k+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvYnJpY2tzJmd0OzwvaT48aT48YnI+CiAgICAg ICAgICA8L2k+PGk+Jmx0Oy9hY3Rpb24mZ3Q7PC9pPjwvZm9udD48YnI+CiAgICAgICAgPGJyPgog ICAgICAgIEJVVCBhZnRlciB0aGVzZSBjaGFuZ2UgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyBi cm9rZW4gYW5kIHRoZQogICAgICAgIG9sZCBhcGkgZG9lcyBub3Qgd29yay48YnI+CiAgICAgICAg SWYgd2UgdHJ5IGludm9raW5nIG9sZCBERUxFVEUgd2l0aCBicmlja3MgYXMgaW5wdXQgcGFyYW1l dGVyIGFzCiAgICAgICAgYmVsb3csIGl0IHN0aWxsIGludm9rZXMgdGhlIG5ldyBhcGkgYW5kIGdp dmVzIGFuIGVycm9yIHNheWluZyAiPGZvbnQKICAgICAgICAgIGNvbG9yPSIjZmYwMDAwIj5JbnZh bGlkIHBhcmFtZXRlcjwvZm9udD4iLjxicj4KICAgICAgICA8Zm9udCBjb2xvcj0iIzMzMzNmZiI+ PGk+PGJyPgogICAgICAgICAgPC9pPjwvZm9udD48L3NwYW4+PC9zcGFuPjxmb250IGNvbG9yPSIj MzMzM2ZmIj48aT48c3BhbgogICAgICAgICAgY2xhc3M9InB1biI+PHNwYW4gY2xhc3M9InB1biI+ PHNwYW4gY2xhc3M9InB1biI+PHNwYW4KICAgICAgICAgICAgICAgIGNsYXNzPSJwdW4iPiZsdDti cmlja3MmZ3Q7PGJyPgogICAgICAgICAgICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDticmlj ayBpZD0iYnJpY2sxLWlkIi8mZ3Q7PGJyPgogICAgICAgICAgICAgIDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L2k+PC9mb250PjxzcGFuIGNsYXNzPSJwdW4iPjxzcGFuCiAgICAgICAgY2xh c3M9InB1biI+PGZvbnQgY29sb3I9IiMzMzMzZmYiPjxpPjxzcGFuIGNsYXNzPSJwdW4iPjxzcGFu CiAgICAgICAgICAgICAgICBjbGFzcz0icHVuIj48c3BhbiBjbGFzcz0icHVuIj48c3BhbiBjbGFz cz0icHVuIj48c3BhbgogICAgICAgICAgICAgICAgICAgICAgY2xhc3M9InB1biI+PHNwYW4gY2xh c3M9InB1biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDticmljawogICAgICAgICAgICAgICAgICAg ICAgICBpZD0iYnJpY2syLWlkIi8mZ3Q7PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxicj4K ICAgICAgICAgICAgICAgICZsdDsvYnJpY2tzJmd0Ozwvc3Bhbj48L3NwYW4+PC9pPjwvZm9udD48 YnI+CiAgICAgICAgPGJyPgogICAgICAgIEtpbmRseSBzdWdnZXN0IGEgc29sdXRpb24gYXJvdW5k IHRoZSBzYW1lLjxicj4KICAgICAgICA8YnI+CiAgICAgICAgPGI+UFM6PC9iPiBCb3RoIHRoZSBh Y3Rpb25zIGFyZSBkZWZpbmVkIGF0IGNvbGxlY3Rpb24gbGV2ZWwgKDxmb250CiAgICAgICAgICBj b2xvcj0iIzMzMzNmZiI+PGk+L2FwaS9jbHVzdGVycy8mbHQ7Y2x1c3Rlci1pZCZndDsvZ2x1c3Rl cnZvbHVtZXMvJmx0O3ZvbHVtZS1pZCZndDsvYnJpY2tzPC9pPjwvZm9udD4pPGJyPgogICAgICAg IDxicj4KICAgICAgICBbMV06IDxhIGhyZWY9Imh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLyMvYy8y MTA0My8iPmh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLyMvYy8yMTA0My88L2E+PGJyPgogICAgICAg IDxicj4KICAgICAgICBUaGFua3MgYW5kIFJlZ2FyZHMsPGJyPgogICAgICAgIFNodWJoZW5kdTxi cj4KICAgICAgICA8YnI+CiAgICAgICAgPGJyPgogICAgICA8L3NwYW4+PC9zcGFuPgogIDwvYm9k eT4KPC9odG1sPgoKLS0tLS0tLS0tLS0tLS0wNTA1MDkwMzA5MDAwMDA0MDQwMzA0MDEtLQo= --===============5312201394906762651==-- From masayag at redhat.com Sun Nov 10 12:36:10 2013 Content-Type: multipart/mixed; boundary="===============7464113626245701125==" MIME-Version: 1.0 From: Moti Asayag To: devel at ovirt.org Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Sun, 10 Nov 2013 12:36:08 -0500 Message-ID: <25153947.26941766.1384104968045.JavaMail.root@redhat.com> In-Reply-To: 527C86AA.7010904@redhat.com --===============7464113626245701125== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Shubhendu Tripathi" > To: "engine-devel" , "Michael Pasternak" , oliel(a)redhat.com > Sent: Friday, November 8, 2013 8:37:30 AM > Subject: [Engine-devel] REST-API: Problem with additional DELETE action a= t collection level > = > Hi All, > = > There is a DELETE action defined at collection level for Gluster Bricks w= ith > signature - > = > @DELETE > public Response remove ( GlusterBricks bricks ); > = > Recently we had needed a commit action to remove migrated bricks. > After multiple rounds of discussion on introducing a commit action to rem= ove > migrated bricks we introduced a DELETE action [1] which accepts a boolean > parameter isForce. > If the parameter is set to true , forced deletion of bricks happens witho= ut > any data migration. > And if the parameter is not set or set to false, the deletion is meant fo= r a > brick on which migration has already taken place. > = > To achieve the above functionality we introduced another DELETE action wi= th > new signature as below and also marked the first action as deprecated - > = > @DELETE > public Response remove ( Action action ); > = > The problem arises now as the new api works fine for all possible scenari= os > with below input structure - > = > > true/false > > > brick1-name > brick2-name > > > > = > BUT after these change backward compatibility is broken and the old api d= oes > not work. > If we try invoking old DELETE with bricks as input parameter as below, it > still invokes the new api and gives an error saying " Invalid parameter ". > = Maybe I've missed it some where, but i wasn't able to find the new 'force' = parameter in the rsdl, and specifically not in optionalArguments list of: - name: /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks= |rel=3Ddelete and perhaps the correct approach will be to deprecate this signature and in= troduce a new one with the 'force' in the 'mandatoryArguments' section. > > > > > = > Kindly suggest a solution around the same. > = > PS: Both the actions are defined at collection level ( > /api/clusters//glustervolumes//bricks ) > = > [1]: http://gerrit.ovirt.org/#/c/21043/ > = > Thanks and Regards, > Shubhendu > = > = > = > = > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============7464113626245701125==-- From shtripat at redhat.com Mon Nov 11 00:00:47 2013 Content-Type: multipart/mixed; boundary="===============6284567269269216454==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Mon, 11 Nov 2013 10:30:31 +0530 Message-ID: <5280646F.2050903@redhat.com> In-Reply-To: 25153947.26941766.1384104968045.JavaMail.root@redhat.com --===============6284567269269216454== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/10/2013 11:06 PM, Moti Asayag wrote: > > ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: "engine-devel" , "Michael Pasternak" , oliel(a)redhat.com >> Sent: Friday, November 8, 2013 8:37:30 AM >> Subject: [Engine-devel] REST-API: Problem with additional DELETE action = at collection level >> >> Hi All, >> >> There is a DELETE action defined at collection level for Gluster Bricks = with >> signature - >> >> @DELETE >> public Response remove ( GlusterBricks bricks ); >> >> Recently we had needed a commit action to remove migrated bricks. >> After multiple rounds of discussion on introducing a commit action to re= move >> migrated bricks we introduced a DELETE action [1] which accepts a boolean >> parameter isForce. >> If the parameter is set to true , forced deletion of bricks happens with= out >> any data migration. >> And if the parameter is not set or set to false, the deletion is meant f= or a >> brick on which migration has already taken place. >> >> To achieve the above functionality we introduced another DELETE action w= ith >> new signature as below and also marked the first action as deprecated - >> >> @DELETE >> public Response remove ( Action action ); >> >> The problem arises now as the new api works fine for all possible scenar= ios >> with below input structure - >> >> >> true/false >> >> >> brick1-name >> brick2-name >> >> >> >> >> BUT after these change backward compatibility is broken and the old api = does >> not work. >> If we try invoking old DELETE with bricks as input parameter as below, it >> still invokes the new api and gives an error saying " Invalid parameter = ". >> > Maybe I've missed it some where, but i wasn't able to find the new 'force= ' parameter > in the rsdl, and specifically not in optionalArguments list of: > > - name: /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bric= ks|rel=3Ddelete > > and perhaps the correct approach will be to deprecate this signature and = introduce a new > one with the 'force' in the 'mandatoryArguments' section. Moti, I have introduced another methods remove of DELETE type which = takes Action as input. I pass list of bricks and force as parameter in the same Action. Also, I tried marking the old method deprecated and introduced the new = one BUT as mentioned above, after introduction of new DELETE with Action = parameter old one STOPS working. Is it OK to stop working for a method if its deprecated?? I don't feel = so. Please comment. > >> >> >> >> >> >> Kindly suggest a solution around the same. >> >> PS: Both the actions are defined at collection level ( >> /api/clusters//glustervolumes//bricks ) >> >> [1]: http://gerrit.ovirt.org/#/c/21043/ >> >> Thanks and Regards, >> Shubhendu >> >> >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> --===============6284567269269216454==-- From shtripat at redhat.com Mon Nov 11 05:00:42 2013 Content-Type: multipart/mixed; boundary="===============8312544508368346679==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Mon, 11 Nov 2013 15:30:34 +0530 Message-ID: <5280AAC2.6010805@redhat.com> In-Reply-To: 5280646F.2050903@redhat.com --===============8312544508368346679== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Self and Ori had a detailed discussion on the topic. Points discussed - 1. Ori mentioned that Michael and Ori did not mean to have a separate = DELETE action for the purpose of commit in previous discussions. 2. Ori tried to understand the intention behind the separate commit = command in gluster and suggested that ideally gluster should remember = that a migration of data is started on the set of bricks, and if there = is a delete fired on the same bricks it should perform a commit action = because commit is nothing but a delete action 3. Ori suggested that in an ideal situation APIs needed would be - start migrate - stop migrate - delete bricks - retain bricks 4. As suggested by Ori, the remove bricks action should internally = decide if there was a data migration, started on the set of bricks. If = so, it should effectively fire a commit for the set of bricks. And if = there was not occurrence of data migration it should behave like a = normal force remove action. Ori, please add your comments if I have missed out anything here. Sahina, request your comments on the same. Thanks and Regards, Shubhendu On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: > On 11/10/2013 11:06 PM, Moti Asayag wrote: >> >> ----- Original Message ----- >>> From: "Shubhendu Tripathi" >>> To: "engine-devel" , "Michael Pasternak" = >>> , oliel(a)redhat.com >>> Sent: Friday, November 8, 2013 8:37:30 AM >>> Subject: [Engine-devel] REST-API: Problem with additional DELETE = >>> action at collection level >>> >>> Hi All, >>> >>> There is a DELETE action defined at collection level for Gluster = >>> Bricks with >>> signature - >>> >>> @DELETE >>> public Response remove ( GlusterBricks bricks ); >>> >>> Recently we had needed a commit action to remove migrated bricks. >>> After multiple rounds of discussion on introducing a commit action = >>> to remove >>> migrated bricks we introduced a DELETE action [1] which accepts a = >>> boolean >>> parameter isForce. >>> If the parameter is set to true , forced deletion of bricks happens = >>> without >>> any data migration. >>> And if the parameter is not set or set to false, the deletion is = >>> meant for a >>> brick on which migration has already taken place. >>> >>> To achieve the above functionality we introduced another DELETE = >>> action with >>> new signature as below and also marked the first action as deprecated - >>> >>> @DELETE >>> public Response remove ( Action action ); >>> >>> The problem arises now as the new api works fine for all possible = >>> scenarios >>> with below input structure - >>> >>> >>> true/false >>> >>> >>> brick1-name >>> brick2-name >>> >>> >>> >>> >>> BUT after these change backward compatibility is broken and the old = >>> api does >>> not work. >>> If we try invoking old DELETE with bricks as input parameter as = >>> below, it >>> still invokes the new api and gives an error saying " Invalid = >>> parameter ". >>> >> Maybe I've missed it some where, but i wasn't able to find the new = >> 'force' parameter >> in the rsdl, and specifically not in optionalArguments list of: >> >> - name: = >> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel= =3Ddelete >> >> and perhaps the correct approach will be to deprecate this signature = >> and introduce a new >> one with the 'force' in the 'mandatoryArguments' section. > Moti, I have introduced another methods remove of DELETE type which = > takes Action as input. > I pass list of bricks and force as parameter in the same Action. > > Also, I tried marking the old method deprecated and introduced the new = > one BUT as mentioned above, after introduction of new DELETE with = > Action parameter old one STOPS working. > Is it OK to stop working for a method if its deprecated?? I don't feel = > so. Please comment. >> >>> >>> >>> >>> >>> >>> Kindly suggest a solution around the same. >>> >>> PS: Both the actions are defined at collection level ( >>> /api/clusters//glustervolumes//bricks ) >>> >>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>> >>> Thanks and Regards, >>> Shubhendu >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > --===============8312544508368346679==-- From oliel at redhat.com Mon Nov 11 05:38:47 2013 Content-Type: multipart/mixed; boundary="===============2060601200768758339==" MIME-Version: 1.0 From: Ori Liel To: devel at ovirt.org Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Mon, 11 Nov 2013 05:38:46 -0500 Message-ID: <463738104.27509428.1384166326211.JavaMail.root@redhat.com> In-Reply-To: 5280AAC2.6010805@redhat.com --===============2060601200768758339== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >----- Original Message ----- >From: "Shubhendu Tripathi" >To: oliel(a)redhat.com, "Michael Pasternak" , "Sahi= na Bose" >Cc: "Dusmant Pati" , "engine-devel" >Sent: Monday, November 11, 2013 12:00:34 PM >Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE actio= n at collection level > >Self and Ori had a detailed discussion on the topic. > >Points discussed - > >1. Ori mentioned that Michael and Ori did not mean to have a separate = >DELETE action for the purpose of commit in previous discussions. That's right - no need for a new delete signature; existing signatures are = enough. >2. Ori tried to understand the intention behind the separate commit = >command in gluster and suggested that ideally gluster should remember = >that a migration of data is started on the set of bricks, and if there = >is a delete fired on the same bricks it should perform a commit action = >because commit is nothing but a delete action >3. Ori suggested that in an ideal situation APIs needed would be > - start migrate > - stop migrate > - delete bricks > - retain bricks >4. As suggested by Ori, the remove bricks action should internally = >decide if there was a data migration, started on the set of bricks. If = >so, it should effectively fire a commit for the set of bricks. And if = >there was not occurrence of data migration it should behave like a = >normal force remove action. > >Ori, please add your comments if I have missed out anything here. I agree with what you wrote, let me sort of say it again in my words: = I don't like requiring two consecutive commands from the API user, to perfo= rm migrate. = If the user only does 'migrate', and doesn't do the second step, we are in = a state of = corruption. But Shubhendu explained to me that there's no way around this; = the = administrator *must* take a look and decide; it is simply not possible to m= ake this decision in advance. So I accepted this heavy-heartedly. = Then we were left with the decision of how to model this two step operation= . I tried to = look at it from the point of view of the user; what would be the simplest w= ay to 'tell him the story?' - If you want to migrate a brick, run 'migrate' on it. = - If you want to stop migration of the brick, run 'stopMigrate' on it. = - If you want to resume the migration of the brick, simply run 'migrate' on= it again. = After migration is done: - if you want to remove the brick, DELETE it (regular delete). = - if you want to keep using the brick, run 'reactivate' on it. = And that's the whole story. = The advantages are: = * In simple English, not bound to Gluster terms, the administrator has to d= ecide whether to = get rid of the brick, remove it, when migration is done. So what would be m= ore natural than = to delete it? It makes sense, and there's no need for a new 'action'. On th= e Gluster side, = if user tried to delete a brick which is undergoing migration - simply don'= t allow it. This = is something you have to do anyway; a user might try to delete a brick whic= h is undergoing migration and you have to stop him from doing so. So 0 extra work here. = * Instead of stopMigrate meaning two different things in two different cont= exts, we now = have stopMigration mean exactly what its name suggests: it stops the migrat= ion, and 'reactive' = mean exactly what it suggests - mark this brick as active again, allow it t= o be used. = > >Sahina, request your comments on the same. > >Thanks and Regards, >Shubhendu On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: > On 11/10/2013 11:06 PM, Moti Asayag wrote: >> >> ----- Original Message ----- >>> From: "Shubhendu Tripathi" >>> To: "engine-devel" , "Michael Pasternak" = >>> , oliel(a)redhat.com >>> Sent: Friday, November 8, 2013 8:37:30 AM >>> Subject: [Engine-devel] REST-API: Problem with additional DELETE = >>> action at collection level >>> >>> Hi All, >>> >>> There is a DELETE action defined at collection level for Gluster = >>> Bricks with >>> signature - >>> >>> @DELETE >>> public Response remove ( GlusterBricks bricks ); >>> >>> Recently we had needed a commit action to remove migrated bricks. >>> After multiple rounds of discussion on introducing a commit action = >>> to remove >>> migrated bricks we introduced a DELETE action [1] which accepts a = >>> boolean >>> parameter isForce. >>> If the parameter is set to true , forced deletion of bricks happens = >>> without >>> any data migration. >>> And if the parameter is not set or set to false, the deletion is = >>> meant for a >>> brick on which migration has already taken place. >>> >>> To achieve the above functionality we introduced another DELETE = >>> action with >>> new signature as below and also marked the first action as deprecated - >>> >>> @DELETE >>> public Response remove ( Action action ); >>> >>> The problem arises now as the new api works fine for all possible = >>> scenarios >>> with below input structure - >>> >>> >>> true/false >>> >>> >>> brick1-name >>> brick2-name >>> >>> >>> >>> >>> BUT after these change backward compatibility is broken and the old = >>> api does >>> not work. >>> If we try invoking old DELETE with bricks as input parameter as = >>> below, it >>> still invokes the new api and gives an error saying " Invalid = >>> parameter ". >>> >> Maybe I've missed it some where, but i wasn't able to find the new = >> 'force' parameter >> in the rsdl, and specifically not in optionalArguments list of: >> >> - name: = >> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel= =3Ddelete >> >> and perhaps the correct approach will be to deprecate this signature = >> and introduce a new >> one with the 'force' in the 'mandatoryArguments' section. > Moti, I have introduced another methods remove of DELETE type which = > takes Action as input. > I pass list of bricks and force as parameter in the same Action. > > Also, I tried marking the old method deprecated and introduced the new = > one BUT as mentioned above, after introduction of new DELETE with = > Action parameter old one STOPS working. > Is it OK to stop working for a method if its deprecated?? I don't feel = > so. Please comment. >> >>> >>> >>> >>> >>> >>> Kindly suggest a solution around the same. >>> >>> PS: Both the actions are defined at collection level ( >>> /api/clusters//glustervolumes//bricks ) >>> >>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>> >>> Thanks and Regards, >>> Shubhendu >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > --===============2060601200768758339==-- From shtripat at redhat.com Mon Nov 11 06:03:58 2013 Content-Type: multipart/mixed; boundary="===============1838073393278435514==" MIME-Version: 1.0 From: Shubhendu Tripathi To: devel at ovirt.org Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Mon, 11 Nov 2013 16:33:53 +0530 Message-ID: <5280B999.6000605@redhat.com> In-Reply-To: 463738104.27509428.1384166326211.JavaMail.root@redhat.com --===============1838073393278435514== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 11/11/2013 04:08 PM, Ori Liel wrote: >> ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: oliel(a)redhat.com, "Michael Pasternak" , "Sa= hina Bose" >> Cc: "Dusmant Pati" , "engine-devel" >> Sent: Monday, November 11, 2013 12:00:34 PM >> Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE act= ion at collection level >> >> Self and Ori had a detailed discussion on the topic. >> >> Points discussed - >> >> 1. Ori mentioned that Michael and Ori did not mean to have a separate >> DELETE action for the purpose of commit in previous discussions. > That's right - no need for a new delete signature; existing signatures ar= e enough. > >> 2. Ori tried to understand the intention behind the separate commit >> command in gluster and suggested that ideally gluster should remember >> that a migration of data is started on the set of bricks, and if there >> is a delete fired on the same bricks it should perform a commit action >> because commit is nothing but a delete action >> 3. Ori suggested that in an ideal situation APIs needed would be >> - start migrate >> - stop migrate >> - delete bricks >> - retain bricks >> 4. As suggested by Ori, the remove bricks action should internally >> decide if there was a data migration, started on the set of bricks. If >> so, it should effectively fire a commit for the set of bricks. And if >> there was not occurrence of data migration it should behave like a >> normal force remove action. >> >> Ori, please add your comments if I have missed out anything here. > I agree with what you wrote, let me sort of say it again in my words: > > I don't like requiring two consecutive commands from the API user, to per= form migrate. > If the user only does 'migrate', and doesn't do the second step, we are i= n a state of > corruption. But Shubhendu explained to me that there's no way around this= ; the > administrator *must* take a look and decide; it is simply not possible to= make this > decision in advance. So I accepted this heavy-heartedly. > > Then we were left with the decision of how to model this two step operati= on. I tried to > look at it from the point of view of the user; what would be the simplest= way to 'tell him > the story?' > > - If you want to migrate a brick, run 'migrate' on it. > - If you want to stop migration of the brick, run 'stopMigrate' on it. > - If you want to resume the migration of the brick, simply run 'migrate' = on it again. > After migration is done: > - if you want to remove the brick, DELETE it (regular delete). > - if you want to keep using the brick, run 'reactivate' on it. > > And that's the whole story. > > The advantages are: > > * In simple English, not bound to Gluster terms, the administrator has to= decide whether to > get rid of the brick, remove it, when migration is done. So what would be= more natural than > to delete it? It makes sense, and there's no need for a new 'action'. On = the Gluster side, > if user tried to delete a brick which is undergoing migration - simply do= n't allow it. This > is something you have to do anyway; a user might try to delete a brick wh= ich is undergoing > migration and you have to stop him from doing so. So 0 extra work here. > > * Instead of stopMigrate meaning two different things in two different co= ntexts, we now > have stopMigration mean exactly what its name suggests: it stops the migr= ation, and 'reactive' > mean exactly what it suggests - mark this brick as active again, allow it= to be used. Thanks Ori for the detailed mail. So now the final set of APIs are - - migrate - stopmigrate - delete (existing delete to be enabled for commit) - reactivate Will go ahead with this and raise the patches accordingly. Thanks and Regards, Shubhendu >> Sahina, request your comments on the same. >> >> Thanks and Regards, >> Shubhendu > On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: >> On 11/10/2013 11:06 PM, Moti Asayag wrote: >>> ----- Original Message ----- >>>> From: "Shubhendu Tripathi" >>>> To: "engine-devel" , "Michael Pasternak" >>>> , oliel(a)redhat.com >>>> Sent: Friday, November 8, 2013 8:37:30 AM >>>> Subject: [Engine-devel] REST-API: Problem with additional DELETE >>>> action at collection level >>>> >>>> Hi All, >>>> >>>> There is a DELETE action defined at collection level for Gluster >>>> Bricks with >>>> signature - >>>> >>>> @DELETE >>>> public Response remove ( GlusterBricks bricks ); >>>> >>>> Recently we had needed a commit action to remove migrated bricks. >>>> After multiple rounds of discussion on introducing a commit action >>>> to remove >>>> migrated bricks we introduced a DELETE action [1] which accepts a >>>> boolean >>>> parameter isForce. >>>> If the parameter is set to true , forced deletion of bricks happens >>>> without >>>> any data migration. >>>> And if the parameter is not set or set to false, the deletion is >>>> meant for a >>>> brick on which migration has already taken place. >>>> >>>> To achieve the above functionality we introduced another DELETE >>>> action with >>>> new signature as below and also marked the first action as deprecated - >>>> >>>> @DELETE >>>> public Response remove ( Action action ); >>>> >>>> The problem arises now as the new api works fine for all possible >>>> scenarios >>>> with below input structure - >>>> >>>> >>>> true/false >>>> >>>> >>>> brick1-name >>>> brick2-name >>>> >>>> >>>> >>>> >>>> BUT after these change backward compatibility is broken and the old >>>> api does >>>> not work. >>>> If we try invoking old DELETE with bricks as input parameter as >>>> below, it >>>> still invokes the new api and gives an error saying " Invalid >>>> parameter ". >>>> >>> Maybe I've missed it some where, but i wasn't able to find the new >>> 'force' parameter >>> in the rsdl, and specifically not in optionalArguments list of: >>> >>> - name: >>> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel= =3Ddelete >>> >>> and perhaps the correct approach will be to deprecate this signature >>> and introduce a new >>> one with the 'force' in the 'mandatoryArguments' section. >> Moti, I have introduced another methods remove of DELETE type which >> takes Action as input. >> I pass list of bricks and force as parameter in the same Action. >> >> Also, I tried marking the old method deprecated and introduced the new >> one BUT as mentioned above, after introduction of new DELETE with >> Action parameter old one STOPS working. >> Is it OK to stop working for a method if its deprecated?? I don't feel >> so. Please comment. >>>> >>>> >>>> >>>> >>>> >>>> Kindly suggest a solution around the same. >>>> >>>> PS: Both the actions are defined at collection level ( >>>> /api/clusters//glustervolumes//bricks ) >>>> >>>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>>> >>>> Thanks and Regards, >>>> Shubhendu >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> > > --===============1838073393278435514==-- From oliel at redhat.com Mon Nov 11 10:47:37 2013 Content-Type: multipart/mixed; boundary="===============5236471698372966406==" MIME-Version: 1.0 From: Ori Liel To: devel at ovirt.org Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Mon, 11 Nov 2013 10:47:36 -0500 Message-ID: <1378916650.28031202.1384184856755.JavaMail.root@redhat.com> In-Reply-To: 5280B999.6000605@redhat.com --===============5236471698372966406== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Guys, I apologize, but after considering it some more, I think there's a ba= sic problem in what I've suggested. = What I described would be great, if there would never be a need to delete a= brick during the process of its = migration, or in other words to force its deletion. But since we must have = such an option, in case migration goes wrong and we decide to get rid of the brick at all cost, then we must be ab= lechoose force=3Dtrue or force=3Dfalse. = We've already had this discussion, and the original conclusion was right: t= his does require another signature for = DELETE, one which receives an Action object and sets force=3Dtrue or force= =3Dfalse inside it - just like what Shubhendu = described that he tried to do in his email. Telling you, Shubhendu, that an= other signature is unnecessary was wrong, = took you a step back and waisted of your time. I hope you haven't spent muc= h effort implementing what we said yet, = as we reached an agreement relatively late in your working day... So my sin= cere apologies for that. I am well aware = that as it is a lot of time has been invested in agreeing on the correct AP= I. = I will now revisit your original question, Shubehendu, and soon reply to th= at, addressing the technical difficulty that you encountered. = Ori. = ----- Original Message ----- From: "Shubhendu Tripathi" To: "Ori Liel" Cc: "Michael Pasternak" , "Sahina Bose" , "Dusmant Pati" , "engine-devel" Sent: Monday, November 11, 2013 1:03:53 PM Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action= at collection level On 11/11/2013 04:08 PM, Ori Liel wrote: >> ----- Original Message ----- >> From: "Shubhendu Tripathi" >> To: oliel(a)redhat.com, "Michael Pasternak" , "Sa= hina Bose" >> Cc: "Dusmant Pati" , "engine-devel" >> Sent: Monday, November 11, 2013 12:00:34 PM >> Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE act= ion at collection level >> >> Self and Ori had a detailed discussion on the topic. >> >> Points discussed - >> >> 1. Ori mentioned that Michael and Ori did not mean to have a separate >> DELETE action for the purpose of commit in previous discussions. > That's right - no need for a new delete signature; existing signatures ar= e enough. > >> 2. Ori tried to understand the intention behind the separate commit >> command in gluster and suggested that ideally gluster should remember >> that a migration of data is started on the set of bricks, and if there >> is a delete fired on the same bricks it should perform a commit action >> because commit is nothing but a delete action >> 3. Ori suggested that in an ideal situation APIs needed would be >> - start migrate >> - stop migrate >> - delete bricks >> - retain bricks >> 4. As suggested by Ori, the remove bricks action should internally >> decide if there was a data migration, started on the set of bricks. If >> so, it should effectively fire a commit for the set of bricks. And if >> there was not occurrence of data migration it should behave like a >> normal force remove action. >> >> Ori, please add your comments if I have missed out anything here. > I agree with what you wrote, let me sort of say it again in my words: > > I don't like requiring two consecutive commands from the API user, to per= form migrate. > If the user only does 'migrate', and doesn't do the second step, we are i= n a state of > corruption. But Shubhendu explained to me that there's no way around this= ; the > administrator *must* take a look and decide; it is simply not possible to= make this > decision in advance. So I accepted this heavy-heartedly. > > Then we were left with the decision of how to model this two step operati= on. I tried to > look at it from the point of view of the user; what would be the simplest= way to 'tell him > the story?' > > - If you want to migrate a brick, run 'migrate' on it. > - If you want to stop migration of the brick, run 'stopMigrate' on it. > - If you want to resume the migration of the brick, simply run 'migrate' = on it again. > After migration is done: > - if you want to remove the brick, DELETE it (regular delete). > - if you want to keep using the brick, run 'reactivate' on it. > > And that's the whole story. > > The advantages are: > > * In simple English, not bound to Gluster terms, the administrator has to= decide whether to > get rid of the brick, remove it, when migration is done. So what would be= more natural than > to delete it? It makes sense, and there's no need for a new 'action'. On = the Gluster side, > if user tried to delete a brick which is undergoing migration - simply do= n't allow it. This > is something you have to do anyway; a user might try to delete a brick wh= ich is undergoing > migration and you have to stop him from doing so. So 0 extra work here. > > * Instead of stopMigrate meaning two different things in two different co= ntexts, we now > have stopMigration mean exactly what its name suggests: it stops the migr= ation, and 'reactive' > mean exactly what it suggests - mark this brick as active again, allow it= to be used. Thanks Ori for the detailed mail. So now the final set of APIs are - - migrate - stopmigrate - delete (existing delete to be enabled for commit) - reactivate Will go ahead with this and raise the patches accordingly. Thanks and Regards, Shubhendu >> Sahina, request your comments on the same. >> >> Thanks and Regards, >> Shubhendu > On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote: >> On 11/10/2013 11:06 PM, Moti Asayag wrote: >>> ----- Original Message ----- >>>> From: "Shubhendu Tripathi" >>>> To: "engine-devel" , "Michael Pasternak" >>>> , oliel(a)redhat.com >>>> Sent: Friday, November 8, 2013 8:37:30 AM >>>> Subject: [Engine-devel] REST-API: Problem with additional DELETE >>>> action at collection level >>>> >>>> Hi All, >>>> >>>> There is a DELETE action defined at collection level for Gluster >>>> Bricks with >>>> signature - >>>> >>>> @DELETE >>>> public Response remove ( GlusterBricks bricks ); >>>> >>>> Recently we had needed a commit action to remove migrated bricks. >>>> After multiple rounds of discussion on introducing a commit action >>>> to remove >>>> migrated bricks we introduced a DELETE action [1] which accepts a >>>> boolean >>>> parameter isForce. >>>> If the parameter is set to true , forced deletion of bricks happens >>>> without >>>> any data migration. >>>> And if the parameter is not set or set to false, the deletion is >>>> meant for a >>>> brick on which migration has already taken place. >>>> >>>> To achieve the above functionality we introduced another DELETE >>>> action with >>>> new signature as below and also marked the first action as deprecated - >>>> >>>> @DELETE >>>> public Response remove ( Action action ); >>>> >>>> The problem arises now as the new api works fine for all possible >>>> scenarios >>>> with below input structure - >>>> >>>> >>>> true/false >>>> >>>> >>>> brick1-name >>>> brick2-name >>>> >>>> >>>> >>>> >>>> BUT after these change backward compatibility is broken and the old >>>> api does >>>> not work. >>>> If we try invoking old DELETE with bricks as input parameter as >>>> below, it >>>> still invokes the new api and gives an error saying " Invalid >>>> parameter ". >>>> >>> Maybe I've missed it some where, but i wasn't able to find the new >>> 'force' parameter >>> in the rsdl, and specifically not in optionalArguments list of: >>> >>> - name: >>> /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel= =3Ddelete >>> >>> and perhaps the correct approach will be to deprecate this signature >>> and introduce a new >>> one with the 'force' in the 'mandatoryArguments' section. >> Moti, I have introduced another methods remove of DELETE type which >> takes Action as input. >> I pass list of bricks and force as parameter in the same Action. >> >> Also, I tried marking the old method deprecated and introduced the new >> one BUT as mentioned above, after introduction of new DELETE with >> Action parameter old one STOPS working. >> Is it OK to stop working for a method if its deprecated?? I don't feel >> so. Please comment. >>>> >>>> >>>> >>>> >>>> >>>> Kindly suggest a solution around the same. >>>> >>>> PS: Both the actions are defined at collection level ( >>>> /api/clusters//glustervolumes//bricks ) >>>> >>>> [1]: http://gerrit.ovirt.org/#/c/21043/ >>>> >>>> Thanks and Regards, >>>> Shubhendu >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> > > --===============5236471698372966406==-- From oliel at redhat.com Mon Nov 11 11:20:47 2013 Content-Type: multipart/mixed; boundary="===============0376091484638336410==" MIME-Version: 1.0 From: Ori Liel To: devel at ovirt.org Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level Date: Mon, 11 Nov 2013 11:20:46 -0500 Message-ID: <2101667553.28083459.1384186846646.JavaMail.root@redhat.com> In-Reply-To: 527C7DDF.2050308@redhat.com --===============0376091484638336410== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Shubhendu, = The problem you're describing stems from the fact that BackendGlusterBricks= Resource already has an implementation of 'remove' which recieves an object= (GlusterBricks). This creates ambiguity that RestEasy can't resolve: it ha= s no way of deciding whether to deserialize the XML data into an 'Action' o= bject or into a 'GlusterBricks' object. Within the current limitation of Re= stEasy, this problem is unsolvable. = To overcome this, we can take a different approach: pass 'force' as a URL m= atrix parameter. In order to see how this is achieved technically, I refer = you to BackendResource.isAsync() method. 'async' is a URL matrix parameter,= and this simple method shows how it's fetched from the URL. Implementing s= omething similar for force should be easy. = On our side, I will deprecate all current uses of 'force' in the API and mo= ve them all to be URL matrix parameters, so that we'll be aligned with you. Michael will be here tomorrow, and on Wednesday I'll also be available agai= n, to help and/or review. = Thanks, = Ori. = ----- Original Message ----- From: "Shubhendu Tripathi" To: "engine-devel" , "Michael Pasternak" , oliel(a)redhat.com Cc: "Dusmant Pati" Sent: Friday, November 8, 2013 7:59:59 AM Subject: REST-API: Problem with additional DELETE action at collection level Hi All, There is a DELETE action defined at collection level for Gluster Bricks = with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to = remove migrated bricks we introduced a DELETE action [1] which accepts a = boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens = without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant = for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action = with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible = scenarios with below input structure - / //// // true/false// // // // // // //brick1-name// // brick2-name// // // // // /// BUT after these change backward compatibility is broken and the old api = does not work. If we try invoking old DELETE with bricks as input parameter as below, = it still invokes the new api and gives an error saying "Invalid parameter". / // // / Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level = (//api/clusters//glustervolumes//bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu --===============0376091484638336410==--