metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <ottobackwa...@gmail.com>
Subject Re: Request double-check on Ambari config logic (ES network_host)
Date Tue, 02 May 2017 20:22:08 GMT
Thanks!


On May 2, 2017 at 14:58:37, Nick Allen (nick@nickallen.org) wrote:

I don't know how to uninstall, but you can reinstall by passing the --force
flag


On Tue, May 2, 2017 at 2:33 PM, Otto Fowler <ottobackwards@gmail.com>
wrote:

> Do you know how to uninstall an mpack from the cli?
>
>
> On May 2, 2017 at 14:27:02, Otto Fowler (ottobackwards@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 (mfoley@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" <ottobackwards@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, Zeolla@GMail.com (zeolla@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 <mfoley@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" <mattf@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message