Actually, you might prefer "_local_", "_site_", "_global_", if you really want to expose globally-scoped addresses. See https://www.elastic.co/guide/en/elasticsearch/reference/2.3/modules-network.html#network-interface-values for the definitions ES uses. But there are indications in the ES 2.3 code that they may only pick one of the possible addresses instead of “all”, which would be bad. In this case, the “0.0.0.0” might succeed in getting “all” (including global addrs). We need to test.
From: "zeo...@gmail.com" <zeo...@gmail.com> Date: Tuesday, May 2, 2017 at 10:59 AM To: Matt Foley <mfo...@hortonworks.com>, "dev@metron.apache.org" <dev@metron.apache.org>, "d...@metron.incubator.apache.org" <d...@metron.incubator.apache.org>, Otto Fowler <ottobackwa...@gmail.com> Subject: Re: Request double-check on Ambari config logic (ES network_host) As somebody who has systems that have globally-scoped addresses directly addressed onto servers, I would prefer using using "_local_", "_site_". Jon On Tue, May 2, 2017 at 1:36 PM Matt Foley <mfo...@hortonworks.com<mailto:mfo...@hortonworks.com>> wrote: Hi Otto, The basic change to use “0.0.0.0” as the default binding, and put the square brackets in the template text instead of the parameter value, is now available in https://github.com/mattf-horton/incubator-metron branch METRON-905 commit e879719a0c3fb I’m having some trouble with my test env, so if you wanted to give it a try, that would be great. If the “0.0.0.0” doesn’t work, then we should use "_local_", "_site_" that being the ES special values that mean aprx the same. I’m going to have to do trial-and-error to determine the exact behavior of multi-item lists, and then write the python code to strip redundant square brackets if included in the parameter value. Thanks, --Matt On 5/2/17, 6:44 AM, "Otto Fowler" <ottobackwa...@gmail.com<mailto:ottobackwa...@gmail.com>> wrote: I am working on a centos 7 cluster deploy for testing the steps. I have this issue ( along with the wrong interface name ) and can test when you have it. An eta would help? On May 2, 2017 at 09:14:10, zeo...@gmail.com (zeo...@gmail.com<mailto:zeo...@gmail.com>) wrote: Are you working on this one? The JIRA doesn't look like it's currently assigned. Thanks, Jon On Mon, May 1, 2017 at 6:40 PM Matt Foley <mfo...@hortonworks.com<mailto:mfo...@hortonworks.com>> wrote: > Ah, I see I mis-read METRON-897, and Nick specifically says > "lo:ipv4","eth0:ipv4" did not work for him, but ["_lo:ipv4_","_eth0:ipv4_"] > did work. > > So I went back and dug a little deeper, and realized that in the > environment where "lo:ipv4","eth0:ipv4" worked for me, I had modified the > yaml.j2 template to include the square brackets. > > So the below theory is wrong. Back to the drawing board. > Thanks, > --Matt > > On 5/1/17, 3:08 PM, "Matt Foley" <ma...@apache.org<mailto:ma...@apache.org>> wrote: > > Hi, there have been widely varying statements about what needs to be > in the Elasticsearch config parameter “network_host”. I think I may have a > rationale for what works and what doesn’t, but I’d like your input or > correction. > > I am focusing on what worked in terms of punctuation (quotes and > square brackets) with the old _lo:ip4_,_eth0:ip4_. I would like to ignore > for the moment, please, whether eth0 was the correct name for a given env, > and whether we can use 0.0.0.0. Instead, for systems where eth0 WAS the > correct name, I’d like to understand what worked and why. > > It’s complicated because the value starts out in xml, is read into > python, printed by jinja, then consumed by yaml. > > I think there were two constructs that actually worked for this > param. Please say whether this is consistent or inconsistent with your > experience: > > "_lo:ip4_","_eth0:ip4_" > This worked for me. I think this was read from XML into python as a > list of strings, then output in jinja ‘print statement‘ > {{ network_host }} as a python literal list with form: > [ "_lo:ip4_", "_eth0:ip4_" ] > In other words, the print statement for a python list object injected > the needed square brackets. > > and > "[ _lo:ip4_, _eth0:ip4_ ]" > Nick and Anand, please confirm if this is the form that worked for > you. I think this was read from XML into python as a single string, and > output in the same jinja print statement as: > [ _lo:ip4_, _eth0:ip4_ ] > because the print statement for a python string object does not > produce quote marks. > > In either case, yaml (the consumer of the jinja output) saw what it > interprets as a list of strings (since quotes are optional for yaml > strings). > > What didn’t work was: > > * "_lo:ip4_, _eth0:ip4_" > This would be read in and output as a single string, and no square > brackets would ever be introduced. > > * _lo:ip4_, _eth0:ip4_ or [ _lo:ip4_, _eth0:ip4_ ] > (without quotes) I think the unquoted colons messed up the python > parsing > > Finally, I don’t know whether > * [ "_lo:ip4_", "_eth0:ip4_" ] > worked or not, I’m not sure anyone ever tried it. By the above logic > it probably should work. > > Please give me your input if you have touched on these issues. > Thanks, > --Matt > > > > > > > -- Jon -- Jon