Re: [prometheus-developers] Removing Vendor
(I've hit the Send button too fast so resending) As far as I'm concerned, I used to be in favor of vendoring. With Go proxies being a thing, I would be ok with removing it. As others have said, there's no urgency though so let's discuss it more in-depth at the DevSummit. On Fri, Mar 13, 2020 at 4:24 PM Simon Pasquier wrote: > > As far as I'm concerned, I used to be in favor of vendoring. With Go > proxies being , I would be ok with removing it. > As others have said, there's no urgency though so let's discuss it > more in-depth at the DevSummit. > > On Fri, Mar 13, 2020 at 1:42 PM Bartłomiej Płotka wrote: > > > > I would love to have it removed, and in fact, I plan in my personal time to > > blog post and talk more about not storing someone else code in your own > > repository and why the vendor is (IMO) evil (: I hope also to help in any > > tooling that will fix the malicious dep problem without vendoring as well. > > > > Anyway, I fully agree with Björn that there is no urgent need, so I don't > > have a strong opinion to fix this in Prometheus now, but anyway I would > > love to hear more opinions on the incoming DevSummit +1 Looks like thanks > > to Björn we already have that on our agenda. > > > > Thanks for raising this Sylvain. > > > > Kind Regards, > > Bartek > > > > On Thu, 12 Mar 2020 at 16:47, Julien Pivotto wrote: > >> > >> On 12 Mar 17:42, Bjoern Rabenstein wrote: > >> > On 11.03.20 23:58, Sylvain Rabot wrote: > >> > > Several maintainers have given their thoughts on the subjects now. > >> > > > >> > > What would be the next step ? > >> > > > >> > > Should this be put to a vote ? > >> > > >> > We could. > >> > > >> > My personal opinion is that if somebody commits to do the work of > >> > changing our build processes to not use/have the `vendor` directory, > >> > I'd be for it. > >> > > >> > However, from the mail conversation and also from some personal > >> > communication I had with a few team members, there are many who don't > >> > really want to change the status quo right now, and some even prefer > >> > to keep the `vendor` directory around. > >> > > >> > Since the current state doesn't really block any other feature > >> > development, and since the appetite for change doesn't seem to be very > >> > high generally, I would say this is not super pressing at the moment, > >> > and I wouldn't spin up the machinery of a formal vote for it right > >> > now. It might, however, be a great topic to discuss at the next > >> > developer summit. I have already added it to the agenda. (It was > >> > planned to happen during KubeCon EU. Since the latter has been > >> > postponed, we might do a virtual summit, but that's not finalized > >> > yet.) > >> > >> After reading everything, I personally don't object to remove the vendor > >> directory. My personal gut is to keep it but there don't seem to be a > >> lot of good technical reasons to do so. > >> > >> My very preferred choice would be to remove it but still to archive a > >> 'vendor' directory within our CI process (next to the binaries?) to > >> ensure we still have the exact code around. > >> > >> +1 to put it on the dev summit agenda. > >> > >> -- > >> (o-Julien Pivotto > >> //\Open-Source Consultant > >> V_/_ Inuits - https://www.inuits.eu > >> > >> -- > >> 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 prometheus-developers+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/prometheus-developers/20200312164709.GA21031%40oxygen. > > > > -- > > 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 prometheus-developers+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYMRzrpwWAZ4xGAzLp7jDdn1rHC%2B8Tb9vGuz6%2Bcrj4U%2BQ%40mail.gmail.com. -- 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 prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAM6RFu5Y_MZyYXw-wEDehyM1TAWcpfCzBfuGe6Upmh65DPKPpQ%40mail.gmail.com.
Re: [prometheus-developers] Removing Vendor
As far as I'm concerned, I used to be in favor of vendoring. With Go proxies being , I would be ok with removing it. As others have said, there's no urgency though so let's discuss it more in-depth at the DevSummit. On Fri, Mar 13, 2020 at 1:42 PM Bartłomiej Płotka wrote: > > I would love to have it removed, and in fact, I plan in my personal time to > blog post and talk more about not storing someone else code in your own > repository and why the vendor is (IMO) evil (: I hope also to help in any > tooling that will fix the malicious dep problem without vendoring as well. > > Anyway, I fully agree with Björn that there is no urgent need, so I don't > have a strong opinion to fix this in Prometheus now, but anyway I would love > to hear more opinions on the incoming DevSummit +1 Looks like thanks to Björn > we already have that on our agenda. > > Thanks for raising this Sylvain. > > Kind Regards, > Bartek > > On Thu, 12 Mar 2020 at 16:47, Julien Pivotto wrote: >> >> On 12 Mar 17:42, Bjoern Rabenstein wrote: >> > On 11.03.20 23:58, Sylvain Rabot wrote: >> > > Several maintainers have given their thoughts on the subjects now. >> > > >> > > What would be the next step ? >> > > >> > > Should this be put to a vote ? >> > >> > We could. >> > >> > My personal opinion is that if somebody commits to do the work of >> > changing our build processes to not use/have the `vendor` directory, >> > I'd be for it. >> > >> > However, from the mail conversation and also from some personal >> > communication I had with a few team members, there are many who don't >> > really want to change the status quo right now, and some even prefer >> > to keep the `vendor` directory around. >> > >> > Since the current state doesn't really block any other feature >> > development, and since the appetite for change doesn't seem to be very >> > high generally, I would say this is not super pressing at the moment, >> > and I wouldn't spin up the machinery of a formal vote for it right >> > now. It might, however, be a great topic to discuss at the next >> > developer summit. I have already added it to the agenda. (It was >> > planned to happen during KubeCon EU. Since the latter has been >> > postponed, we might do a virtual summit, but that's not finalized >> > yet.) >> >> After reading everything, I personally don't object to remove the vendor >> directory. My personal gut is to keep it but there don't seem to be a >> lot of good technical reasons to do so. >> >> My very preferred choice would be to remove it but still to archive a >> 'vendor' directory within our CI process (next to the binaries?) to >> ensure we still have the exact code around. >> >> +1 to put it on the dev summit agenda. >> >> -- >> (o-Julien Pivotto >> //\Open-Source Consultant >> V_/_ Inuits - https://www.inuits.eu >> >> -- >> 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 prometheus-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/20200312164709.GA21031%40oxygen. > > -- > 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 prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYMRzrpwWAZ4xGAzLp7jDdn1rHC%2B8Tb9vGuz6%2Bcrj4U%2BQ%40mail.gmail.com. -- 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 prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAM6RFu5WBK4nJTgNKX%3D3q3eFNSq9VRpEixzUJ22%3DdfPRuFm5LA%40mail.gmail.com.
Re: [prometheus-developers] Removing Vendor
I would love to have it removed, and in fact, I plan in my personal time to blog post and talk more about not storing someone else code in your own repository and why the vendor is (IMO) evil (: I hope also to help in any tooling that will fix the malicious dep problem without vendoring as well. Anyway, I fully agree with Björn that there is no urgent need, so I don't have a strong opinion to fix this in Prometheus now, but anyway I would love to hear more opinions on the incoming DevSummit +1 Looks like thanks to Björn we already have that on our agenda. Thanks for raising this Sylvain. Kind Regards, Bartek On Thu, 12 Mar 2020 at 16:47, Julien Pivotto wrote: > On 12 Mar 17:42, Bjoern Rabenstein wrote: > > On 11.03.20 23:58, Sylvain Rabot wrote: > > > Several maintainers have given their thoughts on the subjects now. > > > > > > What would be the next step ? > > > > > > Should this be put to a vote ? > > > > We could. > > > > My personal opinion is that if somebody commits to do the work of > > changing our build processes to not use/have the `vendor` directory, > > I'd be for it. > > > > However, from the mail conversation and also from some personal > > communication I had with a few team members, there are many who don't > > really want to change the status quo right now, and some even prefer > > to keep the `vendor` directory around. > > > > Since the current state doesn't really block any other feature > > development, and since the appetite for change doesn't seem to be very > > high generally, I would say this is not super pressing at the moment, > > and I wouldn't spin up the machinery of a formal vote for it right > > now. It might, however, be a great topic to discuss at the next > > developer summit. I have already added it to the agenda. (It was > > planned to happen during KubeCon EU. Since the latter has been > > postponed, we might do a virtual summit, but that's not finalized > > yet.) > > After reading everything, I personally don't object to remove the vendor > directory. My personal gut is to keep it but there don't seem to be a > lot of good technical reasons to do so. > > My very preferred choice would be to remove it but still to archive a > 'vendor' directory within our CI process (next to the binaries?) to > ensure we still have the exact code around. > > +1 to put it on the dev summit agenda. > > -- > (o-Julien Pivotto > //\Open-Source Consultant > V_/_ Inuits - https://www.inuits.eu > > -- > 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 prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/20200312164709.GA21031%40oxygen > . > -- 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 prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwYMRzrpwWAZ4xGAzLp7jDdn1rHC%2B8Tb9vGuz6%2Bcrj4U%2BQ%40mail.gmail.com.
Re: [prometheus-developers] New function join_label_sorted()
I think alerting on min (up) by (instance,job) == 0 might work too in
this case.
On 13 Mar 09:26, Ben Kochie wrote:
> Are you sure you're not looking for inhibit rules?
>
> https://prometheus.io/docs/alerting/configuration/#inhibit_rule
>
> This allows one alert to inhibit another alert from firing.
>
> On Fri, Mar 13, 2020 at 12:35 AM D wrote:
>
> > Hi All,
> >
> > I am interested in adding (or having) a new function join_label_sorted()
> > which will be similar to join_label(). It is described as:
> >
> > For each timeseries in v, label_join_sorted(v instant-vector, dst_label,
> > string, separator string, src_label1 string, src_label2 string...) joins
> > all the values of all the src_labels using separator and returns the
> > timeseries with the label dst_label contained the joined value such that
> > joined value is concatenation of original values in sorted order. There can
> > be any number of src_labels in this function.
> >
> > The following example will return a vector with each time series having a
> > foo label with the value 7_9_12 added to it.
> >
> > label_join_sorted(up{job="api-server",src1="12",src2="7",src3="9"}, "foo",
> > "_", "src1", "src2", "src3")
> >
> > It will help me write alarming rules where I can do group by based on
> > the composite label-value. I am not sure if we can achieve it today using
> > UNLESS clause or so. Let me elaborate with an example to understand why
> > this is a requirement. Let's consider that are two services or devices
> > which are connected as follows:
> >
> > A--B
> >
> > Suppose the logical/physical connection between A or B goes down, metrics
> > collected from/for each end-point can potentially trigger an alarm. Metric
> > from A will generate an alarm with labels - local node is A and remote node
> > is B. Metric from B will generate an alarm with swapped values. Since the
> > underlying issue could be same, we don't want to generate both the alarms
> > because JIRA fails to de-dup such issues more often than not.
> >
> >
> > Thanks,
> > Dhiman
> >
> >
> > --
> > 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 prometheus-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/prometheus-developers/CAB2OGjzJY8hHBUXWRsTqQ4EuDt4kFRSiordgfdS3BD1-S15-Tg%40mail.gmail.com
> >
> > .
> >
>
> --
> 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 prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CABbyFmrDwLtXd0GSfNVOvL0%3D05P1-wwZA4FQZJCjM4BOd4Uppw%40mail.gmail.com.
--
(o-Julien Pivotto
//\Open-Source Consultant
V_/_ Inuits - https://www.inuits.eu
--
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 prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-developers/20200313082849.GA4604%40oxygen.
signature.asc
Description: PGP signature
Re: [prometheus-developers] New function join_label_sorted()
Are you sure you're not looking for inhibit rules?
https://prometheus.io/docs/alerting/configuration/#inhibit_rule
This allows one alert to inhibit another alert from firing.
On Fri, Mar 13, 2020 at 12:35 AM D wrote:
> Hi All,
>
> I am interested in adding (or having) a new function join_label_sorted()
> which will be similar to join_label(). It is described as:
>
> For each timeseries in v, label_join_sorted(v instant-vector, dst_label,
> string, separator string, src_label1 string, src_label2 string...) joins
> all the values of all the src_labels using separator and returns the
> timeseries with the label dst_label contained the joined value such that
> joined value is concatenation of original values in sorted order. There can
> be any number of src_labels in this function.
>
> The following example will return a vector with each time series having a
> foo label with the value 7_9_12 added to it.
>
> label_join_sorted(up{job="api-server",src1="12",src2="7",src3="9"}, "foo",
> "_", "src1", "src2", "src3")
>
> It will help me write alarming rules where I can do group by based on
> the composite label-value. I am not sure if we can achieve it today using
> UNLESS clause or so. Let me elaborate with an example to understand why
> this is a requirement. Let's consider that are two services or devices
> which are connected as follows:
>
> A--B
>
> Suppose the logical/physical connection between A or B goes down, metrics
> collected from/for each end-point can potentially trigger an alarm. Metric
> from A will generate an alarm with labels - local node is A and remote node
> is B. Metric from B will generate an alarm with swapped values. Since the
> underlying issue could be same, we don't want to generate both the alarms
> because JIRA fails to de-dup such issues more often than not.
>
>
> Thanks,
> Dhiman
>
>
> --
> 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 prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CAB2OGjzJY8hHBUXWRsTqQ4EuDt4kFRSiordgfdS3BD1-S15-Tg%40mail.gmail.com
>
> .
>
--
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 prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/prometheus-developers/CABbyFmrDwLtXd0GSfNVOvL0%3D05P1-wwZA4FQZJCjM4BOd4Uppw%40mail.gmail.com.
