Bug 1471018 - Allow cancel event that was picked up from queue by WebUI
Summary: Allow cancel event that was picked up from queue by WebUI
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI
Version: 580
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jiří Dostál
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
Depends On:
Blocks: sat58-errata sat58-nth
TreeView+ depends on / blocked
 
Reported: 2017-07-14 09:29 UTC by Pavel Studeník
Modified: 2017-12-13 07:59 UTC (History)
4 users (show)

Fixed In Version: spacewalk-java-2.5.14-102-sat
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-13 07:59:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:3445 0 normal SHIPPED_LIVE Red Hat Satellite 5.8.0 bug fix update 2017-12-12 19:00:37 UTC

Description Pavel Studeník 2017-07-14 09:29:56 UTC
Description of problem:
When the event is picked up it is not possible to cancel it by WebUI. API allows cancel it, but I think that it can be easier. For example when you schedule reboot and cancel it from client "shutdown -c"

Version-Release number of selected component (if applicable):
spacewalk-java-2.5.14-89.el6sat.noarch

How reproducible:
always

Steps to Reproduce:
1. register system to satellite
2. schedule reboot
3. cancel reboot

Actual results:
event is not possible to cancel by WebUI

Expected results:
I can cancel it by WebUI

Comment 1 Jiří Dostál 2017-08-11 14:49:11 UTC
spacewalk(master) ab157795075ab094448823b744728699ca3cf323

Comment 4 Lukáš Hellebrandt 2017-11-14 14:18:25 UTC
Verified with spacewalk-java-2.5.14-104.

1) Schedule a remote command
2) rhn_check -vv on system
3) <system>->events->history-><event>->Set to Failed
4) Confirm that "Forcibly changing status of Picked Up action is potentially dangerous. Are you sure you want to continue?"

After this, the action is set to Failed.

Note:
1) This does not stop the action on the system! In merely sets it to failed on satellite
2) It was possible to do the very similar thing pre-fix, using Schedule->Pending-><action>->In Progress->select system->Unschedule. This removed the action completely, as opposed to this fix marking it as failed.
3) Failing the action causes traceback after rhn_check finishes:
===
D: handle_action actionid = 23, version = 2
D: do_call script.run(23, {'username': 'root', 'groupname': 'root', 'now': '2017-11-14 15:11:43', 'timeout': 600, 'script': '#!/bin/sh\n# Add your shell script below\nsleep 60'}){'cache_only': None}
D: Sending back response(0, 'Script executed', {'output': '', 'base64enc': 1, 'process_end': '2017-11-14 15:12:43', 'return_code': 0, 'process_start': '2017-11-14 15:11:43'})
Could not submit results to server <RetryServer for ibm-x3650m4-03-vm12.lab.eng.brq.redhat.com/XMLRPC>
Error code: -22
Error Message:
    Action 23 does not belong to server 1000010003
Error Class Code: 22
Error Class Info: Unable to retrieve requested entry.
Explanation: 
     An error has occurred while processing your request. If this problem
     persists please consult the Red Hat Customer Portal Knowledge Base
     landing page on common registration Error Class Codes at
     https://access.redhat.com/solutions/17036 for a possible resolution.
     If you choose to open a support case in the Red Hat Customer Portal,
     please be sure to include details of what you were trying to do when
     this error occurred and specifics on how to reproduce this problem.
===
This is suboptimal, it seems like the action never existed in the first place; however, it is good enough, the user is warned they are doing something non-standard and should expect non-standard behavior.

-> Verified after discussing with devel

Comment 7 errata-xmlrpc 2017-12-13 07:59:26 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.

https://access.redhat.com/errata/RHBA-2017:3445


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