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" <[email protected]> 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, [email protected] ([email protected]) 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 <[email protected]> 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" <[email protected]> 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
