Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1500136

Summary: [RFE] Make novnc console session expired after a period of time
Product: Red Hat OpenStack Reporter: Meiyan Zheng <mzheng>
Component: openstack-novaAssignee: OSP DFG:Compute <osp-dfg-compute>
Status: CLOSED WONTFIX QA Contact: OSP DFG:Compute <osp-dfg-compute>
Severity: medium Docs Contact:
Priority: medium    
Version: 10.0 (Newton)CC: dasmith, eglynn, kchamart, lyarwood, mbooth, mzheng, sbauza, sgordon, srevivo, stephenfin, vromanso
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-18 15:11:33 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:

Description Meiyan Zheng 2017-10-10 02:52:41 UTC 
Description of problem:
Customer want to make novnc console session expired and disconnect after a period of time.
After some research, seems token_ttl will delete token after a while, but setting the parameter will not impact to console session and the session never timeout. 

++++++++++++++++++++
[consoleauth]

# From nova.conf
#

#
# The lifetime of a console auth token.
#
# A console auth token is used in authorizing console access for a user.
# Once the auth token time to live count has elapsed, the token is
# considered expired.  Expired tokens are then deleted.
#  (integer value)
# Minimum value: 0
# Deprecated group;name - DEFAULT;console_token_ttl
#token_ttl=600
++++++++++++++++++++

There is a similar bug in upstream. 
https://bugs.launchpad.net/nova/+bug/1427141


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


How reproducible:


Steps to Reproduce:
1. enable the console feature in nova.conf
2. set the token timeout value in nova.conf to a value which fits your
   testing (e.g.)
   token_ttl = 600
3. start the openstack-nova-novncproxy service. 
4. start an instance
5. connect to the novnc console of that launched instance
6. Wait until the timespan defined by "token_ttl" elapsed

Actual results:
The console session never timeout and disconnect

Expected results:
The console session will timeout and disconnect

Additional info:
Comment 1 Stephen Finucane 2017-10-13 15:19:37 UTC 
> 2. set the token timeout value in nova.conf to a value which fits your testing (e.g.)
>   token_ttl = 600

For reference, this affects how long the token is valid for. Tokens are used once to connect to the session and then discarded. They have no effect once the session is established.

If I understand you correctly, you wish to set a connection timeout for any session? Is this a flat time period, or based on activity?
Comment 2 Meiyan Zheng 2017-10-16 05:19:37 UTC 
Hi Stephen,

Thanks for your comment. 

> If I understand you correctly, you wish to set a connection timeout 
> for any session? 

Yes, your understanding is correct. 

> Is this a flat time period, or based on activity?

Customer hope it can be a flat time period from the console session opened. 

Best Regards,
Meiyan
Comment 4 Stephen Finucane 2018-01-08 09:42:45 UTC 
Sorry about the delay.

As noted above, the 'token_ttl' configuration option affects how long the token can be used to create a new session but does not affect an establish session. Far as I can see, there is no equivalent feature in nova yet so the RFE subject is correct.

I've passed this onto my team and will come back once we decide if this is something that should be done and, if so, when it will be possible to work on it. Do note, however, that this would be a somewhat large feature and I would have doubts about backporting this all the way to OSP 10. OSP 14 would be the earliest I would see this feature appearing.
Comment 7 Stephen Finucane 2019-07-18 15:11:33 UTC 
We've investigated this and have decided that it's a significant amount of work that would likely require changes at multiple layers of the software. Given the effort necessary for this, it is likely to be a very long time before we will get around to implementing this, if ever. As such, I'm going to close as WONTFIX rather than suggest this is something we plan to fix in the near term.