Bug 869261 - edits lost when session times out
edits lost when session times out
Status: CLOSED WONTFIX
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
1.8
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Aron Parsons
Red Hat Satellite QA List
:
Depends On:
Blocks: space27
  Show dependency treegraph
 
Reported: 2012-10-23 08:27 EDT by David Juran
Modified: 2017-09-28 13:56 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-03 17:06:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Juran 2012-10-23 08:27:42 EDT
Description of problem:
When running snippet update, it's not unusual to have the file open in an external editor for an extended period of time. But if the session times out during this time, the edits are lost when one exits the editor

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

How reproducible:
Every time

Steps to Reproduce:
1. snippet-update my-favourite-snippet
2. Do some extensive editing
3. ERROR: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: Could no find session with id: 1330295
  
Actual results:
ERROR: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: Could no find session with id: 1330295
Lots of bad words being uttered...

Expected results:
Language being much more civilised (-:

Additional info:
If it' matters, I've been running nightly spacecmd on RHEL6
Comment 1 Miroslav Suchý 2012-10-29 09:37:07 EDT
Forwarding to upstream.
Comment 2 Michael Mráka 2012-10-31 07:02:23 EDT
Reassigning to spacecmd maintainer.
Comment 3 Steven Hardy 2013-01-28 05:12:41 EST
So this issue could be fixed in spacecmd by not opening the API session until after the edit is completed, but IMO a probably simpler solution is a workflow adjustment: 

1. Keep the snippets in a local git/svn repo, edit, then update the snippet after the edit with a non-interactive snippet_update -f snippetfile -n snippetname

or

2. Keep the snippets in a local git/svn repo, and setup a trigger script which updates a checkout under the /var/lib/rhn/kickstarts/snippets directory, changing /var/lib/rhn/kickstarts/snippets/<orgnum> to be a symlink to the checkout

Note that for test environments you could just edit the snippets directly under /var/lib/rhn/kickstarts/snippets/<orgnum> instead of using the spacecmd interactive mode, which again would solve this problem.

Also, I think the same problem would occur doing a lengthy edit via the web UI, in which case the only solution would be to extend the web session cookie timeout (which would also extend the time before the problem described in this bug occurs):

https://access.redhat.com/knowledge/solutions/11001

So with the above in mind, IMO reworking the spacecmd session management logic to solve this problem is probably not justified - propose closing this bug WONTFIX if the reported is happy with the workflow suggestions above.
Comment 4 Steven Hardy 2013-02-21 06:48:12 EST
Reassigning to Aron Parsons, spacecmd maintainer
Comment 5 Aron Parsons 2013-03-03 17:06:03 EST
(In reply to comment #3)
> So this issue could be fixed in spacecmd by not opening the API session
> until after the edit is completed, but IMO a probably simpler solution is a
> workflow adjustment: 

Agreed.  One should not be relying on a vim session as their only record of a snippet modification.  I don't think many people are going to hit this, so closing as WONTFIX.
Comment 6 Eric Herget 2017-09-28 13:56:22 EDT
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.

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