Bug 886788

Summary: ovirt-engine-backend: No event for ticket VM command
Product: Red Hat Enterprise Virtualization Manager Reporter: Oded Ramraz <oramraz>
Component: ovirt-engineAssignee: Roy Golan <rgolan>
Status: CLOSED UPSTREAM QA Contact: Tareq Alayan <talayan>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: acathrow, iheim, jkt, lpeer, michal.skrivanek, ofrenkel, pstehlik, rgolan, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: is11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-24 20:47:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1019461    

Description Oded Ramraz 2012-12-13 07:40:10 UTC
Description of problem:

After setting ticket to a VM , there is no event in events tab . 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

RHEVM shell (connected)]# action vm 0c373c97-0a72-4e4e-a9fd-7d7d906e9531 ticket 

status-state : complete
ticket-expiry: 7200
ticket-value : kDTtdOYAngVx

[RHEVM shell (connected)]# list events --max 1

id         : 1534
description: User admin@internal logged in.

Comment 1 Michal Skrivanek 2013-01-13 16:46:16 UTC
why do we need one? I would expect it's useful only for some more longterm tasks

Comment 2 Oded Ramraz 2013-01-31 14:17:35 UTC
Currently you have no way to know if manual ticket command succeeded or not , I don't see why this command is different from other commands . 

(In reply to comment #1)
> why do we need one? I would expect it's useful only for some more longterm
> tasks

Comment 3 Roy Golan 2013-02-10 13:47:28 UTC
we can add it for explicit usages, e.i  when invoking /api/xxx/ticket but this means we have to flag the engine somehow about explicit call of this verb. I'm not a big fan of shouldBeLogged flag in VdcActionParameterBase (and I know ofrenkel isn't either)  

and 2nd option is that we can always log this one, its informative and not costly really. 
thoughts?

Comment 4 Omer Frenkel 2013-02-11 08:31:27 UTC
this command is basically internal (in the UI, user click the console, shouldn't be aware of internal implementation of setting a ticket).

i suggest adding a message that will describe the process and not the action, something like "user initiated console session"

Comment 5 Oded Ramraz 2013-02-11 09:14:07 UTC
It will not be accurate when calling ticket vm explicitly ( from Rest / SDK / CLI )

(In reply to comment #4)
> this command is basically internal (in the UI, user click the console,
> shouldn't be aware of internal implementation of setting a ticket).
> 
> i suggest adding a message that will describe the process and not the
> action, something like "user initiated console session"

Comment 6 Itamar Heim 2013-04-19 08:14:25 UTC
(In reply to comment #5)
> It will not be accurate when calling ticket vm explicitly ( from Rest / SDK
> / CLI )
> 
> (In reply to comment #4)
> > this command is basically internal (in the UI, user click the console,
> > shouldn't be aware of internal implementation of setting a ticket).
> > 
> > i suggest adding a message that will describe the process and not the
> > action, something like "user initiated console session"

agree - we do support setting the ticket directly, but i think the suggested message ("user initiated console session") covers this use case as well.