Adding clone-vm design to knikubevirt folder

[Ranelim]

Adding 'clone-vm' workflow. Cloning a VM allows the user to quickly create an identical copy of a virtual machine while powered off.

Summary:

• Cloning is accessed from the VM List View
• Selecting "Clone" from a VM's kebab will open the 'Clone VM' modal
• Cloned VM shuts down during the cloning process (alert within the modal)
• Displaying toast notification for cloning success or failure.
• In case of success, the new VM will be added to the VM list with “Transitioning” filter automatically re-enabled.

@openshift/team-ux-leads

[andybraren]

Congrats on your first PR Ran! 🙂

Some of the legacy issues that Colleen noted in #163 (particularly 2 and 3) apply to this design as well. I also notice a few other things:

• The left-hand navigation is out of date. It's not super relevant to cloning VMs, but it would be nice to more closely align with the VM List design that Liz merged into this repo already.
• The Status cell should include text labels to the right of each icon (also shown in the VM List doc)
• The organization of the action kebabs is outdated as well (might want to double-check)

The images in the UI-vm-list folder (within our shared Google Drive folder) include most of the updates for the above. Could you update this PR with those images and/or make updates that would resolve some of #163 as well?

[lizsurette]

Yes, congrats on the first PR!!

I don't have anything additional to call out past what @andybraren has said. It would be great to hear what @beanh66 thinks after you'd made the above changes.

[matthewcarleton]

Looks great Ran! Just a few nits :)

[matthewcarleton]

Are we ok with using "VM" in place of virtual machine? @lizsurette have you thought about this at all?

[lizsurette]

@matthewcarleton - I went back and forth when I created the initial PR with a starter list. Since it's repeated a ton I went with the shorter option, but maybe others can comment who would likely be the audience of this page in reviewing/referring back to designs... @beanh66 @cshinn @bmignano @alimobrem - This is referring to what we call the link in the main homepage to these features as well as the header title.

[matthewcarleton]

should this read "all item filters should be turned off by default"?

[Ranelim]

Right, fixing it in the next commit

[matthewcarleton]

can we replace "disabled" with "inactive" and "re-enabled" with "activated" to be more accurate.

[Ranelim]

fixing it in the next commit

[Ranelim]

I think this task should be reopened based on Colleen's comments on #163.

Once I add text labels to the status icons, I notice something weird:
Status icon for Off & cloned VM is a 'lock': This is a bit confusing cause 'lock' does not indicate if an item is down or cloned. It simply indicates it is locked. Thinking the VM is locked (but on what status) contradicts the actions available on the kebab (like Run).

Another weird thing is that the new clone does not indicate a direct relation to the original, besides being one on top of the other. The new clone has it's own action (Stop Cloning), but it is a duplication from the original. Basically, the new upcoming clone does not exist yet.

We might create a better visual and textual connection, and have the two VMs share the same action.
Similar to Copy Paste modal:

This is just an idea, don't kill me just yet. It creates a problem with the 'Created' column. But it is worth breaking alignment from the rest of the items on the list cause something is happening here. Also, Colleen mentioned that we might wanna remove that column

[andybraren]

Status icon for Off & cloned VM is a 'lock': This is a bit confusing.

Agreed, this is confusing. Sorry for missing that 🙂. Here's the original image for reference:

I haven't thought through this fully, but maybe both the VM being cloned from and the almost-VM being cloned should have pficon-in-progress icons instead of one being a lock. The VM being cloned from could have a status of "Cloning" and the almost-VM could have a status of "Creating" since that's sort of what's happening. Both statuses would be blue and clicking them would reveal a popover like this (a new pattern we're introducing soon) explaining what's happening in more detail.

Looking at this again, I also wonder if the almost-VM would even be shown in this list at all until it's fully created. It might be worth confirming that with the devs.

We might create a better visual and textual connection

Note that since the names of VMs could be very long, a status of "Cloning from VMname" could also be very long and get cut off. The full VM name could definitely be shown in the status popover though. "Cloning" and "Creating" might be enough to imply the connection, but feel free to consider other words/representations.

But it is worth breaking alignment from the rest of the items on the list cause something is happening here.

I agree that the Created column should probably be removed, and maybe the Node column too. That decision will apply to all of our mockups, so we'll need to make sure that doesn't break any other flows. Breaking alignment like this wouldn't be very easy to do from a code perspective - removing a column is much easier.

The new clone has it's own action (Stop Cloning), but it is a duplication from the original

I'm not sure if this is consistent with what the rest of OpenShift does (yet?), but at the very bottom of the VM List documentation in the "States and Actions" section we proposed doing something like this:

