Do you know how to uninstall an mpack from the cli?
On May 2, 2017 at 14:27:02, Otto Fowler (ottobackwa...@gmail.com) wrote: Are you saying that the defaults should work now? Or they should work, but I still need to change the interface from eth0? On May 2, 2017 at 13:36:11, 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
