[prometheus-developers] Manage alertmanager config using Prometheus operator

[EnthuDeveloper]

Hi There,
I am looking for some recommendations as to how we can manage alertmanager 
configuration ( like webhook receiver details , feed alerts rules to Prometheus 
etc. ) using Prometheus operator (helm charts ) ??

I see installing Prometheus operator installs Prometheus and Alertmanager both 
but finding it hard to determine where is it getting the default configuration 
from ? And how can it be tweaked to install custom configuration as such,

Any inputs would be much appreciated.


Thanks.

-- 
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/58b31634-95c8-4b98-9eae-1703103c69d8%40googlegroups.com.

Re: [prometheus-developers] Removing Vendor

[Brian Brazil]

On Mon, 9 Mar 2020 at 19:59, Bartłomiej Płotka  wrote:

> Unpopular opinion: IMO vendoring can be long term a really bad pattern.
> The go.mod, go modules or any other dependency management tool or dep
> caching (e.g GOPROXY) was created *exactly* to avoid copying all the
> dependencies to your repository. (:
>
> So I would be happy to remove vendor dir and work towards safe caching
> dependencies in some other repository, GOPROXY etc.
>
> > I'm talking about vendoring in general. We'd want a good reason to
> change our build system in this way, and I'm not aware of any reason why
> we'd want to change this with our current build system.
>
> *Fair. Would be nice to enumerate the downsides:*
>
> *  We update deps mostly when adding some feature etc. This means
> usually us being lazy and doing feature code + committing thousands of
> files. Fun to review. Splitting by commit does not really help. Rarely we
> review like this and still it's super noisy, it's easy to miss a meaningful
> change in our codebase hidden among 300k lines of codes. ):
>
* Repo size dramatically larger. Cloning etc operations e.g. CI checkout.
> * Git stats totally malformed (lines changed).
> * We host in our repo **not our code**.
>
> > Having it locally is handy for debugging, and it means we at least have
> a copy and a clear record of what changed when. It also more easily allows
> for local development.
>
> I don't get it. go.mod and go.sum are versioned so those already give the
> clear record. For local development `go mod vendor` locally is a one-off
> step (local vendor will keep being updated for lifetime of your local
> repo), so I don't any problem with this.
>

Not an easy to debug record though, as you'd have to indirect through at
least one other repo to figure out what changed. As I see it the costs are
low, so there's no major reason to change things currently.

Brian


