Metric access for reporting tasks

2017-09-16 Thread Omer Hadari
Hello, I hope I am writing to the correct mailing list. We use graphite in my organization, and recently started to use nifi. We went on to write a simple reporting task for graphite, and I figured it could be used by other people as well, so why not contribute it. I was looking at other reporting

Re: Metric access for reporting tasks

2017-09-17 Thread Joe Witt
Omer Is the right list and it's awesome you want to contribute. Yes for sure such contribs are welcome. Just need to be sure all libraries used including transitive deps are fair game as far as licensing goes and are properly accounted for. As far as refactoring to avoid code duplication it cou

Re: Metric access for reporting tasks

2017-09-18 Thread Andrew Hulbert
Hi Omer, If you're interested in some help to implement, test, or review a graphite/grafana metrics reporter please let me know! We have written a very simple version and are interested in getting support into the main codebase as well. -Andrew On 09/17/2017 05:57 PM, Joe Witt wrote: Omer

Re: Metric access for reporting tasks

2017-10-11 Thread Omer Hadari
So I have created a generic metric reporting task, and implemented a Graphite service for it (Thank you Bryan for the quick reviews and responses!), and I am up to implementing the DataDog and Ambari reporting tasks in the same manner as well. I think it's important for avoiding confusion when impl

Re: Metric access for reporting tasks

2017-10-11 Thread Bryan Bende
Omer, I think adding the new versions that implement the new MetricReporterService, and marking the old ones as deprecated makes sense. They could potentially be removed on a major future release like 2.0.0. Were you envisioning the DataDogMetricReportService and AmbariMetricReportingService livi

Re: Metric access for reporting tasks

2017-10-11 Thread Omer Hadari
I looked at it and I think they could live under the same nar. That might be preferred since we want each implementation to depend on the same version of dropwizard-metrics, and including it in each nar is redundant and might even cause problems (correct me if I am wrong here). If you think these

Re: Metric access for reporting tasks

2017-10-11 Thread Bryan Bende
I just added you to the contributors list in JIRA so you should be able to assign things to yourself. I think initially putting all the metric services into the same NAR will probably be fine. If we add others in the future that bring in any conflicting dependencies then we can re-evaluate. The A

Re: Metric access for reporting tasks

2017-10-11 Thread Omer Hadari
Yes it is separate, just read my e-mail again and I see I wasn't clear, sorry about that. Thank you for adding me to the list. I'll create a ticket for the refactor and start working on it soon. Also, what's the appropriate way to deprecate a reporting-task/service/processor? On Wed, Oct 11, 2017

Re: Metric access for reporting tasks

2017-10-11 Thread Bryan Bende
There should be a DeprecationNotice annotation in the nifi-api module. I believe the intent was to use this, and then later add some visualization in the UI/docs to indicate what is deprecated. Anyone else feel free to correct me here. On Wed, Oct 11, 2017 at 1:54 PM, Omer Hadari wrote: > Yes i