When a VM is in a transitional state (cloning, migrating, taking a snapshot, etc.) any unavailable actions in the kebab are disabled and the original action (“Clone”) is replaced with a cancel action (“Cancel Clone”).

This seems like it might be easier to maintain from a code perspective than having different action menus depending on the state of the VM, and makes it clearer to the user that some actions they're used to seeing on VMs aren't available because of that specific VM's current status. What do you think?

[matthewcarleton]

looking at this quickly, I think keeping the VM that is being created from the clone should be visible. If we can ensure that the new VM will always be below the VM it is coming from we could have a status of "being cloned" and "creating clone". It would be difficult to provide longer strings but I agree with @andybraren that we can offer further details in the popup.

[Ranelim]

• I agree that we need to keep the upcoming clone somewhere on the page. I also think that as long as that upcoming clone will not have a unique preview (like the entire row with low opacity) it is a problem.
• I agree with sticking to disabling unavailable actions, it's usually more user-friendly.

I do think we need to simulate a 'Copy Paste' behavior. Adding another idea:
We may use an on-page notification for the upcoming VM, with more details and unique action, thus lifting all the heavy load form the list itself, which we cannot customize too much.
I saw that blue component here

If we do that, the origin VM item can go either of the two following options:

A. Adding unique action on the Kebab flyout menu.

B. Disabling the kebab, and adding an action under the status.

I know, both of these options require customization, but I don't like the idea of not having 'Stop cloning' action right next to where the user sees the VM itself. I also don't think that adding 'Stop cloning' to the kebab action list is a good idea.
We may want to toggle 'Clone' with 'Stop cloning' but I guess we want to provide the user a way to create another clone while the VM is down.

WDYT?

[matthewcarleton]

@Ranelim I am more in favour of adding the "Cancel Cloning" to the kebab in place of where the "clone" action is. We can rely on users looking there for actions. If we disable the kebab entirely it could be confusing because you don't know why it's disabled.
+1 on the blue component :). I think we could align a bit better with what Patternfly offers in terms of inline notifications. Depending on if we go with PF3 or PF4. Maybe @andybraren can offer more info on that "blue component" :) Either way I think we could drop the kebab and have an inline "Cancel Clone" action to be a bit more accessible.

The "Off for cloning...24%" reads a bit strange to me. I like what @andybraren suggested with the in progress icon. Does "Being Cloned" make sense? We have the ability to offer more information here too via the popup dialog. I don't think we need to overload the status here if we are going to provide the same information more efficiently via that notification above the list.

[andybraren]

Good discussions in this PR 🙂

We may want to toggle 'Clone' with 'Stop cloning' but I guess we want to provide the user a way to create another clone while the VM is down.

Good point. Cloning could take several minutes depending on the size of the VM's disk/s, but I wonder if this is even technically possible. It's probably worth asking devs whether this is a use case we should support. If it is, then clicking the "Stop cloning" action might have to list all of the VMs being cloned in a modal, which complicates things.

I saw that blue component here

This is a little tricky. In that doc specifically, the blue and red boxes you see may turn into parts of a Dashboard-like "Health" card for that specific object in the future. That design is still being worked on.

There are existing OpenShift designs that use blue boxes (one example), but they're typically used for educational text or to guide the user to take one specific action. Maybe an OpenShift Designer can chime in, but using them on a Table page to emphasize "a process currently undergoing for this page" might be unconventional.

There are a few other things I'd wonder about. If 4 VMs are cloning, would 4 blue boxes appear? When those boxes disappear and the table starts to jump up, would users find that annoying? Is cloning a VM such an important action that users would expect to see it emphasized in Table pages?

I agree that a way to see all ongoing, user-activated operations like VMs cloning, Hosts provisioning, Cluster operators updating, etc. is important, but I wonder if a Dashboard "Activity" card located somewhere else would be the most appropriate place to see the progress of all of those things.

I know, both of these options require customization, but I don't like the idea of not having 'Stop cloning' action right next to where the user sees the VM itself. I also don't think that adding 'Stop cloning' to the kebab action list is a good idea.

Is "Stop cloning" a common action for a user who just initiated that process? I would assume not, and since it's a (potentially) destructive action I'd be okay with putting it an additional click away within the action kebab.

The "Off for cloning...24%" reads a bit strange to me. I like what @andybraren suggested with the in progress icon. Does "Being Cloned" make sense? We have the ability to offer more information here too via the popup dialog.

Some of our Metal3 designs simplify the truth in a similar way. A VM might be "Off", but the user probably only cares that the clone action they started is "In Progress" and still happening, so that's the status that we show.

