Description of problem: We have an external server that plugs into the WebAdmin UI and needs to add long running tasks that the user starts through our plugin to the UI that are running on our server. Our server needs to be able to create the task through the REST API, update it and eventually mark it completed. Version-Release number of selected component (if applicable): We would need this for version 4.3. How reproducible: N/A Steps to Reproduce: N/A Actual results: N/A Expected results: N/A Additional info:
Moving to RHEV-M.
detailed requirements are required
Chris could you please elaborate a more? 1. Inject a task into where - I'm assuming engine task manager? 2. What entity will perform this task -I'm assuming your server? 3. Who will consume this injected information? - I'm assuming your plugin? I think that the best way to explain the request is to provide a step by step example flow that elaborates what each of the entities (Plugin, engine, your server) is doing on each of these step. This will allow engineering to come with a proper API for it.
1. I'm actually not sure in that I don't know the internals of how tasks are handled in oVirt. My understanding at this point is mainly from the UI. The tasks that show up in the bottom panel in the webadmin screen. We'd like our external task to show up there and if injecting it into the engine task manager does that, then I guess that's what is needed. 2. Yes, our server would create the task using a REST API call. 3. We will not be consuming the task information. It is there purely to inform the webadmin or other users about the progress of the tasks running in our server. Here's an example to demonstrate what we are looking for. A user would like to clone a VM and cranks up our Rapid Cloning wizard. They fill in all the information and have selected a VM that is currently running. Upon clicking Ok, the information is sent to our server which starts performing a set of actions including the following (Will likely differ in real life, just an example): a. Shutdown the VM (oVirt REST) b. Coalesce the disk (oVirt REST) c. Clone the disk (NetApp controller) d. Update metadata in domain associated with new disk (NetApp controller) e. Create new VM based on data from original VM (oVirt REST) f. Attach cloned disk to VM (oVirt REST) Each of these items would be a subtask of the overall Cloning task. At the beginning of this process, we would create the Cloning task through REST in oVirt. We could potentially include all the subtasks in the initial creation or add them as needed. Not sure which is best. As the tasks are performed, we would make REST calls to update the started/ finished status as well as the percentage complete if that's supported. Note that some of these tasks, such as shutting down a VM, would also show up as a separate task. It would be nice to have a way to pass a task ID when performing the oVirt associated REST calls and have any task it creates show up under our high level task.
Created attachment 778144 [details] Rest_Screenshot
Eli I see that in GUI all task are ordered by start time, but in REST it not, really I don't see any order in REST, it's bug? See screenshot of REST for example.
(In reply to Artyom from comment #7) > Eli I see that in GUI all task are ordered by start time, but in REST it > not, really I don't see any order in REST, it's bug? > See screenshot of REST for example. Its a bug , please open a separate BZ for it Also , before opening other bugs please check this list of opened BZs from last oVirt test day 988082 oVirt ovirt-engine-core emesika NEW [ExternalTasks] Cannot add sub-step under existing (parent) step 14:25:57 988086 oVirt ovirt-engine-core emesika NEW [ExternalTasks] When adding new step, type is always EXECUTING 14:26:10 988087 oVirt ovirt-engine-core emesika NEW [ExternalTasks] When adding new step, state is always STARTED 14:26:19 988088 oVirt ovirt-engine-core emesika NEW [ExternalTasks] Step cannot be ended as not successful 14:26:32 988094 oVirt ovirt-engine-core emesika NEW [ExternalTasks] Cannot end existing job
Verified on is13
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2014-0038.html