Bug 1475574 - [Regression] Updating service dialogs customization doesn't work
[Regression] Updating service dialogs customization doesn't work
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS (Show other bugs)
Unspecified Unspecified
high Severity high
: GA
: cfme-future
Assigned To: eclarizi
: Regression
Depends On:
Blocks: 1511957
  Show dependency treegraph
Reported: 2017-07-26 19:29 EDT by Saif Ali
Modified: 2017-11-10 09:00 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: Bug
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core

Attachments (Terms of Use)

  None (edit)
Description Saif Ali 2017-07-26 19:29:41 EDT
Description of problem:
We are seeing two different issues. 

1. Updating service dialogs customization doesn't work. Whenever we try to do any change in service dialog it’s not letting us save… first click it will work and then try to change some other or save it will just get hung and refresh will kick us out to login page.

2. Drop down list empty value issue…

attachment 1 [details].png
attachment 2 [details].png

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

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 15 eclarizi 2017-08-03 16:56:33 EDT
This sounds a lot like something we've dealt before with this exact dialog.

Here's two related BZs:

The first should have some instructions on how to increase the memcache size so that this dialog can be loaded and edited/added to (but please consider removing things instead of adding!).

Realistically, we won't be continuing to support the old dialog editor, and the new dialog editor supports this large dialog without a memcache increase.

I think if you need a workaround for now, follow the steps in the first linked BZ to increase the memcache size and that should fix the issue until the new dialog editor is the standard. If it does not, please report back and let us know.
Comment 25 Joe Rafaniello 2017-08-11 10:26:54 EDT
It looks to be be correctly configured:

Advanced settings:
  :memcache_server_opts: "-l -I 5M"


:cache => Dalli::Client.new(Settings.session.memcache_server, :namespace => "MIQ:VMDB", :value_max_bytes => 10.megabytes),

The log line comes from here:

It's hardcoded to 100 KB here:

That log line is independent from the dalli client or the memcached setting.

You would get an error from dalli client if it couldn't store an object into memcached due to object size.  Something like this:

"Value for #{key} over max size: #{@options[:value_max_bytes]} <= #{value.bytesize}"
Comment 26 Joe Rafaniello 2017-08-11 12:37:18 EDT
Erik noticed this error in the evm.log:

"Warning! ActionDispatch::Session::MemCacheStore failed to save session. Content dropped."  

This is the message to look for in the evm.log to see if the saving of the session was dropped by memcached because it was too large.

That comes from rack:

rack-2.0.3/lib/rack/session/abstract/id.rb-354-          if not data = write_session(req, session_id, session_data, options)
rack-2.0.3/lib/rack/session/abstract/id.rb:355:            req.get_header(RACK_ERRORS).puts("Warning! #{self.class.name} failed to save session. Content dropped.")
rack-2.0.3/lib/rack/session/abstract/id.rb-356-          elsif options[:defer] and not options[:renew]
rack-2.0.3/lib/rack/session/abstract/id.rb-357-            req.get_header(RACK_ERRORS).puts("Deferring cookie for #{session_id}") if $VERBOSE
rack-2.0.3/lib/rack/session/abstract/id.rb-358-          else

We tested this locally and found that you have to change the advanced settings
:memcache_server_opts: "-l -I 10M"



:cache => Dalli::Client.new(Settings.session.memcache_server, :namespace => "MIQ:VMDB", :value_max_bytes => 10.megabytes)

Then you must restart the server process.
Comment 27 Joe Rafaniello 2017-08-11 12:40:44 EDT
Follow up to the last comment, after you save the configuration and restart the server, you should see memcached running with the desired max size (-I) value:

# ps -ef |grep memcached
memcach+  2506     1  0 12:39 ?        00:00:00 /usr/bin/memcached -u memcached -p 11211 -m 64 -c 1024 -l -I 10

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