-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#515]Adds migration scheduling to complete mapping list #514
[#515]Adds migration scheduling to complete mapping list #514
Conversation
@Yadnyawalkya should this be gaprindashvili/yes? piggy back off that same bz? |
@AllenBW I'm a little confused as to why Unschedule is required before the plan can be scheduled again. Does running the plan not get rid of its schedule? I think this will be very confusing to the user. If an Unschedule button needs to appear for every completed plan, then I don't want to merge this before GA. Let's take the time to do it right. |
@vconzola no need for confusion, When we have a schedule on the record, something that was used to kick off a migration, it stays on the record until removed. But that makes sense, we might want to know when the last migration was scheduled to run, or maybe not? UX guidance on how to "do this right" would be most appreciated. Do we clear the past schedule upon migration completion, losing that record? Provide an edit button to modify the existing schedule? Do we ignore all past schedules and treat it as a new one? |
@AllenBW I think the best UX is to clear the past schedule upon migration completion so that the options on a Completed plan become Schedule, Retry, and Archive with Archive being hidden under a kebab. I'll create a mockup. |
@AllenBW Thinking about this does make me think of another edge case, however. Any idea what happens today if a scheduled migration fails to run for some reason, e.g., network problem? Do we indicate that in the UI at all? Leads me to think that we need an error in the plan list view and also to prioritize rescheduling migrations (vs. unschedule and schedule again like we have today). |
@vconzola 👍 ok can clear upon completion, will have that change up in a few shakes. To your other question I believe this would fail just as a normal migration, to my knowledge we aren't provided any indication as to why a schedule failed to run. |
@AllenBW I'm talking about the case where the request is never sent so the migration never starts at the scheduled time. Is this possible and a case we need to consider? |
@vconzola Not sure I follow, the request is never sent? All api errors are handled by miq, so if theres an issue with setting the schedule we'll know then. If your saying what happens in the case the schedule fails to run? Not sure we get any feedback to that effect. |
@AllenBW That's the case I was thinking of - the schedule fails to run. Do we need to address this possibility? |
@vconzola how abouts we chat this over in the standup 👍 |
@AllenBW Here's a mockup with a schedule button added for failed Completed plans and the Archive feature moved under a kebab. |
Late to the party, but this was a red flag for me:
I agree with @vconzola that the remaining options should be Schedule, Retry, and Archive, and we shouldn't have to unschedule. But I don't know how I feel about losing the history of what happened. Maybe a new feature for down the line should be Migration History? I can just imagine a user realizing something was wrong with a completed migration and wanting to go look at how it was configured. |
Archive as a kebab is a problem because we have a whole list item wrapped in a click event. So when you click on the kebab, rather than seeing the dropdown you are redirected to the completed migration. Working on getting the kebab to behave like the rest of the buttons, independent of the row click event, but just in case thats not immediately possible... we can either....
|
5154132
to
7ac47fb
Compare
cedc7ff
to
588e152
Compare
@AllenBW have you tried stopping propagation on the kebab's event handler? |
@mturley yes. and about a billon other things. |
ManageIQ/manageiq-api#436 is the pr we need for this to work... Is ready for review from other parties whenever they can spare the cycles |
@@ -100,7 +100,7 @@ export const initialState = Immutable({ | |||
isFetchingNetworks: false, | |||
isRejectedNetworks: false, | |||
scheduleMigrationModal: false, | |||
scheduleMigrationPlanId: null, | |||
scheduleMigrationPlan: {}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to set the default as an empty string here due to this line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eeeeek nope, good catch, that needs to be an object, cuz the plan is an object
List components share buttons rather than duplicating in each
588e152
to
40734eb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Little thing that might cause an error, not sure if this case is possible though.
scheduleTime, | ||
plan: { id: planId } | ||
} = payload; | ||
const scheduleId = (payload.plan.schedules && payload.plan.schedules[0].id) || null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be a TypeError
if payload.plan.schedules
is an empty array (truthy but [0]
is undefined). Not sure if we'll ever hit that case, but we should maybe do:
const firstSchedule = payload.plan.schedules && payload.plan.schedules[0];
const scheduleId = firstSchedule ? firstSchedule.id : null;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it exists, as in if payload.plan.schedules
passes, there will be something inside 👍
body = scheduleTime | ||
? { | ||
action: 'edit', | ||
resource: { run_at: { ...payload.plan.schedules[0].run_at, start_time: scheduleTime } } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A nice DRY firstSchedule
could be used here as well
{__('Unschedule')} | ||
</Button> | ||
)} | ||
<ScheduleMigrationButton |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the one little potential issue (maybe not even an issue?) this looks great to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested against the pending manageiq-api branch, and looks good to me 🎉
Looks like ManageIQ/manageiq-api#436 has been merged. I've looked at the new kebab code, and it looks good to me. In the interest of time, I've gone ahead and taken a look at the CI failure. We can replace this line with something like const archiveButton = item.find('a').filterWhere(link => link.text() === 'Archive'); to fix the failing test case |
ESlint rightfully doesn't like this onclick, but its necessary to allow for the kebab button to work as intended rather than being overridden by the parent onclick
7b0ee94
to
0c65c6f
Compare
Updated! @michaelkro |
🎉 |
…uling-to-completed-list [#515]Adds migration scheduling to complete mapping list (cherry picked from commit 5e21f6d) https://bugzilla.redhat.com/show_bug.cgi?id=1608351
Gaprindashvili backport details:
|
Fixes #515
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1564255
Dependencies: ManageIQ/manageiq-api#436
What we look like
OK OK so there's an issue with the using the kebab (described here) so we're using buttons for now. We now hide "stale migrations" from the completed list, those migrations that happened in the past, and allow the user to schedule anew but there's an issue with the api serializing the keys (?) or something like that, so rescheduling an already failed migration doesn't so much work @bdunne is looking into da issue...
its a long video, but worth a watch!Its now an old video, but still worth watchingEdit: if this seems clunky, having to unschedule to re schedule, s' something that can be improved upon, but I don't want to make any promises before that it could be done by friday, so here seems like a good stopping spot... 🤞