[ovirt-devel] Gluster Volume Snapshots - Feature review
Einav Cohen
ecohen at redhat.com
Tue Dec 30 17:43:13 UTC 2014
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" <shtripat at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: devel at linode01.ovirt.org, "rhsc-dev" <rhsc-dev at 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. "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 Tripathi"<shtripat at redhat.com>
> >> To:devel at linode01.ovirt.org,jhernand at redhat.com, "Michael
> >> Pasternak"<mpastern at 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
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >>
>
>
More information about the Devel
mailing list