Maybe "Cloning (50%)" for the original VM and "Creating (50%)" for the new one (since it kinda is)? I agree that status popovers (maybe even with a progress bar) could help here, and could even include a "Cancel Clone" action.

[Ranelim]

The more I think about it, mentioning both the original VM and the upcoming clone is not that important, cause they are clones, Identical.

What we want toe user to know, by that order, is:

1. original VM is down for cloning.
2. status of the cloning process.
3. ability to abort to get that Vm running again.
4. See the new clone independently on the VM list.

So, I assume that mentioning "VM status: Cloning" on the VM list is enough to know there is a new clone coming up.

We also want to show the progress cause it takes a few minutes.
It can be hidden or side by side with a view details link. The question is if it should be on the VM list item or in the toast notification which already alerts that the VM has started.

Whatever we decide, this behavior should also affect other "under progress" statuses like "importing" and "migrating".

I agree that placing the "stop cloning" action in the kebab is ok. It is a destructive action so it should be followed by a confirmation modal (do we use that on OS?).

Please note that the attached files are more of a draft, just to test the waters:

[matthewcarleton]

@Ranelim I really like this idea. I think we could accomplish this by aligning with some previous design patterns that have been established. What if we had the status text "Cloning (50%)" as @andybraren suggested and when clicked the dialog would provide the progress bar, name of new VM and name of cloned VM as well as the cancel action?
I think we could still have the kebab have the available action of "cancel clone" to provide consistency and an easy way to cancel it.
The toast notification is a nice feature too, which I think we can keep here as a future enhancement once they are available in Openshift.

@andybraren what you do think?

[andybraren]

So, I assume that mentioning "VM status: Cloning" on the VM list is enough to know there is a new clone coming up.

I agree. It might be worth researching to see what happens in other products, but this seems more straightforward from both a UX and a code perspective. I'm fine with not showing the "ghost" VM until it actually finishes.

I agree that placing the "stop cloning" action in the kebab is ok. It is a destructive action so it should be followed by a confirmation modal (do we use that on OS?).

We do use confirmation modals for other actions and using one here seems very appropriate. The "Stop Cloning" primary action button should be blue in your draft mockup.

What if we had the status text "Cloning (50%)" as @andybraren suggested and when clicked the dialog would provide the progress bar, name of new VM and name of cloned VM as well as the cancel action?

I agree, the new status popover pattern shown here seems like the right approach and would basically contain what your second screen shows (maybe with a little more descriptive text). The "Stop Cloning" action would be the blue action in the bottom-left corner of the popover.

One thing I'm uncertain about is what to call the action that stops/cancels the clone operation.

Our original screen's kebab action was "Cancel Clone" to be consistent with "Cancel Migration" and "Cancel Snapshot". But if we show a confirmation modal, the two buttons at the bottom will be "Cancel" (which closes the modal) and "Cancel Clone". That could be slightly confusing.

Here's the old screen:

Should we change these actions to "Stop Cloning", "Stop Migrating", and "Stop Snapshot"? @matthewcarleton I think I remember discussing this a while back, but we may as well clean this up now.

[matthewcarleton]

@andybraren I don't feel too strongly about replacing cancel with stop but agree that whatever approach we take should be consistent everywhere. @Ranelim how do you feel?

[Ranelim]

About the label:
To me, "Cancel" say more "Stop and Delete", while "stop" might be interpreted as "Pause"? maybe it's just my English. But as Andy suggested, "cancel" becomes a problem at confirmation modals.
Maybe we can say "Abort" but that sound so "Red Alert".
I guess we just need to decide which option is least problematic. I don't know myself.

About that modal:
I usually try to avoid having primary buttons on a destructive confirmation modal. People just click whatever, sometimes. I think it is worth creating a new design pattern in this case too. But I won't break the PR for that.

@andybraren About the modal on the second screen, do we use a "Close" button too, or rely only on the 'X'?

[Ranelim]

I went ahead with "stop". "Cancel cloning" looks funny in the modal.
I also kept the "Off" icon cause I think it's important to hint that the VM is off, and it's ok with "cloning" label next to it (but it's just me).

@matthewcarleton, @andybraren, WDYT? R we closer to a now commit?

[lizsurette]

@Ranelim - Looks great. Very close to ready in my opinion.

A few nitpicks on the "Stop Cloning" modal...we should bring this in alignment with the current OpenShift styling I think. Here's an example from trying to Delete a Pod:

Also a few minor typos... "Prosess" -> "Process" and "Stoping" -> "Stopping".

Last step would be to get a +1 from @beanh66 :)

[andybraren]

"Stop" seems fine to me. Better than "Abort", and although "Stop" could be interpreted as "Pause" it's still a better option than having two buttons with the word "Cancel" in them.

