YES On Thursday, May 28, 2020 at 4:18:16 PM UTC-4, Julius Volz wrote: > > Since the vote is not about the Governance or team members, but would > rather fall under "technical decision", it is automatically a majority > vote: https://prometheus.io/governance/#technical-decisions > > On Thu, May 28, 2020 at 9:54 PM Bartłomiej Płotka <[email protected] > <javascript:>> wrote: > >> Sorry for the spam, but can we make sure to mention* what kind of vote >> is it? (*majority/supermajority/yolo) >> >> I personally don't have opinion on this topic, but don't want to block >> the vote as well. >> >> Kind Regards, >> Bartek >> >> On Thu, 28 May 2020 at 20:35, Julius Volz <[email protected] >> <javascript:>> wrote: >> >>> YES >>> >>> On Thu, May 28, 2020 at 9:30 PM Julius Volz <[email protected] >>> <javascript:>> wrote: >>> >>>> Dear Prometheans, >>>> >>>> https://github.com/prometheus/docs/pull/1640 proposes to list an >>>> exporter for Fortigate devices that uses a REST API. Brian's stance so far >>>> has been to only add exporters for metrics that cannot be already produced >>>> by another exporter on the list at >>>> https://prometheus.io/docs/instrumenting/exporters/, with the >>>> intention of focusing community efforts rather than spreading them over >>>> multiple competing exporters for the same thing. >>>> >>>> Since the Fortigate device can also be monitored via SNMP, Brian's >>>> argument is that the SNMP Exporter ( >>>> https://github.com/prometheus/snmp_exporter) already covers this use >>>> case and a more specialized REST-API-based exporter for Fortigate should >>>> not be listed. On the other hand, many people feel that SNMP is painful to >>>> work with, and monitoring via a REST API is much preferrable. (Further, >>>> and >>>> not directly relevant to this vote, the Fortigate REST API also reports >>>> some information that is not available via SNMP (see >>>> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)). >>>> >>>> In general I like the guideline of not adding too many competing >>>> exporters for the same thing to our public integrations list, but I >>>> believe >>>> that it should only be a guideline. I believe that SNMP is enough of an >>>> operational pain that we should allow exceptions for more specific, >>>> non-SNMP-based exporters like the linked one. It seems that the discussion >>>> has been had and is laid out in the issue. >>>> >>>> I therefore call a vote for the following proposal: >>>> >>>> Allow adding exporters to >>>> https://prometheus.io/docs/instrumenting/exporters/ although the >>>> devices or applications that they export data for can already be monitored >>>> via SNMP (and thus via the SNMP Exporter). This proposal does not affect >>>> other criteria that we may use in deciding whether to list an exporter or >>>> not. >>>> >>>> The vote closes on 2020-06-04 20:30 UTC. >>>> >>>> Cheers, >>>> Julius >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Prometheus Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowGqNyL7DavAaSuEE33DjFziiD6x%3Duc1EPUy6p1aJaH7Q%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowGqNyL7DavAaSuEE33DjFziiD6x%3Duc1EPUy6p1aJaH7Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>
-- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/185f0308-f41a-4f77-9af4-9a91dd8c7dad%40googlegroups.com.
