[
http://opencast.jira.com/browse/MH-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24635#comment-24635
]
Adam Hochman edited comment on MH-6671 at 2/21/11 6:18 PM:
-----------------------------------------------------------
Benjamin and I came up with a workable solution for 1.1.
Problem recap: UI relies on the workflow service, which partially relies on
capture-admin, for recording status. When a capture agent fails to start, the
failure isn't communicated to the capture-admin service and the workflow
service is essentially in the dark. This results in "missed" recordings still
appearing in the upcoming filter. The approaches suggested thus far fix this
problem but cause issues with the all recording filter. Even if we had more
sophisticated querying capabilities to exclude missed recordings from the
workflow service, we still need to account for them in the UI.
Solution: The path of least resistance for 1.1 is for the UI to determine
whether missed recordings "Failed to Start?" rather than rely on the CA or
capture-admin. These recordings never received any official status from the
CA, so they're interpreted as likely to have failed but needed to be looked
into (a limbo condition). Judy, if you have a better status for this please
suggest one. This means that recordings with this status will still appear
under upcoming and all (and accounted for in stats) but the user can either
ignore them or keep them around as a reminder. Perhaps in the future we can
have the user manually put them into a failed state if they really failed. If
the capture agent eventually starts up, these recordings will naturally no
longer appear under upcoming.
See irc chat below for more details....
bwulff: I still think the only way to get rid of recordings from the past that
never made it to become a workflow, putting them into STOPPED state would be
the easiest.
[09:18am] bwulff: at least from the UI side
[09:18am] bwulff: don't know the technical implications on the back end
[09:22am] adhocbot: do #1 and #2 still exists as problems?
[09:22am] adhocbot: just ignore the welcome page question. I'll just find it.
[09:22am] bwulff: yes
[09:23am] bwulff: would be the solution to #1 to make the stats endpoint filter
by date
[09:24am] bwulff: but problem #2 is: on all we query the instances endpoint for
just about everything but the STOPPED workflows
[09:24am] bwulff: we cannot filter by date because we would then filter out
also the recordings that are finished , on hold etc (since they were already
recorded)
[09:25am] adhocbot: so "fromDate" ensures that missed recordings don't sure up
in the upcoming and all filter. correct?
[09:25am] bwulff: and we cannot query instances for example for: every 'full'
workflow + every 'schedule' workflow except those from the past
[09:25am] bwulff: fromDate filters the whole result set
[09:26am] bwulff: in upcomming this solves our problem since we only look for
schedule workflows
[09:27am] bwulff: on All we want every workflow instance (including full).
using fromDate here then applies to the whole result set, thus filtering out
every workflows instance that hase a mediapackage with start date before the
current time
[09:28am] adhocbot: understood. and the problem ultimately is when the CA
fails to start and the CA remains in upcoming. right?
[09:28am] bwulff: hence we would see the same data like on upcomming (only
scheduled recoridngs have a start date in the future)
[09:28am] bwulff: right
[09:29am] adhocbot: for other capture errrors, the capture-admin deals with
these correctly and they're displayed in the failed section?
[09:29am] bwulff: the workflows representing recordings that were not conducted
should reflect this fact
[09:29am] bwulff: a sec, let me ask rüdiger.. incompatible encoding
[09:32am] adhocbot: is it possible to have logic in the upcoming UI that checks
whether the recording has exceeded its start time and display as Failing
[09:32am] bwulff: ok, he says he did see failed scheduled recordings listed
under failed, but a while ago
[09:32am] bwulff: we would have a problem with the stats again
[09:33am] bwulff: because the stats only show cumulative number (how many
instances are in which state, how many operations are in a certain state)
[09:34am] bwulff: further more, every approach that lets the UI decide where/if
to display a recording would break paging
[09:35am] adhocbot: I'm not suggesting not displaying anything. just tweaking
the status under display for questionable recordings.
[09:35am] bwulff: example: requesting the first page of 20 upcoming recordings,
but then deciding that 10 of them are not to be displayed in upcoming ...
[09:36am] bwulff: you mean still showing in the upcoming screen but indicating
that something went wrong with them
[09:36am] bwulff: that possible of course
[09:36am] adhocbot: lemme check to see what currently happens when it fails to
start
[09:36am] adhocbot: yes.
[09:38am] adhocbot: its kind of like "Unlike others recordings, we simply don't
know what happened but assume that it never started so look into it. you can
simply ignore it so it doesn't show in the UI, or fix it. but until then we
won't consider it failed" that's a nice concise status.
[09:41am] bwulff: yea, that is somehow nearly my idea in the comment I made on
6671
[09:41am] bwulff: we don't need to put them into FAILING
[09:42am] adhocbot: Same idea except that we don't rely on any capture-admin
changes from Josh/Tobias. right?
[09:42am] bwulff: we can also check if the recording data is in the past and
then present those recordings in the UI in a different way...
[09:42am] bwulff: ...I hope..
[09:42am] bwulff: yep
[09:42am] adhocbot: not ideal. but I think conceptually reasonable
[09:42am] adhocbot: one would hope that this is an infrequent use case anyway
[09:43am] bwulff: yes
[09:43am] bwulff: I think I need some ideas from judy since I'm not sure how to
handle those cases in the UI
[09:43am] bwulff: especially the wording
[09:47am] adhocbot: so to recap. a) not relying on capture-admin or CA for
failure to start info for 1.1 b)recognize the failed to start recordings in
their current workflow states in both the UI and stats, but change ui logic
exists to change status to a yet tbd status name. FAILING to START might be a
good placeholder for now.
[09:47am] adhocbot: are we on the same page?
[09:47am] adhocbot: pardon the expression. not sure if there is a german
equivalent
[09:50am] adhocbot: re: b, I meant don't do anything fancy to not show these
"failing" recordings in UI or stats beyond showing a different status
[09:51am] bwulff: well ok
[09:51am] bwulff: I think also it's not a good idea to let the stats endpoint
do additional filtering
[09:52am] adhocbot: agree. that is now what I'm proposing. these are still
listed under stats.
[09:52am] bwulff: just show 20 upcoming, when going to that filter the use will
see that eg. 2 of them are marked the way we discussed it?
[09:52am] adhocbot: yes. perhaps "Failed to Start (?)" might be a better
status as a placeholder.
[09:53am] bwulff: jep, a little '?' icon maybe
[09:53am] adhocbot: icon generally assumes info is avail
[09:54am] bwulff: ah, ok
[09:54am] adhocbot: upon rollover imho
[09:55am] bwulff: coloring the status red maybe?
[09:55am] adhocbot: beyond this the ideal approach would be for the
capture-admin to deal with this, but I think this is more complicated for now.
there is already a disconnect between recordings status in capture-admin and
the actual workflow status
[09:55am] adhocbot: sure
[09:56am] bwulff: yes, unfortunately there is...
[09:56am] adhocbot: feel free to disagree. I just think this is the simplest
path to a somewhat coherent temp solution
[09:57am] bwulff: and the UI is limited to the possibilities the qorkflows
queries imply
[09:58am] bwulff: well, this solution is doable for 1.1
[09:58am] bwulff: though not ideal, it is still feasible
[09:58am] adhocbot: even if those workflow queries existed we'd need to account
for missed recordings that aren't in a failed state
[09:58am] bwulff: exactly
[10:00am] adhocbot: I'll update that ticket with this approach to keep others
in the loop and add Judy as a watcher. thanks for your time
was (Author: ahochman):
Benjamin and I came up with a workable solution for 1.1.
Problem recap: UI relies on the workflow service, which partially relies on
capture-admin, for recording status. When a capture agent fails to start, the
failure isn't communicated to the capture-admin service and the workflow
service is essentially in the dark. This results in "missed" recordings still
appearing in the upcoming filter. The approaches suggested thus far fix this
problem but cause issues with the all recording filter. Even if we had more
sophisticated querying capabilities to exclude missed recordings from the
workflow service, we still need to account for them in the UI.
Solution: The path of least resistance for 1.1 is for the UI to determine
whether missed recordings "Failed to Start?" rather than rely on the CA or
capture-admin. These recordings never received any official status from the
CA, so they're interpreted as likely to have failed but needed to be looked
into (a limbo condition). Judy, if you have a better status for this please
suggest one. This means that recordings with this status will still appear
under upcoming and all (and accounted for in stats) but the user can either
ignore them or keep them around as a reminder. Perhaps in the future we can
have the user manually put them into a failed state if they really failed. If
the capture agent eventually starts up, these recordings will naturally no
longer appear under upcoming.
bwulff: I still think the only way to get rid of recordings from the past that
never made it to become a workflow, putting them into STOPPED state would be
the easiest.
[09:18am] bwulff: at least from the UI side
[09:18am] bwulff: don't know the technical implications on the back end
[09:22am] adhocbot: do #1 and #2 still exists as problems?
[09:22am] adhocbot: just ignore the welcome page question. I'll just find it.
[09:22am] bwulff: yes
[09:23am] bwulff: would be the solution to #1 to make the stats endpoint filter
by date
[09:24am] bwulff: but problem #2 is: on all we query the instances endpoint for
just about everything but the STOPPED workflows
[09:24am] bwulff: we cannot filter by date because we would then filter out
also the recordings that are finished , on hold etc (since they were already
recorded)
[09:25am] adhocbot: so "fromDate" ensures that missed recordings don't sure up
in the upcoming and all filter. correct?
[09:25am] bwulff: and we cannot query instances for example for: every 'full'
workflow + every 'schedule' workflow except those from the past
[09:25am] bwulff: fromDate filters the whole result set
[09:26am] bwulff: in upcomming this solves our problem since we only look for
schedule workflows
[09:27am] bwulff: on All we want every workflow instance (including full).
using fromDate here then applies to the whole result set, thus filtering out
every workflows instance that hase a mediapackage with start date before the
current time
[09:28am] adhocbot: understood. and the problem ultimately is when the CA
fails to start and the CA remains in upcoming. right?
[09:28am] bwulff: hence we would see the same data like on upcomming (only
scheduled recoridngs have a start date in the future)
[09:28am] bwulff: right
[09:29am] adhocbot: for other capture errrors, the capture-admin deals with
these correctly and they're displayed in the failed section?
[09:29am] bwulff: the workflows representing recordings that were not conducted
should reflect this fact
[09:29am] bwulff: a sec, let me ask rüdiger.. incompatible encoding
[09:32am] adhocbot: is it possible to have logic in the upcoming UI that checks
whether the recording has exceeded its start time and display as Failing
[09:32am] bwulff: ok, he says he did see failed scheduled recordings listed
under failed, but a while ago
[09:32am] bwulff: we would have a problem with the stats again
[09:33am] bwulff: because the stats only show cumulative number (how many
instances are in which state, how many operations are in a certain state)
[09:34am] bwulff: further more, every approach that lets the UI decide where/if
to display a recording would break paging
[09:35am] adhocbot: I'm not suggesting not displaying anything. just tweaking
the status under display for questionable recordings.
[09:35am] bwulff: example: requesting the first page of 20 upcoming recordings,
but then deciding that 10 of them are not to be displayed in upcoming ...
[09:36am] bwulff: you mean still showing in the upcoming screen but indicating
that something went wrong with them
[09:36am] bwulff: that possible of course
[09:36am] adhocbot: lemme check to see what currently happens when it fails to
start
[09:36am] adhocbot: yes.
[09:38am] adhocbot: its kind of like "Unlike others recordings, we simply don't
know what happened but assume that it never started so look into it. you can
simply ignore it so it doesn't show in the UI, or fix it. but until then we
won't consider it failed" that's a nice concise status.
[09:41am] bwulff: yea, that is somehow nearly my idea in the comment I made on
6671
[09:41am] bwulff: we don't need to put them into FAILING
[09:42am] adhocbot: Same idea except that we don't rely on any capture-admin
changes from Josh/Tobias. right?
[09:42am] bwulff: we can also check if the recording data is in the past and
then present those recordings in the UI in a different way...
[09:42am] bwulff: ...I hope..
[09:42am] bwulff: yep
[09:42am] adhocbot: not ideal. but I think conceptually reasonable
[09:42am] adhocbot: one would hope that this is an infrequent use case anyway
[09:43am] bwulff: yes
[09:43am] bwulff: I think I need some ideas from judy since I'm not sure how to
handle those cases in the UI
[09:43am] bwulff: especially the wording
[09:47am] adhocbot: so to recap. a) not relying on capture-admin or CA for
failure to start info for 1.1 b)recognize the failed to start recordings in
their current workflow states in both the UI and stats, but change ui logic
exists to change status to a yet tbd status name. FAILING to START might be a
good placeholder for now.
[09:47am] adhocbot: are we on the same page?
[09:47am] adhocbot: pardon the expression. not sure if there is a german
equivalent
[09:50am] adhocbot: re: b, I meant don't do anything fancy to not show these
"failing" recordings in UI or stats beyond showing a different status
[09:51am] bwulff: well ok
[09:51am] bwulff: I think also it's not a good idea to let the stats endpoint
do additional filtering
[09:52am] adhocbot: agree. that is now what I'm proposing. these are still
listed under stats.
[09:52am] bwulff: just show 20 upcoming, when going to that filter the use will
see that eg. 2 of them are marked the way we discussed it?
[09:52am] adhocbot: yes. perhaps "Failed to Start (?)" might be a better
status as a placeholder.
[09:53am] bwulff: jep, a little '?' icon maybe
[09:53am] adhocbot: icon generally assumes info is avail
[09:54am] bwulff: ah, ok
[09:54am] adhocbot: upon rollover imho
[09:55am] bwulff: coloring the status red maybe?
[09:55am] adhocbot: beyond this the ideal approach would be for the
capture-admin to deal with this, but I think this is more complicated for now.
there is already a disconnect between recordings status in capture-admin and
the actual workflow status
[09:55am] adhocbot: sure
[09:56am] bwulff: yes, unfortunately there is...
[09:56am] adhocbot: feel free to disagree. I just think this is the simplest
path to a somewhat coherent temp solution
[09:57am] bwulff: and the UI is limited to the possibilities the qorkflows
queries imply
[09:58am] bwulff: well, this solution is doable for 1.1
[09:58am] bwulff: though not ideal, it is still feasible
[09:58am] adhocbot: even if those workflow queries existed we'd need to account
for missed recordings that aren't in a failed state
[09:58am] bwulff: exactly
[10:00am] adhocbot: I'll update that ticket with this approach to keep others
in the loop and add Judy as a watcher. thanks for your time
> Events in the past are displayed in upcomming
> ---------------------------------------------
>
> Key: MH-6671
> URL: http://opencast.jira.com/browse/MH-6671
> Project: Matterhorn Project
> Issue Type: Bug
> Components: Administrative Tools
> Affects Versions: 1.1
> Reporter: Ruediger Rolf
> Assignee: Benjamin Wulff
> Priority: Release Blocker
> Fix For: 1.1
>
> Attachments: statistics.json
>
>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