@andybraren About the modal on the second screen, do we use a "Close" button too, or rely only on the 'X'?

A "Cancel" button is always included I believe, but it does the same thing as clicking the X. I see your latest screen includes it.

Sorry to be so nitpicky, I know it gets annoying (especially in GitHub where changes are harder), but we're definitely close! Just a few more things based on your latest screens. 🙂

• The Status Popover could use a "Stop Cloning" quick action in the bottom-left corner, similar to this example.
• "Virtual machines" should be "Virtual Machines" in the left-hand navigation
• "offline" should be "Offline" in the filter bar
• "Transitioning" should be "In Progress" in the filter bar, or at least that's what our VM List doc uses (my fault for the inconsistency) - this can't be implemented at the moment but our designs should standardize on one word to be ready for the day that it can
• I believe the word "cloning" in the title bar and primary button of the modal should be capitalized to "Cloning" (I'm pretty sure this is what all other modals in OpenShift do)
• I wonder if the Stop modal should include a percent completion at all. What happens when it reaches 100%? Does it auto-close? Would showing the percent increasing nudge the user into making a quick decision? Do we want that?
• The README.md file in this repo should be updated to include a link to this documentation so that it appears on the site - Liz created a section for KubeVirt stuff and "Clone VM" is an item in there

[andybraren]

Oh, I’m now realizing that this PR and the VM List doc also use the old lightning bolt icon for Running - we now use the fa-refresh icon instead, documented here.

[matthewcarleton]

@Ranelim this is looking really close!
+1 to all the above comments

@andybraren

I wonder if the Stop modal should include a percent completion at all. What happens when it reaches 100%? Does it auto-close? Would showing the percent increasing nudge the user into making a quick decision? Do we want that?

I'd say we don't want percentage in there for how it complicates things in general like you're pointing out and also the complexity of building the thing. It would have to be dynamically updating as it progressed which seems awkward in this scenario.

Should we leave all list view updates for another PR?

[beanh66]

Thanks @Ranelim! I left a minor comment around toast notifications. Let me know what you think.

[beanh66]

I mentioned this in another PR from @yfrimanm as well but in general we don't use toasts in the console to indicate a process has started when that process was just activated by the user. We used to have these type of toasts in 3.x and due to user feedback have gotten away from notifying users of their own actions. For a process that is not instantaneous, it's still valid to notify via toast when it completes. Toasts are not currently in the console so if we add them, they should use PF4.

[Ranelim]

I agree. As long the user has some feedback that something happened, we should remove them.

• They are not ideal for displaying undergoing processes
• Duplication to the item status on the list
• underdefined and unused in our current system.

[Ranelim]

@andybraren Please note that I changed the clone source VM actions from only 'Run' and 'Delete' disabled to all, except 'Clone' which toggles to 'Stop Cloning' (In case it was under everyone's radar on previous iterations).

I think it clears out some complications, but also creates new ones. The user can't create more than one clone at a time. Without adding a unique for cloning action, we should consider adding 'Number of clones' on the 'Clone VM' modal. It means that renaming them probably occur only after the cloning process is done. We can figure all this out on the next PR.

[andybraren]

@andybraren Please note that I changed the clone source VM actions from only 'Run' and 'Delete' disabled to all, except 'Clone' which toggles to 'Stop Cloning' (In case it was under everyone's radar on previous iterations).

Makes sense to me. New confirmation modal looks good too except one nit: "delene" to "delete".

The user can't create more than one clone at a time. Without adding a unique for cloning action, we should consider adding 'Number of clones' on the 'Clone VM' modal. It means that renaming them probably occur only after the cloning process is done. We can figure all this out on the next PR.

Leaving this for a future PR sounds good, and I agree that the design for this capability is probably straightforward. Thinking about and mocking up a possible future feature is fine, but I'd want to confirm that this is A) possible on the technology side with little overhead or ongoing maintenance and B) a common user need and user-driven feature request. Googling around I see some small forum threads from ~2009 about creating multiple clones at once with some people noting that there's a performance impact of doing so that would need to be considered on the implementation side.

[beanh66]

LGTM @Ranelim!

Only one minor comment on maybe changing to a destructive button for stop clone. Let me know what you think and I'm happy to merge whenever you feel it's ready :)

[beanh66]

@Ranelim I think the Stop Cloning button is a destructive action so it should be red.

[lizsurette]

@Ranelim - after the merge I noticed there isn't a link to this from the main page. Would do a followup PR to update the Readme file to include a link to this new documentation? Should be a very quick merge :)

[beanh66]

Sorry should have caught that before merging!