First off, this is super nice, and a great way to let us be able to debug
and help others debug quickly, easily, and hopefully more consistently.
I super briefly glanced at at it, so these might already be there, but I'd
like to be able to filter what I get back, e.g. if I give the options for
Hey guys,
I wanted to bring attention to a tool I created for gathering cluster
details for debugging purposes. There are a number of locations that
properties get materialized, e.g. from Ambari -> properties file -> flux ->
Storm, which means a lot of hunting to guarantee that the changes you've
Comments below
On Wed, Apr 11, 2018, 10:59 AM Justin Leet wrote:
> First off, this is super nice, and a great way to let us be able to debug
> and help others debug quickly, easily, and hopefully more consistently.
>
> I super briefly glanced at at it, so these might
I think this is super helpful, Mike.
> Other than that, does anyone have any thoughts on putting something like this
into the management UI (for the non-Ambari managed stuff)? That seems like
it would be the natural place to get that stuff...
I agree this would be a great feature to add to a
Agree with you both - one reason Ambari might be preferable is that there
are config variables we can access more easily from Ambari, kind of like
what we use in the MPacks. I haven't looked at what we have in the
management UI but I think that's also a reasonable option.
On Wed, Apr 11, 2018,
I had a PR build fail with an issue with the Zookeeper cache.
https://travis-ci.org/apache/metron/builds/365122993
Failed tests:
ZKConfigurationsCacheIntegrationTest.validateUpdate:230->lambda$validateUpdate$9:230
expected:<{hdfs={index=yaf, batchSize=1, enabled=true},
I have not personally seen that one yet, but I will not deny that it
exists. It could be very intermittent or triggered under load in travis
too. Either way, we should probably investigate and fix.
On Wed, Apr 11, 2018 at 3:57 PM Otto Fowler wrote:
> I had a PR build