Bug 886788 - ovirt-engine-backend: No event for ticket VM command
Summary: ovirt-engine-backend: No event for ticket VM command
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 3.3.0
Assignee: Roy Golan
QA Contact: Tareq Alayan
URL:
Whiteboard: virt
Depends On:
Blocks: 1019461
TreeView+ depends on / blocked
 
Reported: 2012-12-13 07:40 UTC by Oded Ramraz
Modified: 2015-09-22 13:09 UTC (History)
10 users (show)

Fixed In Version: is11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-24 20:47:26 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 17742 0 None None None Never

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.


Note You need to log in before you can comment on or make changes to this bug.