|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:||Appliance||Assignee:||Nick Carboni <ncarboni>|
|Status:||CLOSED WORKSFORME||QA Contact:||Dave Johnson <dajohnso>|
|Version:||5.6.0||CC:||abellott, brant.evans, dscott, jhardy, ldixon, ncarboni, obarenbo|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-08-16 19:33:31 UTC||Type:||Bug|
|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): 188.8.131.52.20160624114606_13a9153 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: Hostname: cfme01web01.example.com IP Address: 172.16.0.51 Netmask: 255.255.255.0 Gateway: 172.16.0.1 Primary DNS: 172.16.0.1 Secondary DNS: Search Order: example.com 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: 184.108.40.206 CFME Console: https://172.16.0.51 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... Host: cfme01vmdb.example.com 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 220.127.116.11-20160810181333_8ba817b and couldn't reproduce the issue. Can you retest with the latest build? Also is it possible that you are hitting this 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.  https://bugzilla.redhat.com/show_bug.cgi?id=1348632
Comment 6 Lynn Dixon 2016-08-16 19:29:04 UTC
Confirmed that this is resolved in version 18.104.22.168.20160624114606_13a9153 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 22.214.171.124.20160624114606_13a9153 > > 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 126.96.36.199-20160810181333_8ba817b not 188.8.131.52...