On Mon, Apr 25, 2011 at 1:19 PM, Hank Magnuski <[email protected]> wrote:
> > Hi Adam, > > Thanks for any clarification. I'm not sure which release notes you > referenced below. > > I'm trying to get familiar with this product from the point of view and > administrator, installer and end user, and I don't want to start reading > java source code just yet. > > For example, I made a number of test submittals using the Admin recording > upload facility, and decided I wanted to clean up unwanted recordings from > the system. > > Surprisingly, with the 1.1 Admin tool there is still no way (that I saw) to > delete or edit (e.g. change the Title) of a submitted recording, pretty > basic admin functionality supported on most other video portals. > Yes, the edit and delete features are in much demand, but have still not been implemented. You are certainly not alone in expecting these features. > > The Wiki said there would be some additional detail about doing this, but I > was unable to find it. So I tried to do the cleanup myself. > > Using the REST forms I was able to "retract" the download and streaming > files, and "unpublish" the entries for Engage. > > But there doesn't seem to be any REST call to delete a mediapackage. There is a tension here between "audit everything" requirements and allowing the administrative user full control. We tried to come up with a flexible approach where workflows can clean up after themselves, leaving only those files that have been configured to be saved. If you want to delete all traces of a workflow (including its mediapackage, and all of its linked files), in the 1.1 release you would have to write some custom code. > There is a "/discardMediaPackage" under Ingest, but I could never get it to > work. This is a cleanup for a multi-request (aka "thin client") ingest, where the client calls create, add, add..., ingest. If the client wants to cancel before ingesting, it calls /discardMediaPackage. In other words, as you've already discovered, this doesn't do what you need. In fact, there does not appear to be any Admin page or REST call to list all > mediapackages (or all downloadable files or stream files either) in the > system (please correct me, as I might be wrong or misinformed on all of > these points). The workflow service provides lists of all workflow instances (e.g. /workflow/instances.xml). The mediapackage->workflow instance relationship is 1->n. > Surprisingly, there is no table in the database, it appears, that lists > mediapackages. They must be somewhere else. > Each service uses its own persistence approach, tailored to fit its needs. Most Matterhorn services use "document oriented" rather than relational databases. In the end, though, most entites wind up somewhere in the relational database. > > Well, I found mediapackage links under the "files" and "workspace", so I > just deleted them all. That would be the end to all those unwanted > recordings, I thought. > > Not so. The "Recordings" that are listed do not seem to be mediapackages at > all, but "workflow instances". I found entries in the "jobs" database table > and deleted those workflow jobs, and thought that that would be the end of > all those unwanted recordings. > > Not so. It looks like "workflow instances" are kept in yet another index > managed by "lucene" and totally separate from filesystem mediapackages or > the database. > I could find no REST call to delete a workflow instance. Those audit requirements again. If you POST the workflow ID to /workflow/stop, the workflow / recording won't show up in the UI anymore, but the underlying data structures are still there. > Is a "workflow instance" just an expanded mediapackage by another name? > Does it own the files in the download and streaming directories too, or are > those files separately accounted for by some other index? > A mediapackage is just a document that keeps track of resources, along with metadata relating to each resource. Mediapackages can also be zipped, so all of the resources are contained in the same archive as the xml document. This dual meaning of the word "mediapackage" often leads to confusion. A workflow is another kind of document that keeps track of operations performed on a mediapackage. The workflow document contains a mediapackage along with processing instructions, timing information, etc. There is no central repository for all mediapackages, just the workflow service that keeps track of workflow instances, including workflows that are scheduled to capture at a future date, those that are currently processing, and those that have finished processing. That said, there's nothing keeping an external application from submitting to the search service a mediapackage document that has never been part of a workflow. The resources referenced by that mediapackage may even be hosted elsewhere. So as you can see by all these questions and my confusion about what really > is a mediapackage, why is it not the same as a recording, and what about > other files in the system that there needs to be some additional > documentation and information available to help new admins understand this > system. A few wiki pages on the directories used by Matterhorn, the indexes > and databases used by the various services, the main objects (mediapackages, > workflow instances, etc.) used by Matterhorn, ... , to reduce the learning > time needed by an incoming admin to get a handle on this system and figure > out how to tailor it to best fit the needs of his/her client base. > > You already have some really nice overview tutorials on the site. I need > the next level. > > We're always in need of more and better documentation. Please feel free to write up what you've learned. We can use it as a starting point for a "your first week with Matterhorn" tutorial :) Thanks, Josh > Thanks for the support and feedback, > > Hank > > On Mon, 25 Apr 2011, Adam Hochman wrote: Hi Hank, > I'll update the 1.1 FAQ to explain some of the issues you encountered. > Please note that there are known issues stated in the release notes that may > impact your 1.1 installation. There is also a blurb about storage in the > distribution installation notes that goes into more details about > Matterhorn's storage configuration. You may find it informative. > > ~ Adam > > On 4/23/11 8:31 AM, Hank Magnuski wrote: > >> >> Thank you, I missed the fact that these were hard links (they are on the >> same filesystem). >> >> Hank >> >> On Sat, 23 Apr 2011, Josh Holtzman wrote: >> >> > If those two paths are from a single physical volume, those are two >> hard >> > links pointing to the same file. So even though it looks like you have >> > four >> > files, they are really only taking up the space of two. >> > _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
