Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Do you really want to call this entity schedule? I find this somehow confusing as there is already a scheduling component in ovirt, which does different stuff. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
- Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com, Alok Srivastava asriv...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Thursday, January 1, 2015 11:30:41 PM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review On 01/01/2015 10:36 PM, Einav Cohen wrote: - Original Message - From: Shubhendu Tripathi shtri...@redhat.com Sent: Thursday, January 1, 2015 10:05:48 AM On 12/31/2014 11:42 PM, Einav Cohen wrote: Thanks, Shubhendu. Additional comments: ... Yes, attempt to create second snapshot schedule is actually an override option. Of course spot creation is allowed in addition to the scheduled. ... ... If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. ... From your latest responses, I conclude the following. via the New dialog, you can: (1) create a one-time snapshot (2) create a new snapshot schedule (3) override (and practically, edit) an existing snapshot schedule via the Schedule dialog, you can: (a) create a one-time snapshot (by selecting the 'None' recurrence) (b) create a new snapshot schedule (by selecting something other than 'None' in the recurrence field, given that no schedule exists yet) (c) edit an existing snapshot schedule (which is what this dialog is actually meant to do). I am not sure about (a), but it doesn't matter much for my point: New and Schedule have the exact same functionality. To be more accurate: New contains all of the needed functionality; Schedule is not really needed. The only thing that New is potentially missing is showing the values of the already-existing snapshot schedule, if one exists. I think that this may confuse to the user; I recommend to either unite both of these actions/dialogs to a single action/dialog, or separate completely some functionalists. So my recommendation is to do one of the following: (a) unite: Have a single action (Create / Schedule) which will display a dialog very similar to the New dialog, with the option to see the values of the already-existing snapshot schedule, if one exists. In this case, I would actually recommend to go with something more similar to option 2 in http://i.imgur.com/4j7hvRY.png, rather than option 3 (so the separation between *creating new* *one-time* snapshot and *editing an existing* *scheduled* snapshot is clearer). see http://i.imgur.com/ZgCp9Tz.png for an updated suggestion. - or - (b) separate: Have two completely separate actions: Create Now and Schedule. - The Create Now dialog will look like the 'General' side-section of the New dialog (i.e. without the Schedule side-section; it will allow only one-time immediate snapshot creation. - The Schedule dialog will look like the New dialog (with both 'General' and 'Schedule' side-sections) without the None recurrence, and will allow only creating a new recurring snapshot schedule (if one doesn't exist yet) or editing the existing schedule (in this case, the dialog would be pre-populated with the values of the existing schedule). I am more in favor of (b) - it seems simpler and more user-friendly in my view. Option (b) is something which we had started with, then at later stage it was discussed that scheduling as well should be in the flow of creation of snapshot so merged with New Snapshot option. After this as we need Edit option for snapshot schedule, so introduced Schedule option. But still, as you suggest I feel option (b) is no doubt a clearer and user friendly way. Alok, need a point of view from PMs on this. Thanks, Shubhendu. @Alok (and all): the main pain-point in the current design that I am trying to address is the fact that in the 'New' dialog, you have the option to create a one- time snapshot, and within the same dialog, with a very small (too small IMO) change, you have the option to edit (override) an already-existing schedule, without even realizing necessarily that you are editing something (since you are in a 'New' dialog) and without seeing the values of the object that you are editing. From a UX perspective, this may be confusing and misleading. if it is imperative to combine the one-time creation functionality with the scheduling functionality, you have option
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
similar to New in the current design, including the None recurrence that I have suggested before. * In case a schedule doesn't exist yet - New will have both the 'General' and 'Schedule' sections, like today, allowing creating a one- time snapshot as well as creating a new snapshot schedule. * In case a schedule already exists - New will have only the 'General' side-section (the 'Schedule' side-section will not be displayed), allowing only creation of new one-time snapshots. - Schedule: * In case a schedule doesn't exist yet - two options: i. disable this button (i.e. force the user to create a new schedule via New); in this case, I agree with Shubhendu on renaming the button to Edit Schedule. - or - ii. have the dialog look exactly like New today, without the None recurrence option; so only new schedule can be created, not one-time snapshots. One-time snapshots should be created only via New. * In case a schedule already exists - the dialog will look like New, without the 'General' section (i.e. very similar to the mock-up of the Schedule dialog in the ovirt wiki today), pre-populated with the current values of the existing schedule. Your thoughts/comments are welcome. Thank you. So if we go ahead with above mentioned option (c) with Edit Schedule option it would be something as below. - Have two optiona New and Edit Schedule under Volumes - Snapshots. - New will be *only* for creating new objects, not editing/overriding existing ones. * In case a schedule doesn't exist yet - New will have both the 'General' and 'Schedule' sections, like today, allowing creating a one- time snapshot as well as creating a new snapshot schedule. * In case a schedule already exists - New will have only the 'General' side-section (the 'Schedule' side-section will not be displayed), allowing only creation of new one-time snapshots. - Edit Schedule: * In case a schedule doesn't exist yet - disable this button (i.e. force the user to create a new schedule via New) * In case a schedule already exists - the dialog will look like New, without the 'General' section (i.e. very similar to the mock-up of the Schedule dialog in the ovirt wiki today), pre-populated with the current values of the existing schedule. @Alok, need your confirmation. This option certainly looks clean to me personally but leave the final call to your descretion. Regards, Shubhendu Your comments/thoughts are welcome. Thanks! Regards, Einav - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Wednesday, December 31, 2014 12:56:44 AM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review Hi Einav, Find the comments inline. Thanks and Regards, Shubhendu On 12/30/2014 11:13 PM, Einav Cohen wrote: Thank you, Shubhendu! I have a few more comments: Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. I think that if a user already got to the Snapshots sub-tab of a specific Volume, it would seem strange that not all Snapshots-related actions for that Volume are available from there - but I will leave it to your discretion; I think that New is indeed the most important one to have also in the sub-tab. We may have the New option available under sub tab as well. Setting configuration options would only be available in Volumes main tab. Once scheduled the only way to stop snapshot creation is to provide an end date. let me try and understand what are the exact snapshot creation capabilities. consider the following use-cases (which may make absolutely no sense, just giving these as examples in order to understand the capabilities): (1) let's say that I want to do two recurring snapshots schedules in parallel for a single volume: one Monthly, and another one Weekly. Can I do that? We can have only one schedule for a volume at a time. I am assuming that I can't, i.e. there can only be one recurring-snapshot- creation schedule per volume (which you create via New and edit via Schedule) - is that correct? If so: are you blocking an attempt to create a New recurring snapshot schedule when one already exists for this Volume (e.g. disable the New button, fail a CanDoAction with a message such as Cannot create snapshot scheduling. A snapshot scheduling already exists for this Volume, etc.) or allowing override of the already- existing schedule (with a proper warning)? Even if a volume snapshot creation is scheduled user can still opt for onetime spot snapshot creation and New would be available. If my assumption is wrong, and I can have two (or more) recurring- snapshot-creation schedules per volume: how do I *edit* these schedules? what happens when I click on Schedule? which one of the two schedules will I edit? The Weekly one? The Monthly one? As there is only one schedule for a volume
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
, like today. - New will be *only* for creating new objects, not editing/overriding existing ones. It will look very similar to New in the current design, including the None recurrence that I have suggested before. * In case a schedule doesn't exist yet - New will have both the 'General' and 'Schedule' sections, like today, allowing creating a one- time snapshot as well as creating a new snapshot schedule. * In case a schedule already exists - New will have only the 'General' side-section (the 'Schedule' side-section will not be displayed), allowing only creation of new one-time snapshots. - Schedule: * In case a schedule doesn't exist yet - two options: i. disable this button (i.e. force the user to create a new schedule via New); in this case, I agree with Shubhendu on renaming the button to Edit Schedule. - or - ii. have the dialog look exactly like New today, without the None recurrence option; so only new schedule can be created, not one-time snapshots. One-time snapshots should be created only via New. * In case a schedule already exists - the dialog will look like New, without the 'General' section (i.e. very similar to the mock-up of the Schedule dialog in the ovirt wiki today), pre-populated with the current values of the existing schedule. Your thoughts/comments are welcome. Thank you. Your comments/thoughts are welcome. Thanks! Regards, Einav - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Wednesday, December 31, 2014 12:56:44 AM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review Hi Einav, Find the comments inline. Thanks and Regards, Shubhendu On 12/30/2014 11:13 PM, Einav Cohen wrote: Thank you, Shubhendu! I have a few more comments: Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. I think that if a user already got to the Snapshots sub-tab of a specific Volume, it would seem strange that not all Snapshots-related actions for that Volume are available from there - but I will leave it to your discretion; I think that New is indeed the most important one to have also in the sub-tab. We may have the New option available under sub tab as well. Setting configuration options would only be available in Volumes main tab. Once scheduled the only way to stop snapshot creation is to provide an end date. let me try and understand what are the exact snapshot creation capabilities. consider the following use-cases (which may make absolutely no sense, just giving these as examples in order to understand the capabilities): (1) let's say that I want to do two recurring snapshots schedules in parallel for a single volume: one Monthly, and another one Weekly. Can I do that? We can have only one schedule for a volume at a time. I am assuming that I can't, i.e. there can only be one recurring-snapshot- creation schedule per volume (which you create via New and edit via Schedule) - is that correct? If so: are you blocking an attempt to create a New recurring snapshot schedule when one already exists for this Volume (e.g. disable the New button, fail a CanDoAction with a message such as Cannot create snapshot scheduling. A snapshot scheduling already exists for this Volume, etc.) or allowing override of the already- existing schedule (with a proper warning)? Even if a volume snapshot creation is scheduled user can still opt for onetime spot snapshot creation and New would be available. If my assumption is wrong, and I can have two (or more) recurring- snapshot-creation schedules per volume: how do I *edit* these schedules? what happens when I click on Schedule? which one of the two schedules will I edit? The Weekly one? The Monthly one? As there is only one schedule for a volume at a time, so this is not valid scenario. Exiting single instance of schedule can be edited using the option Volumes - Snapshots - Schedule. May be if you suggest this option can be renamed to Edit Schedule. If I am comparing the terminology to the one of Calendar meeting schedule (see http://i.imgur.com/xvf5w30.png): I don't have any series objects that I can 'edit', I can see only instances, and I can edit only one global 'series' object via the Schedule button. [again: if there can only be one recurring-snapshot-creation schedule per volume, then the current design is OK, assuming the attempt to create a second snapshot-schedule for a volume is properly blocked/overridden/...] Yes, attempt to create second snapshot schedule is actually an override option. Of course spot creation is allowed in addition to the scheduled. (2) let's say that I want to do a weekly recurring snapshot scheduling for a certain
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Thanks, Shubhendu. Additional comments: ... Yes, attempt to create second snapshot schedule is actually an override option. Of course spot creation is allowed in addition to the scheduled. ... ... If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. ... From your latest responses, I conclude the following. via the New dialog, you can: (1) create a one-time snapshot (2) create a new snapshot schedule (3) override (and practically, edit) an existing snapshot schedule via the Schedule dialog, you can: (a) create a one-time snapshot (by selecting the 'None' recurrence) (b) create a new snapshot schedule (by selecting something other than 'None' in the recurrence field, given that no schedule exists yet) (c) edit an existing snapshot schedule (which is what this dialog is actually meant to do). I am not sure about (a), but it doesn't matter much for my point: New and Schedule have the exact same functionality. To be more accurate: New contains all of the needed functionality; Schedule is not really needed. The only thing that New is potentially missing is showing the values of the already-existing snapshot schedule, if one exists. I think that this may confuse to the user; I recommend to either unite both of these actions/dialogs to a single action/dialog, or separate completely some functionalists. So my recommendation is to do one of the following: (a) unite: Have a single action (Create / Schedule) which will display a dialog very similar to the New dialog, with the option to see the values of the already-existing snapshot schedule, if one exists. In this case, I would actually recommend to go with something more similar to option 2 in http://i.imgur.com/4j7hvRY.png, rather than option 3 (so the separation between *creating new* *one-time* snapshot and *editing an existing* *scheduled* snapshot is clearer). see http://i.imgur.com/ZgCp9Tz.png for an updated suggestion. - or - (b) separate: Have two completely separate actions: Create Now and Schedule. - The Create Now dialog will look like the 'General' side-section of the New dialog (i.e. without the Schedule side-section; it will allow only one-time immediate snapshot creation. - The Schedule dialog will look like the New dialog (with both 'General' and 'Schedule' side-sections) without the None recurrence, and will allow only creating a new recurring snapshot schedule (if one doesn't exist yet) or editing the existing schedule (in this case, the dialog would be pre-populated with the values of the existing schedule). I am more in favor of (b) - it seems simpler and more user-friendly in my view. Your comments/thoughts are welcome. Thanks! Regards, Einav - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Wednesday, December 31, 2014 12:56:44 AM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review Hi Einav, Find the comments inline. Thanks and Regards, Shubhendu On 12/30/2014 11:13 PM, Einav Cohen wrote: Thank you, Shubhendu! I have a few more comments: Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. I think that if a user already got to the Snapshots sub-tab of a specific Volume, it would seem strange that not all Snapshots-related actions for that Volume are available from there - but I will leave it to your discretion; I think that New is indeed the most important one to have also in the sub-tab. We may have the New option available under sub tab as well. Setting configuration options would only be available in Volumes main tab. Once scheduled the only way to stop snapshot creation is to provide an end date. let me try and understand what are the exact snapshot creation capabilities. consider the following use-cases (which may make absolutely no sense, just giving these as examples in order to understand the capabilities): (1) let's say that I want to do two recurring snapshots schedules in parallel for a single volume: one Monthly, and another one Weekly. Can I do that? We can have only one schedule for a volume at a time. I am
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Thanks Einav for the detailed review and your comments. Find below the comment inline. Will update the wiki accordingly and circulate. Team, please provide your thoughts (if conflicting) on this. Thanks and Regards, Shubhendu On 12/30/2014 05:33 AM, Einav Cohen wrote: Hi Shubhendu, First of all - very detailed wiki pages (I focused mainly on the User Experience part) - nicely done. I have a couple of comments / suggestions regarding the GUI: Snapshot action-group: - from the wiki page: A new action-group Snapshot would be introduced under actions for a volume. I assume that you will implement it similarly to the Power Management action-group (on Hosts main tab) or the Profiling action-group (on the Volumes tab), i.e. with a drop-down-like styling [http://i.imgur.com/eWRg6o8.png]? Yes. That's correct. - If the Snapshot-related actions are expected to be core/critical in the Volumes-related workflows, it makes sense to put them in the main- tab, but please consider adding them to the Snapshots sub-tab as well, in order to be consistent with other similar oVirt workflows. Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. New Snapshot dialog - Schedule section: - I suggest to implement the time-interval selection with a drop-down, rather than a radio-button group; it is more consistent with e.g. event-repeat scheduling in a calendar [http://i.imgur.com/y9Gn3wq.png], it will save real-estate within the dialog and it will be more easily readable for the user. That's a good suggestion. Will do this. - to my understanding, the New Snapshot functionality doesn't have to be recurrent; however, there isn't any way to disable the recurring aspect. Here are some suggestions to how this should be added: http://i.imgur.com/4j7hvRY.png Once scheduled the only way to stop snapshot creation is to provide an end date. Option 3 is my personal favorite - it is the simplest, and is consistent with Calendear-scheduling UI. Option 1 is my least favorite, however it is consistent with e.g. the Enable Power Management UI within the New Host dialog. Option-3 looks good to me as well. Should be doable I feel. Snapshots - Options: - I think that there are a couple of problematic issues with this dialog: * the different functionality of this dialog when a Volume is selected vs. when no Volume is selected may be unclear to the user. Agree * the fact that we can update Cluster-related parameters (which potentially affects *all* volumes in that Cluster) within a specific Volume-context dialog is a bit risky - and we don't have anything similar to that anywhere in the application today IIRC. my recommendations: * have separate Options - Cluster and Options - Volume actions; Options - Cluster should always be enabled. Options - Volume should be enabled only when a Volume is selected. Accept * Seehttp://i.imgur.com/pfRpjrH.png for my suggestion for Cluster Options vs. Volume Options. Note that from the Volume Options dialog, you may allow editing the Cluster Options by clicking on the link-button, which will either (a) open the Cluster Options dialog on top or (b) allow editing the Cluster Values inline within the already-open dialog - this should be accompanied with a clear note to the user that he is editing Cluster-related parameters from the current (Volume) context, which may affect *all* Volumes in that Cluster. Also note that in my suggestion, the user can conveniently see both the Volume values and the Cluster Values side-by-side at once, for reference. Accept Snapshots - Schedule: - to my understanding, this should be very similar (or identical) to the New Snapshot functionality? if so, we may want to simply open the New Snapshot dialog focused on the Schedule side-section (rather than the 'General' side-section, maybe already pre-populated with some values in the 'General' side-section (which will still be editable by the user) and something already pre-selected in the (focused) Schedule section. please let me know whether you think these can/should be incorporated into the design, and/or if you have any comments or questions. Accept. The snapshot create dialog itself can be used here. thanks. Regards, Einav - Original Message - From: Shubhendu Tripathishtri...@redhat.com To:de...@linode01.ovirt.org,jhern...@redhat.com, Michael Pasternakmpast...@redhat.com Sent: Monday, November 10, 2014 1:52:40 AM Subject: [ovirt-devel] Gluster Volume Snapshots - Feature review 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
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
Thank you, Shubhendu! I have a few more comments: Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. I think that if a user already got to the Snapshots sub-tab of a specific Volume, it would seem strange that not all Snapshots-related actions for that Volume are available from there - but I will leave it to your discretion; I think that New is indeed the most important one to have also in the sub-tab. Once scheduled the only way to stop snapshot creation is to provide an end date. let me try and understand what are the exact snapshot creation capabilities. consider the following use-cases (which may make absolutely no sense, just giving these as examples in order to understand the capabilities): (1) let's say that I want to do two recurring snapshots schedules in parallel for a single volume: one Monthly, and another one Weekly. Can I do that? I am assuming that I can't, i.e. there can only be one recurring-snapshot- creation schedule per volume (which you create via New and edit via Schedule) - is that correct? If so: are you blocking an attempt to create a New recurring snapshot schedule when one already exists for this Volume (e.g. disable the New button, fail a CanDoAction with a message such as Cannot create snapshot scheduling. A snapshot scheduling already exists for this Volume, etc.) or allowing override of the already- existing schedule (with a proper warning)? If my assumption is wrong, and I can have two (or more) recurring- snapshot-creation schedules per volume: how do I *edit* these schedules? what happens when I click on Schedule? which one of the two schedules will I edit? The Weekly one? The Monthly one? If I am comparing the terminology to the one of Calendar meeting schedule (see http://i.imgur.com/xvf5w30.png): I don't have any series objects that I can 'edit', I can see only instances, and I can edit only one global 'series' object via the Schedule button. [again: if there can only be one recurring-snapshot-creation schedule per volume, then the current design is OK, assuming the attempt to create a second snapshot-schedule for a volume is properly blocked/overridden/...] (2) let's say that I want to do a weekly recurring snapshot scheduling for a certain volume. In addition to that weekly recurring snapshots, I want to take a one-time snapshot of this volume right now. Can I do that? If so: then my suggestion [http://i.imgur.com/4j7hvRY.png, option 3] is indeed valid; I am assuming that the user can create, per volume: one recurring snapshot schedule + unlimited one-time snapshots. [If the user can create two (or more) recurring snapshot schedules - see (1) above]. need to make sure that the user is able to create a New snapshot with the Weekly recurrence schedule, and then another New snapshot(s) with the None recurrence schedule, which will create the one-time snapshot(s) immediately, and that the schedule of the Weekly snapshot can be edited via the Schedule option. If not (i.e. the user can create only one recurring snapshot schedule, and that's it - no additional recurring snapshot schedules, no one-time immediate snapshots, etc.), then my suggestion is invalid, and a 'None' recurrence is not needed. In this case, just need to make sure that the 'Schedule' side-section of the dialog will be pre-populated with the most common/reasonable recurrence schedule, in case the user will not touch it. BTW, if this is indeed the case, then there is probably no need for both 'New' and 'Schedule' buttons - only 'Schedule' is sufficient. Accept. The snapshot create dialog itself can be used here. Just need to make sure to change its title accordingly (to 'Schedule Snapshot' or something similar; right now it says New Snapshot in the wiki). I assume that this dialog can be used for: (a) creating a New snapshot schedule (which should look very similar to the 'New Snapshot' dialog, maybe with some pre-populated values, maybe without the 'None' option in the Recurrence drop-down). - and/or - (b) editing the already-existing schedule (in this case, fields that cannot be edited should be disabled). I hope I was clear - please let me know if you have any questions or comments. Thanks again! Regards, Einav - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Tuesday, December 30, 2014 7:09:51 AM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review Thanks Einav for the detailed review and your comments. Find below the comment inline. Will update the wiki accordingly and circulate. Team, please provide your thoughts (if conflicting) on this. Thanks and Regards, Shubhendu On 12/30/2014 05:33 AM, Einav Cohen wrote: Hi Shubhendu, First of all - very detailed wiki pages (I
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
will be pre-populated with the most common/reasonable recurrence schedule, in case the user will not touch it. BTW, if this is indeed the case, then there is probably no need for both 'New' and 'Schedule' buttons - only 'Schedule' is sufficient. Accept. The snapshot create dialog itself can be used here. Just need to make sure to change its title accordingly (to 'Schedule Snapshot' or something similar; right now it says New Snapshot in the wiki). I assume that this dialog can be used for: (a) creating a New snapshot schedule (which should look very similar to the 'New Snapshot' dialog, maybe with some pre-populated values, maybe without the 'None' option in the Recurrence drop-down). If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. - and/or - (b) editing the already-existing schedule (in this case, fields that cannot be edited should be disabled). As above. I hope I was clear - please let me know if you have any questions or comments. Thanks again! Regards, Einav - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Tuesday, December 30, 2014 7:09:51 AM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review Thanks Einav for the detailed review and your comments. Find below the comment inline. Will update the wiki accordingly and circulate. Team, please provide your thoughts (if conflicting) on this. Thanks and Regards, Shubhendu On 12/30/2014 05:33 AM, Einav Cohen wrote: Hi Shubhendu, First of all - very detailed wiki pages (I focused mainly on the User Experience part) - nicely done. I have a couple of comments / suggestions regarding the GUI: Snapshot action-group: - from the wiki page: A new action-group Snapshot would be introduced under actions for a volume. I assume that you will implement it similarly to the Power Management action-group (on Hosts main tab) or the Profiling action-group (on the Volumes tab), i.e. with a drop-down-like styling [http://i.imgur.com/eWRg6o8.png]? Yes. That's correct. - If the Snapshot-related actions are expected to be core/critical in the Volumes-related workflows, it makes sense to put them in the main- tab, but please consider adding them to the Snapshots sub-tab as well, in order to be consistent with other similar oVirt workflows. Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. New Snapshot dialog - Schedule section: - I suggest to implement the time-interval selection with a drop-down, rather than a radio-button group; it is more consistent with e.g. event-repeat scheduling in a calendar [http://i.imgur.com/y9Gn3wq.png], it will save real-estate within the dialog and it will be more easily readable for the user. That's a good suggestion. Will do this. - to my understanding, the New Snapshot functionality doesn't have to be recurrent; however, there isn't any way to disable the recurring aspect. Here are some suggestions to how this should be added: http://i.imgur.com/4j7hvRY.png Once scheduled the only way to stop snapshot creation is to provide an end date. Option 3 is my personal favorite - it is the simplest, and is consistent with Calendear-scheduling UI. Option 1 is my least favorite, however it is consistent with e.g. the Enable Power Management UI within the New Host dialog. Option-3 looks good to me as well. Should be doable I feel. Snapshots - Options: - I think that there are a couple of problematic issues with this dialog: * the different functionality of this dialog when a Volume is selected vs. when no Volume is selected may be unclear to the user. Agree * the fact that we can update Cluster-related parameters (which potentially affects *all* volumes in that Cluster) within a specific Volume-context dialog is a bit risky - and we don't have anything similar to that anywhere in the application today IIRC. my recommendations: * have separate Options - Cluster and Options - Volume actions; Options - Cluster should always be enabled. Options - Volume should be enabled only when a Volume is selected. Accept * Seehttp://i.imgur.com/pfRpjrH.png for my suggestion for Cluster Options vs
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
- Snapshots - New option) In this case, just need to make sure that the 'Schedule' side-section of the dialog will be pre-populated with the most common/reasonable recurrence schedule, in case the user will not touch it. BTW, if this is indeed the case, then there is probably no need for both 'New' and 'Schedule' buttons - only 'Schedule' is sufficient. Accept. The snapshot create dialog itself can be used here. Just need to make sure to change its title accordingly (to 'Schedule Snapshot' or something similar; right now it says New Snapshot in the wiki). I assume that this dialog can be used for: (a) creating a New snapshot schedule (which should look very similar to the 'New Snapshot' dialog, maybe with some pre-populated values, maybe without the 'None' option in the Recurrence drop-down). If the option Volumes - Snapshots - New selected, the dialog opens with pre-populated snapshot name prefix and Recurrence type selected as None by default. This effectively is one time snapshot creation. If this is first time and user wants to schedule the snapshot creation, he/she can change the recurrence type and provide details. Snapshot creation is scheduled in this case. Later, it user wants to edit the schedule, he/she needs to select option Volumes - Snapshots - Schedule (may be for this reason only I want to call it Edit Schedule). So effectively option Volumes - Snapshots - Schedule is meant for only re-scheduling the snapshot creation. If its not yet scheduled dialog opens with recurrence type selected as None. - and/or - (b) editing the already-existing schedule (in this case, fields that cannot be edited should be disabled). As above. I hope I was clear - please let me know if you have any questions or comments. Thanks again! Regards, Einav - Original Message - From: Shubhendu Tripathi shtri...@redhat.com To: Einav Cohen eco...@redhat.com Cc: de...@linode01.ovirt.org, rhsc-dev rhsc-...@redhat.com Sent: Tuesday, December 30, 2014 7:09:51 AM Subject: Re: [ovirt-devel] Gluster Volume Snapshots - Feature review Thanks Einav for the detailed review and your comments. Find below the comment inline. Will update the wiki accordingly and circulate. Team, please provide your thoughts (if conflicting) on this. Thanks and Regards, Shubhendu On 12/30/2014 05:33 AM, Einav Cohen wrote: Hi Shubhendu, First of all - very detailed wiki pages (I focused mainly on the User Experience part) - nicely done. I have a couple of comments / suggestions regarding the GUI: Snapshot action-group: - from the wiki page: A new action-group Snapshot would be introduced under actions for a volume. I assume that you will implement it similarly to the Power Management action-group (on Hosts main tab) or the Profiling action-group (on the Volumes tab), i.e. with a drop-down-like styling [http://i.imgur.com/eWRg6o8.png]? Yes. That's correct. - If the Snapshot-related actions are expected to be core/critical in the Volumes-related workflows, it makes sense to put them in the main- tab, but please consider adding them to the Snapshots sub-tab as well, in order to be consistent with other similar oVirt workflows. Yes that's true for most of the cases. But having Options setting from sub-tab, not sure if that's correct. May be New is fine. New Snapshot dialog - Schedule section: - I suggest to implement the time-interval selection with a drop-down, rather than a radio-button group; it is more consistent with e.g. event-repeat scheduling in a calendar [http://i.imgur.com/y9Gn3wq.png], it will save real-estate within the dialog and it will be more easily readable for the user. That's a good suggestion. Will do this. - to my understanding, the New Snapshot functionality doesn't have to be recurrent; however, there isn't any way to disable the recurring aspect. Here are some suggestions to how this should be added: http://i.imgur.com/4j7hvRY.png Once scheduled the only way to stop snapshot creation is to provide an end date. Option 3 is my personal favorite - it is the simplest, and is consistent with Calendear-scheduling UI. Option 1 is my least favorite, however it is consistent with e.g. the Enable Power Management UI within the New Host dialog. Option-3 looks good to me as well. Should be doable I feel. Snapshots - Options: - I think that there are a couple of problematic issues with this dialog: * the different functionality of this dialog when a Volume is selected vs. when no Volume is selected may be unclear to the user. Agree * the fact that we can update Cluster-related parameters (which potentially affects *all* volumes in that Cluster) within a specific Volume-context dialog is a bit risky - and we don't have anything similar to that anywhere in the application today IIRC. my recommendations: * have separate Options - Cluster and Options - Volume actions; Options - Cluster should always be enabled. Options - Volume should
Re: [ovirt-devel] 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 jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi
shtri...@redhat.com,devel@ovirt.org,Michael Pasternak
mpast...@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
Re: [ovirt-devel] 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 jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi shtri...@redhat.com,devel@ovirt.org,Michael Pasternak
mpast...@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@ovirt.org
http://lists.ovirt.org
Re: [ovirt-devel] 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 jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi shtri...@redhat.com,devel@ovirt.org,Michael
Pasternak mpast...@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@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.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
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.
--
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.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Gluster Volume Snapshots - Feature review
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 jhern...@redhat.com
Date: 09/12/2014 18:51 (GMT+05:30)
To: Shubhendu Tripathi shtri...@redhat.com,devel@ovirt.org,Michael Pasternak
mpast...@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.
--
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.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
