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
