Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1362301

Summary: Changing session_store from cache to sql results in appliance losing database configuration
Product: Red Hat CloudForms Management Engine Reporter: Lynn Dixon <ldixon>
Component: ApplianceAssignee: Nick Carboni <ncarboni>
Status: CLOSED WORKSFORME QA Contact: Dave Johnson <dajohnso>
Severity: high Docs Contact:
Priority: high    
Version: 5.6.0CC: abellott, brant.evans, dscott, jhardy, ldixon, ncarboni, obarenbo
Target Milestone: GA   
Target Release: 5.7.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: appliance:database
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-16 19:33:31 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:

Description Lynn Dixon 2016-08-01 21:41:07 UTC
Description of problem:
In a newly deployed WebUI worker attached to an external database (VMDB machine), changing the session_store advanced option from "cache" to "sql" results in the appliance loosing its external database configuration.  This is to support session persistence when behind a load balancer with more than one WebUI worker

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

How reproducible:
Simply modifying the session_store parameter and waiting a few minutes.

Steps to Reproduce:
1. Deploy a new CFME appliance (same version as above).
2. Configure it to join region in an external database
3. Once joined to region, login to appliances webui and navigate to Configuration --> (server_name) --> advanced
4. search for session_store and chance the option from "cache" to "sql"
5. Save settings and wait a few minutes, or reboot / restart services on appliance

Actual results:
The appliance will lose its database configuration and the "summary section" shows the following:

IP Address:    
Primary DNS:   
Secondary DNS:           
Search Order:  
MAC Address:             00:1a:4a:16:01:6a
Timezone:                US/Eastern
Local Database:          not running
CFME Database:           postgres @ localhost
Database/Region:          / 0
External Auth:           not configured
CFME Version:  
CFME Console:  

Expected results:
Expect the session_store option to be successfully changed to sql and worker appliance functions normally as it has in previous versions.

Additional info:
This was done in my lab. After this happened the first time, I completely rebuilt the VM from scratch and was able to fully duplicate the problem following the steps above.  I took a snapshot before I made the change on the new VM.  I can provide logs and other information to help diagnose / troubleshoot if needed.  The failed appliance is still in a broken state right now if any logs are needed.

Comment 2 Lynn Dixon 2016-08-01 21:47:49 UTC
Going back and attempting to re-configure the database settings results in the following:

Activating the configuration using the following settings...
Username: root
Database: vmdb_production

/opt/rh/cfme-gemset/gems/awesome_spawn-1.4.1/lib/awesome_spawn.rb:105:in `run!': /bin/systemctl exit code: 1 (AwesomeSpawn::CommandResultError)
        from /opt/rh/cfme-gemset/gems/linux_admin-0.16.0/lib/linux_admin/common.rb:24:in `run!'
        from /opt/rh/cfme-gemset/gems/linux_admin-0.16.0/lib/linux_admin/service/systemd_service.rb:21:in `start'
        from /var/www/miq/vmdb/gems/pending/appliance_console/database_configuration.rb:83:in `post_activation'
        from /var/www/miq/vmdb/gems/pending/appliance_console/database_configuration.rb:49:in `run_interactive'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:452:in `block in <module:ApplianceConsole>'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:106:in `loop'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:106:in `<module:ApplianceConsole>'
        from /var/www/miq/vmdb/gems/pending/appliance_console.rb:90:in `<main>'
[root@cfme01web01 ~]#

Comment 3 Nick Carboni 2016-08-12 20:19:23 UTC
Tested this with build and couldn't reproduce the issue.

Can you retest with the latest build?

Also is it possible that you are hitting this[1] BZ which also has to do with worker failures around changing the session_store?

I wouldn't expect the database setting to be wiped out if it was that bug though.


Comment 6 Lynn Dixon 2016-08-16 19:29:04 UTC
Confirmed that this is resolved in version

Tested latest build in my lab and was able to modify the session_store option to sql without any issues.

Comment 7 Nick Carboni 2016-08-16 19:33:31 UTC
Okay, if you're no longer seeing the issue, I'll close this as WORKSFORME.

Thanks for retesting Lynn.

Comment 8 Brant Evans 2016-08-18 22:13:08 UTC
(In reply to Lynn Dixon from comment #6)
> Confirmed that this is resolved in version
> Tested latest build in my lab and was able to modify the session_store
> option to sql without any issues.

I hope you meant version not