Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/760
> Can you reference :
http://mail-archives.apache.org/mod_mbox/metron-dev/201701.mbox/%3cCAPpQHK1svDAx7R-s7x2Q0kJR6=5d+KDmR6a+ZmSo-5=wcmo...@mail.gmail.com%3e
> Which I think is the discuss list?
Not sure I follow - you want me to reference it in the docs? This doesn't
change the current paradigm of Zookeeper being the source of truth at all times.
> Is this a standard way of working between ambari and zookeeper or a new
take?
There isn't really a standard way of managing configs in Zookeeper in
Ambari that I'm aware of. This is mostly fixing a gap in how we handle
materializing configs from the properties that are managed via the Ambari
interface.
> I have not found it this morning, but my recollection is we did some
documentation around ambari and what we do there, do you plan on putting in
something about this for maintainers etc?
Yes, completely agreed. Per my initial PR comments this workflow should
definitely be explained so the implications of making config changes from local
disk, Ambari, Zookeeper, and the management UI are well understood. I have to
look for where we put that. While I'm addressing some other code review
comments, if anyone happens to know where off the top of their head, that would
be helpful.
> Do you plan on integrating this into the feature branch yourself? Or were
you planning on me doing it?
This is backwards compatible with existing config management. The only
major change would be around Ambari:
1. actually writing the global config from properties held in the Ambari UI
(as opposed to the hard-coded values) and
2. using a patching (additive in nature, overwrite in the event of property
conflict) mechanism
3. doing a zk config pull to local disk after any service starts/restarts.
What problems with integration are you expecting? There aren't any new
classes introduced.
---
