Skip to content
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

Check if we need the capture agent state error #54

Open
lkiesow opened this issue Feb 9, 2017 · 3 comments
Open

Check if we need the capture agent state error #54

lkiesow opened this issue Feb 9, 2017 · 3 comments
Milestone

Comments

@lkiesow
Copy link
Member

lkiesow commented Feb 9, 2017

A new capture agent state “error” is introduced with Opencast 2.4:

https://bitbucket.org/opencast-community/matterhorn/pull-requests/1297

@smarquard
Copy link

error is meaningful for capture agents that are aware of some issue preventing successful recording, in advance of the recording.

As pyca doesn't continuously monitor inputs, it doesn't know if a source is available or not.

It could possibly check for low disk space. If free disk space is less than a configured value, it would be appropriate to set status to error (running, but recording unlikely to be successful).

@JanKoppe
Copy link
Contributor

I think an option for commands that are regularly run would be a good choice. This gives enough flexibility to say "check if capture card device is available", "check if IP camera is pingable", etc. Error state could then be triggered by return code. Implementation is up to the user.

@lkiesow
Copy link
Member Author

lkiesow commented Feb 23, 2017

That would then be more or less a monitor service. Separate from the rest of pyCA, it would just check things and, if necessary, set the capture agent state to error.

For that to happen, we would probably need to have a centralized global capture agent state (could easily be just a simple database table) so that the capturer would not just overwrite the error state.

Going into that begs the question if we want to pick up other ca states again as well. For example, iirc uploading is never used at the moment since it could easily conflict with capturing and we would end up with a random state.

Finally, there is the question if we want to suspend other services (capture?, upload?, schedule?) if an error state is set.It could be useful to not completely fill the disk or not fail uploads if there is no network, but it also means that it might stop the ca from doing certain tasks it still could do· or introducing a complex system with several error states and different handlers which I tend to avoid.

@JanKoppe JanKoppe added this to the 2.1 milestone Mar 20, 2017
@lkiesow lkiesow modified the milestones: 2.2, 2.1 Apr 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants