Deej Howard <[email protected]> writes: > That video was very useful, Dennis – thanx for passing it > on! > > > > It sounds like the solution to the problem I’m seeing lies > with the client-side operations, based on the repo reservation methodology > that is in place. It would really be useful if there were some sort of API > call that could be made so the client code could decide if the operation > were just hung due to network issues (and abort or otherwise handle that > state), or if there is an active repo reservation in place that is waiting > to clear before the operation can proceed. I can also appreciate that this > has at least the potential of changing dynamically from the viewpoint of a > client’s operations (because the repo reservation can be put on/taken off > for other tasks that are already in the queue), and it would be good for > the client to be able to determine that its task is progressing (or not) as > far as getting assigned/executed. Sounds like I need to dig deeper into > what I can accomplish with API (or REST) to get a better idea of the exact > status of the import operation and basing decisions more on that status > rather than just “30 attempts every 2 seconds”. >
You can use the API to search for running or waiting tasks, then look at the "tags" on each task. Repositories used by a task will appear as "pulp:repository:<repo_id>" tags. _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
