3:53 p.m.
----_com.android.email_68837318013720
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
ClRoYW5rcyBKdWFuIGZvciB0aGUgY29tbWVudHMuIEkgd291bGQgdXBkYXRlIHRoZSB3aWtpIGFj
Y29yZGluZ2x5IGFuZCBzZW5kIGZvciBjb25maXJtYXRpb24uCgpSZWdhcmRzClNodWJoZW5kdQoK
U2VudCBmcm9tIFNhbXN1bmcgTW9iaWxlCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t
LS0tCkZyb206IEp1YW4gSGVybsOhbmRleiA8amhlcm5hbmRAcmVkaGF0LmNvbT4gCkRhdGU6IDA5
LzEyLzIwMTQgIDE4OjUxICAoR01UKzA1OjMwKSAKVG86IFNodWJoZW5kdSBUcmlwYXRoaSA8c2h0
cmlwYXRAcmVkaGF0LmNvbT4sZGV2ZWxAb3ZpcnQub3JnLE1pY2hhZWwgUGFzdGVybmFrIDxtcGFz
dGVybkByZWRoYXQuY29tPiAKU3ViamVjdDogUmU6IFtvdmlydC1kZXZlbF0gR2x1c3RlciBWb2x1
bWUgU25hcHNob3RzIC0gRmVhdHVyZSByZXZpZXcgCiAKT24gMTIvMDQvMjAxNCAwNzoxMSBQTSwg
U2h1YmhlbmR1IFRyaXBhdGhpIHdyb3RlOgo+IEhpIEp1YW4vTWljaGFlbCwKPiAKPiBUaGlzIGlz
IGEgZ2VudGxlIHJlbWluZGVyIGZvciB0aGUgcmV2aWV3IG9mIHRoZSBSRVNUIGFwaSBkZXNpZ24g
Zm9yIHRoZSAKPiBiZWxvdyBmZWF0dXJlLgo+IFdlIHdvdWxkIGJlIHN0YXJ0aW5nIHRoZSBSRVNU
IGRldmVsb3BtZW50IGZvciB0aGUgc2FtZSBzb29uIChwcm9iYWJseSBieSAKPiBEZWMgMjAxNCBl
bmQpLgo+IAo+IElmIHRoZXJlIGFyZSBzcGVjaWZpYyBjb21tZW50cywgcGxlYXNlIHBhc3MgaXQg
b24uIElmIG5vIGNvbW1lbnRzIHdlIAo+IHdvdWxkIGdvIGFoZWFkIHdpdGggdGhlIGN1cnJlbnQg
ZGVzaWduIGFuZCBpbXBsZW1lbnQgYWNjb3JkaW5nbHkuCj4gCj4gUmVxdWVzdCB5b3VyIHRpbWUg
Zm9yIHRoaXMuCj4gCj4gVGhhbmtzIGFuZCBSZWdhcmRzLAo+IFNodWJoZW5kdQo+IAo+IE9uIDEx
LzEwLzIwMTQgMTI6MjIgUE0sIFNodWJoZW5kdSBUcmlwYXRoaSB3cm90ZToKPj4gSGkgQWxsLAo+
Pgo+PiBQbGVhc2UgaGVscCB1cyB0byByZXZpZXcgdGhlIGRlc2lnbiBvZiBHbHVzdGVyIFZvbHVt
ZSBTbmFwc2hvdHMgaW4gb1ZpcnQsCj4+Cj4+IEhlcmUgYXJlIHR3byBkZXNpZ24gb24gd2lraSBw
YWdlCj4+Cj4+IEdlbmVyYWwgRmVhdHVyZSBEZXNpZ24KPj4gaHR0cDovL3d3dy5vdmlydC5vcmcv
RmVhdHVyZXMvR2x1c3RlclZvbHVtZVNuYXBzaG90cwo+Pgo+PiBEZXRhaWxlZCBEZXNpZ24KPj4g
aHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMvRGVzaWduL0dsdXN0ZXJWb2x1bWVTbmFwc2hv
dHMKPj4KPj4gV2UgdGFyZ2V0IGl0IGluIG92aXJ0IDMuNiByZWxlYXNlLgo+Pgo+PiBNYXJrZWQg
SnVhbi9NaWNoYWVsIHNwZWNpZmljYWxseSBmb3IgUkVTVCByZXZpZXcuCj4+Cj4+IEJlc3QgUmVn
YXJkcywKPj4gU2h1YmhlbmR1IFRyaXBhdGhpCgpNeSBjb21tZW50cyBhYm91dCB0aGUgUkVTVEFQ
SToKCjEuIFlvdSBjYW4ndCB1c2UgdGhlICJzbmFwc2hvdCIgYW5kICJzbmFwc2hvdHMiIFhNTCBl
bGVtZW50cywgYXMgdGhvc2UKYXJlIGFscmVhZHkgaW4gdXNlIGZvciBkaXNrIHNuYXBzaG90cywg
YW5kIHdlIGRvbid0IGhhdmUgbmFtZSBzcGFjZQpzdXBwb3J0IGluIHRoZSBSRVNUQVBJLiBZb3Ug
d2lsbCBoYXZlIHRvIHVzZSBzb21ldGhpbmcgZGlmZmVyZW50LCBmb3IKZXhhbXBsZSAiZ2x1c3Rl
cl92b2x1bWVfc25hcHNob3RzIiBhbmQgImdsdXN0ZXJfdm9sdW1lX3NuYXBzaG90Ii4KCjIuIFdo
ZW4gYWRkaW5nIGEgdm9sdW1lIHNuYXBzaG90IHRoZSBuYW1lIG9mIHRoZSB2b2x1bWUgc2hvdWxk
bid0IGJlIGEKcGFyYW1ldGVyLCBhcyB0aGF0IGlzIGltcGxpY2l0LiBPbmx5IHRoZSBuYW1lIGFu
ZCBkZXNjcmlwdGlvbiBvZiB0aGUKc25hcHNob3Qgc2hvdWxkIGJlIHByb3ZpZGVkLgoKMy4gVGhl
IG9wZXJhdGlvbiB0byBkZWxldGUgYSBzbmFwc2hvdCBzaG91bGQgYmUgcGVyZm9ybWVkIG9uIHRo
ZQpzbmFwc2hvdCByZXNvdXJjZSwgbm90IG9uIHRoZSBjb2xsZWN0aW9uOgoKwqAgREVMRVRFCi9j
bHVzdGVycy97Y2x1c3RlcjppZH0vZ2x1c3RlcnZvbHVtZXMve3ZvbHVtZTppZH0vc25hcHNob3Rz
L3tzbmFwc2hvdDppZH0KCklkZWFsbHkgdGhpcyBvcGVyYXRpb24gc2hvdWxkbid0IHJlY2VpdmUg
YW55IHBhcmFtZXRlcnMgKHRodXMgbm8gYm9keSkuCklmIGl0IGRvZXMgcmVxdWlyZSBwYXJhbWV0
ZXJzIHRoZW4gdGhleSBzaG91bGQgYmUgY29udGFpbmVkIGluc2lkZSBhbgoiYWN0aW9uIiBlbGVt
ZW50LgoKNC4gVGhlIG9wZXJhdGlvbiB0byB1cGRhdGUgdGhlIHNuYXBzaG90IGNvbmZpZ3VyYXRp
b24gc2hvdWxkIGJlIHRoZSBQVVQKb3BlcmF0aW9uIG9mIHRoZSB2b2x1bWUsIG5vdCBhIG5ldyAi
c25hcHNob3Rjb25maWciIHN1Yi1yZXNvdXJjZSwgYXMKdGhlc2Uga2luZCBvZiBzdWItcmVzb3Vy
Y2VzIGFyZW4ndCB3ZWxsIHN1cHBvcnRlZCBieSB0aGUgU0RLcyBhbmQgdGhlIENMSS4KCi0tIApE
aXJlY2Npw7NuIENvbWVyY2lhbDogQy9Kb3NlIEJhcmRhc2FubyBCYW9zLCA5LCBFZGlmLiBHb3Ji
ZWEgMywgcGxhbnRhCjPCukQsIDI4MDE2IE1hZHJpZCwgU3BhaW4KSW5zY3JpdGEgZW4gZWwgUmVn
LiBNZXJjYW50aWwgZGUgTWFkcmlkIOKAkyBDLkkuRi4gQjgyNjU3OTQxIC0gUmVkIEhhdCBTLkwu
Cg==
----_com.android.email_68837318013720
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj48YnI+PC9kaXY+PGRpdj5U
aGFua3MgSnVhbiBmb3IgdGhlIGNvbW1lbnRzLiBJIHdvdWxkIHVwZGF0ZSB0aGUgd2lraSBhY2Nv
cmRpbmdseSBhbmQgc2VuZCBmb3IgY29uZmlybWF0aW9uLjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk
aXY+UmVnYXJkczwvZGl2PjxkaXY+U2h1YmhlbmR1PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48
ZGl2IHN0eWxlPSJmb250LXNpemU6NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5n
IE1vYmlsZTwvZGl2PjwvZGl2Pjxicj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2Ug
LS0tLS0tLS08YnI+RnJvbTogSnVhbiBIZXJuw6FuZGV6ICZsdDtqaGVybmFuZEByZWRoYXQuY29t
Jmd0OyA8YnI+RGF0ZTogMDkvMTIvMjAxNCAgMTg6NTEgIChHTVQrMDU6MzApIDxicj5UbzogU2h1
YmhlbmR1IFRyaXBhdGhpICZsdDtzaHRyaXBhdEByZWRoYXQuY29tJmd0OyxkZXZlbEBvdmlydC5v
cmcsTWljaGFlbCBQYXN0ZXJuYWsgJmx0O21wYXN0ZXJuQHJlZGhhdC5jb20mZ3Q7IDxicj5TdWJq
ZWN0OiBSZTogW292aXJ0LWRldmVsXSBHbHVzdGVyIFZvbHVtZSBTbmFwc2hvdHMgLSBGZWF0dXJl
IHJldmlldyA8YnI+IDxicj48YnI+T24gMTIvMDQvMjAxNCAwNzoxMSBQTSwgU2h1YmhlbmR1IFRy
aXBhdGhpIHdyb3RlOjxicj4mZ3Q7IEhpIEp1YW4vTWljaGFlbCw8YnI+Jmd0OyA8YnI+Jmd0OyBU
aGlzIGlzIGEgZ2VudGxlIHJlbWluZGVyIGZvciB0aGUgcmV2aWV3IG9mIHRoZSBSRVNUIGFwaSBk
ZXNpZ24gZm9yIHRoZSA8YnI+Jmd0OyBiZWxvdyBmZWF0dXJlLjxicj4mZ3Q7IFdlIHdvdWxkIGJl
IHN0YXJ0aW5nIHRoZSBSRVNUIGRldmVsb3BtZW50IGZvciB0aGUgc2FtZSBzb29uIChwcm9iYWJs
eSBieSA8YnI+Jmd0OyBEZWMgMjAxNCBlbmQpLjxicj4mZ3Q7IDxicj4mZ3Q7IElmIHRoZXJlIGFy
ZSBzcGVjaWZpYyBjb21tZW50cywgcGxlYXNlIHBhc3MgaXQgb24uIElmIG5vIGNvbW1lbnRzIHdl
IDxicj4mZ3Q7IHdvdWxkIGdvIGFoZWFkIHdpdGggdGhlIGN1cnJlbnQgZGVzaWduIGFuZCBpbXBs
ZW1lbnQgYWNjb3JkaW5nbHkuPGJyPiZndDsgPGJyPiZndDsgUmVxdWVzdCB5b3VyIHRpbWUgZm9y
IHRoaXMuPGJyPiZndDsgPGJyPiZndDsgVGhhbmtzIGFuZCBSZWdhcmRzLDxicj4mZ3Q7IFNodWJo
ZW5kdTxicj4mZ3Q7IDxicj4mZ3Q7IE9uIDExLzEwLzIwMTQgMTI6MjIgUE0sIFNodWJoZW5kdSBU
cmlwYXRoaSB3cm90ZTo8YnI+Jmd0OyZndDsgSGkgQWxsLDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0
OyBQbGVhc2UgaGVscCB1cyB0byByZXZpZXcgdGhlIGRlc2lnbiBvZiBHbHVzdGVyIFZvbHVtZSBT
bmFwc2hvdHMgaW4gb1ZpcnQsPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEhlcmUgYXJlIHR3byBk
ZXNpZ24gb24gd2lraSBwYWdlPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEdlbmVyYWwgRmVhdHVy
ZSBEZXNpZ248YnI+Jmd0OyZndDsgaHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMvR2x1c3Rl
clZvbHVtZVNuYXBzaG90czxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBEZXRhaWxlZCBEZXNpZ248
YnI+Jmd0OyZndDsgaHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMvRGVzaWduL0dsdXN0ZXJW
b2x1bWVTbmFwc2hvdHM8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgV2UgdGFyZ2V0IGl0IGluIG92
aXJ0IDMuNiByZWxlYXNlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBNYXJrZWQgSnVhbi9NaWNo
YWVsIHNwZWNpZmljYWxseSBmb3IgUkVTVCByZXZpZXcuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7
IEJlc3QgUmVnYXJkcyw8YnI+Jmd0OyZndDsgU2h1YmhlbmR1IFRyaXBhdGhpPGJyPjxicj5NeSBj
b21tZW50cyBhYm91dCB0aGUgUkVTVEFQSTo8YnI+PGJyPjEuIFlvdSBjYW4ndCB1c2UgdGhlICJz
bmFwc2hvdCIgYW5kICJzbmFwc2hvdHMiIFhNTCBlbGVtZW50cywgYXMgdGhvc2U8YnI+YXJlIGFs
cmVhZHkgaW4gdXNlIGZvciBkaXNrIHNuYXBzaG90cywgYW5kIHdlIGRvbid0IGhhdmUgbmFtZSBz
cGFjZTxicj5zdXBwb3J0IGluIHRoZSBSRVNUQVBJLiBZb3Ugd2lsbCBoYXZlIHRvIHVzZSBzb21l
dGhpbmcgZGlmZmVyZW50LCBmb3I8YnI+ZXhhbXBsZSAiZ2x1c3Rlcl92b2x1bWVfc25hcHNob3Rz
IiBhbmQgImdsdXN0ZXJfdm9sdW1lX3NuYXBzaG90Ii48YnI+PGJyPjIuIFdoZW4gYWRkaW5nIGEg
dm9sdW1lIHNuYXBzaG90IHRoZSBuYW1lIG9mIHRoZSB2b2x1bWUgc2hvdWxkbid0IGJlIGE8YnI+
cGFyYW1ldGVyLCBhcyB0aGF0IGlzIGltcGxpY2l0LiBPbmx5IHRoZSBuYW1lIGFuZCBkZXNjcmlw
dGlvbiBvZiB0aGU8YnI+c25hcHNob3Qgc2hvdWxkIGJlIHByb3ZpZGVkLjxicj48YnI+My4gVGhl
IG9wZXJhdGlvbiB0byBkZWxldGUgYSBzbmFwc2hvdCBzaG91bGQgYmUgcGVyZm9ybWVkIG9uIHRo
ZTxicj5zbmFwc2hvdCByZXNvdXJjZSwgbm90IG9uIHRoZSBjb2xsZWN0aW9uOjxicj48YnI+Jm5i
c3A7IERFTEVURTxicj4vY2x1c3RlcnMve2NsdXN0ZXI6aWR9L2dsdXN0ZXJ2b2x1bWVzL3t2b2x1
bWU6aWR9L3NuYXBzaG90cy97c25hcHNob3Q6aWR9PGJyPjxicj5JZGVhbGx5IHRoaXMgb3BlcmF0
aW9uIHNob3VsZG4ndCByZWNlaXZlIGFueSBwYXJhbWV0ZXJzICh0aHVzIG5vIGJvZHkpLjxicj5J
ZiBpdCBkb2VzIHJlcXVpcmUgcGFyYW1ldGVycyB0aGVuIHRoZXkgc2hvdWxkIGJlIGNvbnRhaW5l
ZCBpbnNpZGUgYW48YnI+ImFjdGlvbiIgZWxlbWVudC48YnI+PGJyPjQuIFRoZSBvcGVyYXRpb24g
dG8gdXBkYXRlIHRoZSBzbmFwc2hvdCBjb25maWd1cmF0aW9uIHNob3VsZCBiZSB0aGUgUFVUPGJy
Pm9wZXJhdGlvbiBvZiB0aGUgdm9sdW1lLCBub3QgYSBuZXcgInNuYXBzaG90Y29uZmlnIiBzdWIt
cmVzb3VyY2UsIGFzPGJyPnRoZXNlIGtpbmQgb2Ygc3ViLXJlc291cmNlcyBhcmVuJ3Qgd2VsbCBz
dXBwb3J0ZWQgYnkgdGhlIFNES3MgYW5kIHRoZSBDTEkuPGJyPjxicj4tLSA8YnI+RGlyZWNjacOz
biBDb21lcmNpYWw6IEMvSm9zZSBCYXJkYXNhbm8gQmFvcywgOSwgRWRpZi4gR29yYmVhIDMsIHBs
YW50YTxicj4zwrpELCAyODAxNiBNYWRyaWQsIFNwYWluPGJyPkluc2NyaXRhIGVuIGVsIFJlZy4g
TWVyY2FudGlsIGRlIE1hZHJpZCDigJMgQy5JLkYuIEI4MjY1Nzk0MSAtIFJlZCBIYXQgUy5MLjxi
cj48L2JvZHk+
----_com.android.email_68837318013720--
6:36 a.m.
New subject: Gluster Volume Snapshots - Feature review
Hi Juan,
Incorporated the review comments.
Kindly have a look and let us know if everything looks well and good.
Thanks and Regards,
Shubhendu
On 12/09/2014 07:23 PM, Shubhendu Tripathi wrote:
Thanks Juan for the comments. I would update the wiki accordingly and
send for confirmation.
Regards
Shubhendu
Sent from Samsung Mobile
-------- Original message --------
From: Juan Hernández <jhernand(a)redhat.com>
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi <shtripat@redhat.com>,devel(a)ovirt.org,Michael Pasternak
<mpastern(a)redhat.com>
Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
> Hi Juan/Michael,
>
> This is a gentle reminder for the review of the REST api design for the
> below feature.
> We would be starting the REST development for the same soon (probably by
> Dec 2014 end).
>
> If there are specific comments, please pass it on. If no comments we
> would go ahead with the current design and implement accordingly.
>
> Request your time for this.
>
> Thanks and Regards,
> Shubhendu
>
> On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
>> Hi All,
>>
>> Please help us to review the design of Gluster Volume Snapshots in oVirt,
>>
>> Here are two design on wiki page
>>
>> General Feature Design
>> http://www.ovirt.org/Features/GlusterVolumeSnapshots
>>
>> Detailed Design
>> http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
>>
>> We target it in ovirt 3.6 release.
>>
>> Marked Juan/Michael specifically for REST review.
>>
>> Best Regards,
>> Shubhendu Tripathi
My comments about the RESTAPI:
1. You can't use the "snapshot" and "snapshots" XML elements, as
those
are already in use for disk snapshots, and we don't have name space
support in the RESTAPI. You will have to use something different, for
example "gluster_volume_snapshots" and "gluster_volume_snapshot".
2. When adding a volume snapshot the name of the volume shouldn't be a
parameter, as that is implicit. Only the name and description of the
snapshot should be provided.
3. The operation to delete a snapshot should be performed on the
snapshot resource, not on the collection:
DELETE
/clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
Ideally this operation shouldn't receive any parameters (thus no body).
If it does require parameters then they should be contained inside an
"action" element.
4. The operation to update the snapshot configuration should be the PUT
operation of the volume, not a new "snapshotconfig" sub-resource, as
these kind of sub-resources aren't well supported by the SDKs and the CLI.
5:26 p.m.
New subject: Gluster Volume Snapshots - Feature review
On 12/11/2014 05:36 AM, Shubhendu Tripathi wrote:
Hi Juan,
Incorporated the review comments.
Kindly have a look and let us know if everything looks well and good.
Thanks and Regards,
Shubhendu
Thanks for making the changes. I have some additional comments:
1. URL segments shouldn't have underscores. For example, you are
proposing URLs like this:
/clusters/{cluster:id}/glustervolumes/{volume:id}/volume_snapshots
The last component should be "volumesnapshots", without the underscore.
Note that on the other hand XML element should have underscores, like in
"<volume_snapshots>", that is correct.
2. Try to avoid abbreviations. For example, instead of "whatever_params"
use "whatever_parameters", and instead of "scheduling_det" use
"scheduling_details", use "cron_expression" instead of
"cronexpr", so on.
3. If possible the action to delete a snapshot shouldn't receive any
parameters, not even an empty "<action/>" element.
4. The "schedulesnapshot" action should be modeled using REST style, not
an action. My understanding is that you plan to have for each volume a
set of rules that define when the snapshots will be created. This should
be implemented as a sub-collection of the volume, so that these rules
can be queried, added, modified and deleted:
To query:
GET ...{volume:id}/snapshotrules
<snapshot_rules>
<snapshot_rule id="..." href="...">
<crontab_expression>...</crontab_expression>
</snapshot_rule>
...
</snapshot_rules>
To add:
POST ...{volume:id{/snapshotrules
<snapshot_rule>
<crontab_expression>...</crontab_expression>
</snapshot_rule>
To modify:
PUT ...{volume:id}/snapshotrules/{snapshotrule:id}
<snapshot_rule>
<crontab_expression>...</crontab_expression>
</snapshot_rule>
To delete (note that there is no body):
DELETE ...{volume:id}/snapshotrules/{snapshotrule:id}
If there will be only one of these rules per volume then you can model
them as attributes of the volume itself, without the sub-collection.
5. The "snapshotconfigs" should be modeled as an attribute of the
volume, not as an action.
On 12/09/2014 07:23 PM, Shubhendu Tripathi wrote:
> Thanks Juan for the comments. I would update the wiki accordingly and send for
confirmation.
>
> Regards
> Shubhendu
>
> Sent from Samsung Mobile
>
> -------- Original message --------
> From: Juan Hernández <jhernand(a)redhat.com>
> Date: 09/12/2014 18:51 (GMT+05:30)
> To: Shubhendu Tripathi <shtripat@redhat.com>,devel(a)ovirt.org,Michael Pasternak
<mpastern(a)redhat.com>
> Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
>
> On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
>> Hi Juan/Michael,
>>
>> This is a gentle reminder for the review of the REST api design for the
>> below feature.
>> We would be starting the REST development for the same soon (probably by
>> Dec 2014 end).
>>
>> If there are specific comments, please pass it on. If no comments we
>> would go ahead with the current design and implement accordingly.
>>
>> Request your time for this.
>>
>> Thanks and Regards,
>> Shubhendu
>>
>> On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
>>> Hi All,
>>>
>>> Please help us to review the design of Gluster Volume Snapshots in oVirt,
>>>
>>> Here are two design on wiki page
>>>
>>> General Feature Design
>>> http://www.ovirt.org/Features/GlusterVolumeSnapshots
>>>
>>> Detailed Design
>>> http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
>>>
>>> We target it in ovirt 3.6 release.
>>>
>>> Marked Juan/Michael specifically for REST review.
>>>
>>> Best Regards,
>>> Shubhendu Tripathi
> My comments about the RESTAPI:
>
> 1. You can't use the "snapshot" and "snapshots" XML elements,
as those
> are already in use for disk snapshots, and we don't have name space
> support in the RESTAPI. You will have to use something different, for
> example "gluster_volume_snapshots" and
"gluster_volume_snapshot".
>
> 2. When adding a volume snapshot the name of the volume shouldn't be a
> parameter, as that is implicit. Only the name and description of the
> snapshot should be provided.
>
> 3. The operation to delete a snapshot should be performed on the
> snapshot resource, not on the collection:
>
> DELETE
> /clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
>
> Ideally this operation shouldn't receive any parameters (thus no body).
> If it does require parameters then they should be contained inside an
> "action" element.
>
> 4. The operation to update the snapshot configuration should be the PUT
> operation of the volume, not a new "snapshotconfig" sub-resource, as
> these kind of sub-resources aren't well supported by the SDKs and the CLI.
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
3:08 p.m.
New subject: Gluster Volume Snapshots - Feature review
Hi Juan,
Thanks for the detailed comments.
My comments inline.
Thanks and Regards,
Shubhendu
On 12/11/2014 08:56 PM, Juan Hernández wrote:
On 12/11/2014 05:36 AM, Shubhendu Tripathi wrote:
> Hi Juan,
>
> Incorporated the review comments.
> Kindly have a look and let us know if everything looks well and good.
>
> Thanks and Regards,
> Shubhendu
>
Thanks for making the changes. I have some additional comments:
1. URL segments shouldn't have underscores. For example, you are
proposing URLs like this:
/clusters/{cluster:id}/glustervolumes/{volume:id}/volume_snapshots
The last component should be "volumesnapshots", without the underscore.
Note that on the other hand XML element should have underscores, like in
"<volume_snapshots>", that is correct.
Sure. Will do the changes accordingly.
2. Try to avoid abbreviations. For example, instead of "whatever_params"
use "whatever_parameters", and instead of "scheduling_det" use
"scheduling_details", use "cron_expression" instead of
"cronexpr", so on.
Sure. Will do the changes accordingly.
3. If possible the action to delete a snapshot shouldn't receive any
parameters, not even an empty "<action/>" element.
Sure. Will do the changes accordingly.
4. The "schedulesnapshot" action should be modeled using REST style, not
an action. My understanding is that you plan to have for each volume a
set of rules that define when the snapshots will be created. This should
be implemented as a sub-collection of the volume, so that these rules
can be queried, added, modified and deleted:
To query:
GET ...{volume:id}/snapshotrules
<snapshot_rules>
<snapshot_rule id="..." href="...">
<crontab_expression>...</crontab_expression>
</snapshot_rule>
...
</snapshot_rules>
To add:
POST ...{volume:id{/snapshotrules
<snapshot_rule>
<crontab_expression>...</crontab_expression>
</snapshot_rule>
To modify:
PUT ...{volume:id}/snapshotrules/{snapshotrule:id}
<snapshot_rule>
<crontab_expression>...</crontab_expression>
</snapshot_rule>
To delete (note that there is no body):
DELETE ...{volume:id}/snapshotrules/{snapshotrule:id}
If there will be only one of these rules per volume then you can model
them as attributes of the volume itself, without the sub-collection.
At a time there would be only one rule for a volume, so as suggested it
could be a volume attribute. Will model accordingly.
5. The "snapshotconfigs" should be modeled as an attribute of the
volume, not as an action.
As above.
> On 12/09/2014 07:23 PM, Shubhendu Tripathi wrote:
>> Thanks Juan for the comments. I would update the wiki accordingly and send for
confirmation.
>>
>> Regards
>> Shubhendu
>>
>> Sent from Samsung Mobile
>>
>> -------- Original message --------
>> From: Juan Hernández <jhernand(a)redhat.com>
>> Date: 09/12/2014 18:51 (GMT+05:30)
>> To: Shubhendu Tripathi <shtripat@redhat.com>,devel(a)ovirt.org,Michael
Pasternak <mpastern(a)redhat.com>
>> Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
>>
>> On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
>>> Hi Juan/Michael,
>>>
>>> This is a gentle reminder for the review of the REST api design for the
>>> below feature.
>>> We would be starting the REST development for the same soon (probably by
>>> Dec 2014 end).
>>>
>>> If there are specific comments, please pass it on. If no comments we
>>> would go ahead with the current design and implement accordingly.
>>>
>>> Request your time for this.
>>>
>>> Thanks and Regards,
>>> Shubhendu
>>>
>>> On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
>>>> Hi All,
>>>>
>>>> Please help us to review the design of Gluster Volume Snapshots in
oVirt,
>>>>
>>>> Here are two design on wiki page
>>>>
>>>> General Feature Design
>>>> http://www.ovirt.org/Features/GlusterVolumeSnapshots
>>>>
>>>> Detailed Design
>>>> http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
>>>>
>>>> We target it in ovirt 3.6 release.
>>>>
>>>> Marked Juan/Michael specifically for REST review.
>>>>
>>>> Best Regards,
>>>> Shubhendu Tripathi
>> My comments about the RESTAPI:
>>
>> 1. You can't use the "snapshot" and "snapshots" XML
elements, as those
>> are already in use for disk snapshots, and we don't have name space
>> support in the RESTAPI. You will have to use something different, for
>> example "gluster_volume_snapshots" and
"gluster_volume_snapshot".
>>
>> 2. When adding a volume snapshot the name of the volume shouldn't be a
>> parameter, as that is implicit. Only the name and description of the
>> snapshot should be provided.
>>
>> 3. The operation to delete a snapshot should be performed on the
>> snapshot resource, not on the collection:
>>
>> DELETE
>> /clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
>>
>> Ideally this operation shouldn't receive any parameters (thus no body).
>> If it does require parameters then they should be contained inside an
>> "action" element.
>>
>> 4. The operation to update the snapshot configuration should be the PUT
>> operation of the volume, not a new "snapshotconfig" sub-resource, as
>> these kind of sub-resources aren't well supported by the SDKs and the CLI.
>>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
5:40 a.m.
New subject: Gluster Volume Snapshots - Feature review
Hi Juan,
Incorporated the comments in the wiki.
Kindly do have a look.
Thanks and Regards,
Shubhendu
On 12/18/2014 06:38 PM, Shubhendu Tripathi wrote:
Hi Juan,
Thanks for the detailed comments.
My comments inline.
Thanks and Regards,
Shubhendu
On 12/11/2014 08:56 PM, Juan Hernández wrote:
> On 12/11/2014 05:36 AM, Shubhendu Tripathi wrote:
>> Hi Juan,
>>
>> Incorporated the review comments.
>> Kindly have a look and let us know if everything looks well and good.
>>
>> Thanks and Regards,
>> Shubhendu
>>
> Thanks for making the changes. I have some additional comments:
>
> 1. URL segments shouldn't have underscores. For example, you are
> proposing URLs like this:
>
> /clusters/{cluster:id}/glustervolumes/{volume:id}/volume_snapshots
>
> The last component should be "volumesnapshots", without the underscore.
> Note that on the other hand XML element should have underscores, like in
> "<volume_snapshots>", that is correct.
Sure. Will do the changes accordingly.
>
> 2. Try to avoid abbreviations. For example, instead of "whatever_params"
> use "whatever_parameters", and instead of "scheduling_det" use
> "scheduling_details", use "cron_expression" instead of
"cronexpr", so
> on.
Sure. Will do the changes accordingly.
>
> 3. If possible the action to delete a snapshot shouldn't receive any
> parameters, not even an empty "<action/>" element.
Sure. Will do the changes accordingly.
>
> 4. The "schedulesnapshot" action should be modeled using REST style, not
> an action. My understanding is that you plan to have for each volume a
> set of rules that define when the snapshots will be created. This should
> be implemented as a sub-collection of the volume, so that these rules
> can be queried, added, modified and deleted:
>
> To query:
>
> GET ...{volume:id}/snapshotrules
> <snapshot_rules>
> <snapshot_rule id="..." href="...">
> <crontab_expression>...</crontab_expression>
> </snapshot_rule>
> ...
> </snapshot_rules>
>
> To add:
>
> POST ...{volume:id{/snapshotrules
> <snapshot_rule>
> <crontab_expression>...</crontab_expression>
> </snapshot_rule>
>
> To modify:
>
> PUT ...{volume:id}/snapshotrules/{snapshotrule:id}
> <snapshot_rule>
> <crontab_expression>...</crontab_expression>
> </snapshot_rule>
>
> To delete (note that there is no body):
>
> DELETE ...{volume:id}/snapshotrules/{snapshotrule:id}
>
> If there will be only one of these rules per volume then you can model
> them as attributes of the volume itself, without the sub-collection.
At a time there would be only one rule for a volume, so as suggested
it could be a volume attribute. Will model accordingly.
>
> 5. The "snapshotconfigs" should be modeled as an attribute of the
> volume, not as an action.
As above.
>
>> On 12/09/2014 07:23 PM, Shubhendu Tripathi wrote:
>>> Thanks Juan for the comments. I would update the wiki accordingly
>>> and send for confirmation.
>>>
>>> Regards
>>> Shubhendu
>>>
>>> Sent from Samsung Mobile
>>>
>>> -------- Original message --------
>>> From: Juan Hernández <jhernand(a)redhat.com>
>>> Date: 09/12/2014 18:51 (GMT+05:30)
>>> To: Shubhendu Tripathi
>>> <shtripat@redhat.com>,devel(a)ovirt.org,Michael Pasternak
>>> <mpastern(a)redhat.com>
>>> Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
>>> On 12/04/2014 07:11 PM, Shubhendu Tripathi wrote:
>>>> Hi Juan/Michael,
>>>>
>>>> This is a gentle reminder for the review of the REST api design
>>>> for the
>>>> below feature.
>>>> We would be starting the REST development for the same soon
>>>> (probably by
>>>> Dec 2014 end).
>>>>
>>>> If there are specific comments, please pass it on. If no comments we
>>>> would go ahead with the current design and implement accordingly.
>>>>
>>>> Request your time for this.
>>>>
>>>> Thanks and Regards,
>>>> Shubhendu
>>>>
>>>> On 11/10/2014 12:22 PM, Shubhendu Tripathi wrote:
>>>>> Hi All,
>>>>>
>>>>> Please help us to review the design of Gluster Volume Snapshots
>>>>> in oVirt,
>>>>>
>>>>> Here are two design on wiki page
>>>>>
>>>>> General Feature Design
>>>>> http://www.ovirt.org/Features/GlusterVolumeSnapshots
>>>>>
>>>>> Detailed Design
>>>>> http://www.ovirt.org/Features/Design/GlusterVolumeSnapshots
>>>>>
>>>>> We target it in ovirt 3.6 release.
>>>>>
>>>>> Marked Juan/Michael specifically for REST review.
>>>>>
>>>>> Best Regards,
>>>>> Shubhendu Tripathi
>>> My comments about the RESTAPI:
>>>
>>> 1. You can't use the "snapshot" and "snapshots" XML
elements, as those
>>> are already in use for disk snapshots, and we don't have name space
>>> support in the RESTAPI. You will have to use something different, for
>>> example "gluster_volume_snapshots" and
"gluster_volume_snapshot".
>>>
>>> 2. When adding a volume snapshot the name of the volume shouldn't be a
>>> parameter, as that is implicit. Only the name and description of the
>>> snapshot should be provided.
>>>
>>> 3. The operation to delete a snapshot should be performed on the
>>> snapshot resource, not on the collection:
>>>
>>> DELETE
>>> /clusters/{cluster:id}/glustervolumes/{volume:id}/snapshots/{snapshot:id}
>>>
>>>
>>> Ideally this operation shouldn't receive any parameters (thus no
>>> body).
>>> If it does require parameters then they should be contained inside an
>>> "action" element.
>>>
>>> 4. The operation to update the snapshot configuration should be the
>>> PUT
>>> operation of the volume, not a new "snapshotconfig" sub-resource,
as
>>> these kind of sub-resources aren't well supported by the SDKs and
>>> the CLI.
>>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3617
days inactive
3632
days old
4 comments
2 participants
participants (2)
-
Juan Hernández -
Shubhendu Tripathi