Bug 872719

Summary: PRD33 - [RFE] Add support for adding and managing external tasks
Product: Red Hat Enterprise Virtualization Manager Reporter: Chris Morrissey <cmorriss>
Component: ovirt-engineAssignee: Eli Mesika <emesika>
Status: CLOSED ERRATA QA Contact: Artyom <alukiano>
Severity: medium Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: abaron, acathrow, adahms, bazulay, bdagan, ecohen, emesika, iheim, jkt, lpeer, mgoldboi, pstehlik, Rhev-m-bugs, thildred, yeylon, yzaslavs
Target Milestone: ---Keywords: FutureFeature
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: is6 Doc Type: Enhancement
Doc Text:
External systems and plug-ins can now log their events in the application Audit Log. This feature allows administrators to view events linked to external tasks using the same mechanism as application events.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-21 17:30:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1019470    
Attachments:
Description Flags
Rest_Screenshot none

Description Chris Morrissey 2012-11-02 19:54:21 UTC
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:

Comment 1 Chris Morrissey 2012-11-02 21:02:16 UTC
Moving to RHEV-M.

Comment 2 Barak 2013-01-23 11:00:38 UTC
detailed requirements are required

Comment 3 Simon Grinberg 2013-01-23 11:10:36 UTC
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.

Comment 4 Chris Morrissey 2013-01-24 20:01:47 UTC
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.

Comment 6 Artyom 2013-07-25 09:11:05 UTC
Created attachment 778144 [details]
Rest_Screenshot

Comment 7 Artyom 2013-07-25 09:11:57 UTC
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.

Comment 8 Eli Mesika 2013-07-25 09:29:30 UTC
(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

Comment 10 Artyom 2013-09-10 08:52:04 UTC
Verified on is13

Comment 11 Charlie 2013-11-28 00:10:15 UTC
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.

Comment 13 errata-xmlrpc 2014-01-21 17:30:41 UTC
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