METRON-480: Kibana 4.5+ Requires http.cors.enabled set to false on ES

[dlyle65535]

Tested with simulated Docker cluster.

Installed Elasticsearch and Kibana services together post-install and verified Kibana could initialize.

[anandsubbu]

I have verified this fix on a 12-node openstack cluster.

Generated a fresh set of RPMs with the fix provided in this pull request, and setup the cluster afresh. After the installation completes, the Kibana dashboard comes up fine.

[justinleet]

Assuming that the quotes don't get removed in the .j2 files, can we move the quotes into those, then just leave this as a plain string without quotes? I'm not sure if using the quotes is required or not, but if they are then users might not remember to add them.

If we do want to change that, given that path_data does this even in the Github snippet, I'm sure this occurs more frequently and we may want to create a separate task for cleaning all of them up in one fell swoop.

[nickwallen]

@justinleet Do you think this needs addressed in this PR? If so, we can hold-off until @dlyle65535 has a chance to respond. Otherwise, respond with a +1 and we can merge this PR.

[justinleet]

+1, I'm fine with it being merged as-is.

[dlyle65535]

We have to have the quotes, otherwise Ambari will treat it as a boolean which will be written as False in elasticsearch.yml and Elasticsearch doesn't recognize that as False for this parameter only.

Please don't make them all the same in a clean-up pr, it will break things that work.

[nickwallen]

Was this intended to fix the following error thrown by Kibana when it tries to talk to Elasticsearch?

Courier Fetch Error: unhandled courier request error: Authorization Exception

[nickwallen]

Ah, chased down the JIRA. Looks like it is.

[nickwallen]

To fix this using Ambari on an existing ES cluster would I just go to...
Elasticsearch -> Configs -> Custom elastic_site -> Add Property -> key=http_cors_enabled, value=false?

[dlyle65535]

No, it defaults to false, so no user action is required.

[dlyle65535]

Darn. Can't edit on the phone. Are you seeing this on an existing cluster? A default ES instance should default to false.

[nickwallen]

I am seeing this on a cluster that I deployed with the mpack from 'master'. ES is happy and excited to play. When I hit up Kibana I get this error.

Courier Fetch Error: unhandled courier request error: Authorization Exception
Version: 4.5.1
Build: 9892

In researching the error, I ran across this on Github/Kibana which refers to the http.cors.enabled setting. I remembered you opening this PR and thought it might connect.

Now I'm confused though because in this PR you set a http_cors_enabled variable which uses underlines versus http.cors.enabled which is mentioned in the link above.

[nickwallen]

If I manually login to each ES master and remove the http.cors.enabled = true from /etc/elasticsearch/elasticsearch.yml then restart ES, I am able to connect to ES with Kibana.

Of course, once Ambari gets involved it undoes my manual edit. I have not yet figured out how to 'unset' this through Ambari yet.

[nickwallen]

+1 This PR did fix the issue that I was seeing. Tested on a live cluster.