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> 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> 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) 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> > 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> 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