>
> I think the main argument for having a vendor folder is to be safe on a
> malicious act of dependency actor, which removes or compromises the
> dependency. Anyone can replace the code for a given tag anytime really (:
> Given that it never happened, not sure if worth pursuing. Wonder why no one
> thought about some separate repo solution just for deps then (:
>
> Bartek
>
> On Mon, 9 Mar 2020 at 18:19, Sylvain Rabot  wrote:
>
>> On Mon, 9 Mar 2020 at 16:54, Brian Brazil <
>> brian.bra...@robustperception.io> wrote:
>>
>>> On Mon, 9 Mar 2020 at 15:41, Julien Pivotto 
>>> wrote:
>>>
 On 09 Mar 15:30, Brian Brazil wrote:
 > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
 wrote:
 >
 > > Hi there,
 > >
 > > Sylvain has open a pull request to remove the vendor directory. We
 had
 > > larger threads before on versioning etc, but I would like to start
 a new
 > > thread about this particular topic to see if we have a consensus.
 > >
 > > https://github.com/prometheus/prometheus/pull/6949
 > >
 > > One of the blocker I have is that I would like to be 100% sure that
 the
 > > checks that are run by CNCF on licence compatibility have full
 support
 > > for this, e.g. they can fetch the modules and scan the licenses.
 > >
 >
 > The question here is that as this is all internal, does this make
 sense for
 > our build processes?


 Can you clarify the question. Are you speaking about removing vendoring
 or license check?

>>>
>>> I'm talking about vendoring in general. We'd want a good reason to
>>> change our build system in this way, and I'm not aware of any reason why
>>> we'd want to change this with our current build system.
>>>
>>
>>>
 > I don't recall offhand anyone in -team having issues with our current
 state
 > (beyond a brief discussion if we still wanted it when we switched to
 go-mod
 > - we do).

 I am all for keeping vendor but I have not really strong arguments
 against removing it.

 I often use it to grep some dependencies sources but I could still run
 go mod vendor locally.

>>>
>>> Having it locally is handy for debugging, and it means we at least have
>>> a copy and a clear record of what changed when. It also more easily allows
>>> for local development.
>>>
>>
>> I personally don't have any trouble doing any of that without vendoring.
>>
>> Also, it's much easier to keep track of what happened to the dependencies
>> in the history of the go.mod than in the vendor/ dir.
>>
>> I admit it can be handy to grep in the vendor/ dir although I personally
>> hate it when I'm looking for something and I get submerged by results in
>> the vendor/ dir.
>>
>>
>>> --
>>> Brian Brazil
>>> www.robustperception.io
>>>
>>> --
>>> 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 

Re: [prometheus-developers] Removing Vendor

[Sylvain Rabot]

I wish I would have been able to write this argument.

Thanks Bartek.

On Mon, 9 Mar 2020 at 20:59, Bartłomiej Płotka  wrote:

> Unpopular opinion: IMO vendoring can be long term a really bad pattern.
> The go.mod, go modules or any other dependency management tool or dep
> caching (e.g GOPROXY) was created *exactly* to avoid copying all the
> dependencies to your repository. (:
>
> So I would be happy to remove vendor dir and work towards safe caching
> dependencies in some other repository, GOPROXY etc.
>
> > I'm talking about vendoring in general. We'd want a good reason to
> change our build system in this way, and I'm not aware of any reason why
> we'd want to change this with our current build system.
>
> *Fair. Would be nice to enumerate the downsides:*
>
> *  We update deps mostly when adding some feature etc. This means
> usually us being lazy and doing feature code + committing thousands of
> files. Fun to review. Splitting by commit does not really help. Rarely we
> review like this and still it's super noisy, it's easy to miss a meaningful
> change in our codebase hidden among 300k lines of codes. ):
> * Repo size dramatically larger. Cloning etc operations e.g. CI checkout.
> * Git stats totally malformed (lines changed).
> * We host in our repo **not our code**.
>
> > Having it locally is handy for debugging, and it means we at least have
> a copy and a clear record of what changed when. It also more easily allows
> for local development.
>
> I don't get it. go.mod and go.sum are versioned so those already give the
> clear record. For local development `go mod vendor` locally is a one-off
> step (local vendor will keep being updated for lifetime of your local
> repo), so I don't any problem with this.
>
> I think the main argument for having a vendor folder is to be safe on a
> malicious act of dependency actor, which removes or compromises the
> dependency. Anyone can replace the code for a given tag anytime really (:
> Given that it never happened, not sure if worth pursuing. Wonder why no one
> thought about some separate repo solution just for deps then (:
>
> Bartek
>
> On Mon, 9 Mar 2020 at 18:19, Sylvain Rabot  wrote:
>
>> On Mon, 9 Mar 2020 at 16:54, Brian Brazil <
>> brian.bra...@robustperception.io> wrote:
>>
>>> On Mon, 9 Mar 2020 at 15:41, Julien Pivotto 
>>> wrote:
>>>
 On 09 Mar 15:30, Brian Brazil wrote:
 > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
 wrote:
 >
 > > Hi there,
 > >
 > > Sylvain has open a pull request to remove the vendor directory. We
 had
 > > larger threads before on versioning etc, but I would like to start
 a new
 > > thread about this particular topic to see if we have a consensus.
 > >
 > > https://github.com/prometheus/prometheus/pull/6949
 > >
 > > One of the blocker I have is that I would like to be 100% sure that
 the
 > > checks that are run by CNCF on licence compatibility have full
 support
 > > for this, e.g. they can fetch the modules and scan the licenses.
 > >
 >
 > The question here is that as this is all internal, does this make
 sense for
 > our build processes?


 Can you clarify the question. Are you speaking about removing vendoring
 or license check?

>>>
>>> I'm talking about vendoring in general. We'd want a good reason to
>>> change our build system in this way, and I'm not aware of any reason why
>>> we'd want to change this with our current build system.
>>>
>>
>>>
 > I don't recall offhand anyone in -team having issues with our current
 state
 > (beyond a brief discussion if we still wanted it when we switched to
 go-mod
 > - we do).

 I am all for keeping vendor but I have not really strong arguments
 against removing it.

 I often use it to grep some dependencies sources but I could still run
 go mod vendor locally.

>>>
>>> Having it locally is handy for debugging, and it means we at least have
>>> a copy and a clear record of what changed when. It also more easily allows
>>> for local development.
>>>
>>
>> I personally don't have any trouble doing any of that without vendoring.
>>
>> Also, it's much easier to keep track of what happened to the dependencies
>> in the history of the go.mod than in the vendor/ dir.
>>
>> I admit it can be handy to grep in the vendor/ dir although I personally
>> hate it when I'm looking for something and I get submerged by results in
>> the vendor/ dir.
>>
>>
>>> --
>>> Brian Brazil
>>> www.robustperception.io
>>>
>>> --
>>> 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
>>> 

Re: [prometheus-developers] Removing Vendor

[Bartłomiej Płotka]

Unpopular opinion: IMO vendoring can be long term a really bad pattern. The
go.mod, go modules or any other dependency management tool or dep caching
(e.g GOPROXY) was created *exactly* to avoid copying all the dependencies
to your repository. (:

So I would be happy to remove vendor dir and work towards safe caching
dependencies in some other repository, GOPROXY etc.

> I'm talking about vendoring in general. We'd want a good reason to change
our build system in this way, and I'm not aware of any reason why we'd want
to change this with our current build system.

*Fair. Would be nice to enumerate the downsides:*

*  We update deps mostly when adding some feature etc. This means
usually us being lazy and doing feature code + committing thousands of
files. Fun to review. Splitting by commit does not really help. Rarely we
review like this and still it's super noisy, it's easy to miss a meaningful
change in our codebase hidden among 300k lines of codes. ):
* Repo size dramatically larger. Cloning etc operations e.g. CI checkout.
* Git stats totally malformed (lines changed).
* We host in our repo **not our code**.

> Having it locally is handy for debugging, and it means we at least have a
copy and a clear record of what changed when. It also more easily allows
for local development.

I don't get it. go.mod and go.sum are versioned so those already give the
clear record. For local development `go mod vendor` locally is a one-off
step (local vendor will keep being updated for lifetime of your local
repo), so I don't any problem with this.

I think the main argument for having a vendor folder is to be safe on a
malicious act of dependency actor, which removes or compromises the
dependency. Anyone can replace the code for a given tag anytime really (:
Given that it never happened, not sure if worth pursuing. Wonder why no one
thought about some separate repo solution just for deps then (:

Bartek

On Mon, 9 Mar 2020 at 18:19, Sylvain Rabot  wrote:

> On Mon, 9 Mar 2020 at 16:54, Brian Brazil <
> brian.bra...@robustperception.io> wrote:
>
>> On Mon, 9 Mar 2020 at 15:41, Julien Pivotto 
>> wrote:
>>
>>> On 09 Mar 15:30, Brian Brazil wrote:
>>> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
>>> wrote:
>>> >
>>> > > Hi there,
>>> > >
>>> > > Sylvain has open a pull request to remove the vendor directory. We
>>> had
>>> > > larger threads before on versioning etc, but I would like to start a
>>> new
>>> > > thread about this particular topic to see if we have a consensus.
>>> > >
>>> > > https://github.com/prometheus/prometheus/pull/6949
>>> > >
>>> > > One of the blocker I have is that I would like to be 100% sure that
>>> the
>>> > > checks that are run by CNCF on licence compatibility have full
>>> support
>>> > > for this, e.g. they can fetch the modules and scan the licenses.
>>> > >
>>> >
>>> > The question here is that as this is all internal, does this make
>>> sense for
>>> > our build processes?
>>>
>>>
>>> Can you clarify the question. Are you speaking about removing vendoring
>>> or license check?
>>>
>>
>> I'm talking about vendoring in general. We'd want a good reason to change
>> our build system in this way, and I'm not aware of any reason why we'd want
>> to change this with our current build system.
>>
>
>>
>>> > I don't recall offhand anyone in -team having issues with our current
>>> state
>>> > (beyond a brief discussion if we still wanted it when we switched to
>>> go-mod
>>> > - we do).
>>>
>>> I am all for keeping vendor but I have not really strong arguments
>>> against removing it.
>>>
>>> I often use it to grep some dependencies sources but I could still run
>>> go mod vendor locally.
>>>
>>
>> Having it locally is handy for debugging, and it means we at least have a
>> copy and a clear record of what changed when. It also more easily allows
>> for local development.
>>
>
> I personally don't have any trouble doing any of that without vendoring.
>
> Also, it's much easier to keep track of what happened to the dependencies
> in the history of the go.mod than in the vendor/ dir.
>
> I admit it can be handy to grep in the vendor/ dir although I personally
> hate it when I'm looking for something and I get submerged by results in
> the vendor/ dir.
>
>
>> --
>> Brian Brazil
>> www.robustperception.io
>>
>> --
>> 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/CAHJKeLqvvbvXvfMaDJomBM10hs2pLkiY6Q9fyuQZfo537b%2Bm6g%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Sylvain Rabot 
>
> --
> You received this message because you are subscribed to the 

Re: [prometheus-developers] Removing Vendor

[Sylvain Rabot]

On Mon, 9 Mar 2020 at 16:54, Brian Brazil 
wrote:

> On Mon, 9 Mar 2020 at 15:41, Julien Pivotto 
> wrote:
>
>> On 09 Mar 15:30, Brian Brazil wrote:
>> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
>> wrote:
>> >
>> > > Hi there,
>> > >
>> > > Sylvain has open a pull request to remove the vendor directory. We had
>> > > larger threads before on versioning etc, but I would like to start a
>> new
>> > > thread about this particular topic to see if we have a consensus.
>> > >
>> > > https://github.com/prometheus/prometheus/pull/6949
>> > >
>> > > One of the blocker I have is that I would like to be 100% sure that
>> the
>> > > checks that are run by CNCF on licence compatibility have full support
>> > > for this, e.g. they can fetch the modules and scan the licenses.
>> > >
>> >
>> > The question here is that as this is all internal, does this make sense
>> for
>> > our build processes?
>>
>>
>> Can you clarify the question. Are you speaking about removing vendoring
>> or license check?
>>
>
> I'm talking about vendoring in general. We'd want a good reason to change
> our build system in this way, and I'm not aware of any reason why we'd want
> to change this with our current build system.
>

>
>> > I don't recall offhand anyone in -team having issues with our current
>> state
>> > (beyond a brief discussion if we still wanted it when we switched to
>> go-mod
>> > - we do).
>>
>> I am all for keeping vendor but I have not really strong arguments
>> against removing it.
>>
>> I often use it to grep some dependencies sources but I could still run
>> go mod vendor locally.
>>
>
> Having it locally is handy for debugging, and it means we at least have a
> copy and a clear record of what changed when. It also more easily allows
> for local development.
>

I personally don't have any trouble doing any of that without vendoring.

Also, it's much easier to keep track of what happened to the dependencies
in the history of the go.mod than in the vendor/ dir.

I admit it can be handy to grep in the vendor/ dir although I personally
hate it when I'm looking for something and I get submerged by results in
the vendor/ dir.


> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLqvvbvXvfMaDJomBM10hs2pLkiY6Q9fyuQZfo537b%2Bm6g%40mail.gmail.com
> 
> .
>


-- 
Sylvain Rabot 

-- 
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/CADjtP1Fwqi_rn_27vZRgfUUwUj1QBGQeyPnVnZY8CHimtWcYvQ%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

[Brian Brazil]

On Mon, 9 Mar 2020 at 15:41, Julien Pivotto  wrote:

> On 09 Mar 15:30, Brian Brazil wrote:
> > On Mon, 9 Mar 2020 at 15:26, Julien Pivotto 
> wrote:
> >
> > > Hi there,
> > >
> > > Sylvain has open a pull request to remove the vendor directory. We had
> > > larger threads before on versioning etc, but I would like to start a
> new
> > > thread about this particular topic to see if we have a consensus.
> > >
> > > https://github.com/prometheus/prometheus/pull/6949
> > >
> > > One of the blocker I have is that I would like to be 100% sure that the
> > > checks that are run by CNCF on licence compatibility have full support
> > > for this, e.g. they can fetch the modules and scan the licenses.
> > >
> >
> > The question here is that as this is all internal, does this make sense
> for
> > our build processes?
>
>
> Can you clarify the question. Are you speaking about removing vendoring
> or license check?
>

I'm talking about vendoring in general. We'd want a good reason to change
our build system in this way, and I'm not aware of any reason why we'd want
to change this with our current build system.


> > I don't recall offhand anyone in -team having issues with our current
> state
> > (beyond a brief discussion if we still wanted it when we switched to
> go-mod
> > - we do).
>
> I am all for keeping vendor but I have not really strong arguments
> against removing it.
>
> I often use it to grep some dependencies sources but I could still run
> go mod vendor locally.
>

Having it locally is handy for debugging, and it means we at least have a
copy and a clear record of what changed when. It also more easily allows
for local development.

-- 
Brian Brazil
www.robustperception.io

-- 
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/CAHJKeLqvvbvXvfMaDJomBM10hs2pLkiY6Q9fyuQZfo537b%2Bm6g%40mail.gmail.com.

Re: [prometheus-developers] Removing Vendor

[Julien Pivotto]

On 09 Mar 15:30, Brian Brazil wrote:
> On Mon, 9 Mar 2020 at 15:26, Julien Pivotto  wrote:
> 
> > Hi there,
> >
> > Sylvain has open a pull request to remove the vendor directory. We had
> > larger threads before on versioning etc, but I would like to start a new
> > thread about this particular topic to see if we have a consensus.
> >
> > https://github.com/prometheus/prometheus/pull/6949
> >
> > One of the blocker I have is that I would like to be 100% sure that the
> > checks that are run by CNCF on licence compatibility have full support
> > for this, e.g. they can fetch the modules and scan the licenses.
> >
> 
> The question here is that as this is all internal, does this make sense for
> our build processes?


Can you clarify the question. Are you speaking about removing vendoring
or license check?


> I don't recall offhand anyone in -team having issues with our current state
> (beyond a brief discussion if we still wanted it when we switched to go-mod
> - we do).

I am all for keeping vendor but I have not really strong arguments
against removing it.

I often use it to grep some dependencies sources but I could still run
go mod vendor locally.

> 
> -- 
> Brian Brazil
> www.robustperception.io

-- 
 (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/20200309154120.GA365%40oxygen.


signature.asc
Description: PGP signature

Re: [prometheus-developers] Removing Vendor

[Brian Brazil]

On Mon, 9 Mar 2020 at 15:26, Julien Pivotto  wrote:

> Hi there,
>
> Sylvain has open a pull request to remove the vendor directory. We had
> larger threads before on versioning etc, but I would like to start a new
> thread about this particular topic to see if we have a consensus.
>
> https://github.com/prometheus/prometheus/pull/6949
>
> One of the blocker I have is that I would like to be 100% sure that the
> checks that are run by CNCF on licence compatibility have full support
> for this, e.g. they can fetch the modules and scan the licenses.
>

The question here is that as this is all internal, does this make sense for
our build processes?
I don't recall offhand anyone in -team having issues with our current state
(beyond a brief discussion if we still wanted it when we switched to go-mod
- we do).

-- 
Brian Brazil
www.robustperception.io

-- 
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/CAHJKeLpKHBWC2NkrSofMqTY9iP%3DB6j2j2%2B-Sb0kSCt%3Drm8s-zA%40mail.gmail.com.

[prometheus-developers] Removing Vendor

[Julien Pivotto]

Hi there,

Sylvain has open a pull request to remove the vendor directory. We had
larger threads before on versioning etc, but I would like to start a new
thread about this particular topic to see if we have a consensus.

https://github.com/prometheus/prometheus/pull/6949

One of the blocker I have is that I would like to be 100% sure that the
checks that are run by CNCF on licence compatibility have full support
for this, e.g. they can fetch the modules and scan the licenses.

-- 
 (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/20200309152603.GA25698%40oxygen.


signature.asc
Description: PGP signature