Re: [prometheus-developers] Removing Vendor
On Tue, 10 Mar 2020 at 16:46, Bartłomiej Płotka wrote: > Also, side note: In the event of some dependency disappearing we would > need to get the old code (locally, other forks etc) anyway and fork it for > long term usage ASAP for further development of Prometheus anyway, so I > don't see how vendoring help here either. (: > I'm not following your logic here, we currently already have a copy of the code sitting right there. Brian > > Bartek > > On Tue, 10 Mar 2020 at 16:37, Julius Volz wrote: > >> I used to really care about keeping vendoring because it's the only way >> to make sure you really still have a copy of everything you need to build >> Prometheus no matter what dependency authors or hosts choose to do, but I >> guess the existence of module proxies and the fact that we also don't >> vendor "node_modules" (because that would be huge) is pushing me into the >> direction of caring less about it nowadays. >> >> So I guess I don't mind either way now. >> >> On Tue, Mar 10, 2020 at 2:37 PM Julien Pivotto >> wrote: >> >>> On 10 Mar 14:11, Bjoern Rabenstein wrote: >>> > On 10.03.20 13:48, Julien Pivotto wrote: >>> > > >>> > > As far as I know the main go proxies are maintained by google, and we >>> > > can not afford hosting one for the project in the long term. Google >>> is >>> > > not really known for their long-term commitments. >>> > > >>> > > I know that in the past we wanted to rebuild old releases of >>> prometheus >>> > > and could not (for unrelated reasons!). If now (or in X years) the >>> > > goproxy decides to garbage collect dependencies untouched for x >>> months >>> > > and the upstream is gone, rebuilding old releases will be even more >>> > > difficult. >>> > >>> > There are plenty of non-Google-run go-modules proxy. And should Google >>> > really shutdown hosting go-modules, I'm sure there will be even more. >>> > >>> > And even if they all disappear, the git-hosting platforms that have >>> > the source code can still give you the old versions of the source. >>> > >>> > And even if they all disappear, you or me or somebody else will still >>> > have a clone of the Git repo on their laptop. >>> > >>> > In sum, I highly doubt that reconstructing the source code for an old >>> > version will ever be impossible. It might be a bit inconvenient, but >>> > the necessity of building old versions of Prometheus is rare enough >>> > that it's not really of practical relevance. I would much prefer >>> > leaner source repositories. >>> > >>> > -- >>> > Björn Rabenstein >>> > [PGP-ID] 0x851C3DA17D748D03 >>> > [email] bjo...@rabenste.in >>> >>> Note: CNCF will adapt the tooling to support go.mod and go.sum so that >>> question is out of the table. >>> >>> -- >>> (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/20200310133729.GB22487%40oxygen >>> . >>> >> -- 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/CAHJKeLrNxz%3DthSp5ij8CkUkAtgTi61rvjMObkcxfO3VW2BjbhA%40mail.gmail.com.
Re: [prometheus-developers] Removing Vendor
Also, side note: In the event of some dependency disappearing we would need to get the old code (locally, other forks etc) anyway and fork it for long term usage ASAP for further development of Prometheus anyway, so I don't see how vendoring help here either. (: Bartek On Tue, 10 Mar 2020 at 16:37, Julius Volz wrote: > I used to really care about keeping vendoring because it's the only way to > make sure you really still have a copy of everything you need to build > Prometheus no matter what dependency authors or hosts choose to do, but I > guess the existence of module proxies and the fact that we also don't > vendor "node_modules" (because that would be huge) is pushing me into the > direction of caring less about it nowadays. > > So I guess I don't mind either way now. > > On Tue, Mar 10, 2020 at 2:37 PM Julien Pivotto > wrote: > >> On 10 Mar 14:11, Bjoern Rabenstein wrote: >> > On 10.03.20 13:48, Julien Pivotto wrote: >> > > >> > > As far as I know the main go proxies are maintained by google, and we >> > > can not afford hosting one for the project in the long term. Google is >> > > not really known for their long-term commitments. >> > > >> > > I know that in the past we wanted to rebuild old releases of >> prometheus >> > > and could not (for unrelated reasons!). If now (or in X years) the >> > > goproxy decides to garbage collect dependencies untouched for x months >> > > and the upstream is gone, rebuilding old releases will be even more >> > > difficult. >> > >> > There are plenty of non-Google-run go-modules proxy. And should Google >> > really shutdown hosting go-modules, I'm sure there will be even more. >> > >> > And even if they all disappear, the git-hosting platforms that have >> > the source code can still give you the old versions of the source. >> > >> > And even if they all disappear, you or me or somebody else will still >> > have a clone of the Git repo on their laptop. >> > >> > In sum, I highly doubt that reconstructing the source code for an old >> > version will ever be impossible. It might be a bit inconvenient, but >> > the necessity of building old versions of Prometheus is rare enough >> > that it's not really of practical relevance. I would much prefer >> > leaner source repositories. >> > >> > -- >> > Björn Rabenstein >> > [PGP-ID] 0x851C3DA17D748D03 >> > [email] bjo...@rabenste.in >> >> Note: CNCF will adapt the tooling to support go.mod and go.sum so that >> question is out of the table. >> >> -- >> (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/20200310133729.GB22487%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/CAMssQwaDaPE%2BKYvnUpQrKwG8sPdXS5uRX32B7XMXp8LtTvM1_A%40mail.gmail.com.
Re: [prometheus-developers] Removing Vendor
I used to really care about keeping vendoring because it's the only way to make sure you really still have a copy of everything you need to build Prometheus no matter what dependency authors or hosts choose to do, but I guess the existence of module proxies and the fact that we also don't vendor "node_modules" (because that would be huge) is pushing me into the direction of caring less about it nowadays. So I guess I don't mind either way now. On Tue, Mar 10, 2020 at 2:37 PM Julien Pivotto wrote: > On 10 Mar 14:11, Bjoern Rabenstein wrote: > > On 10.03.20 13:48, Julien Pivotto wrote: > > > > > > As far as I know the main go proxies are maintained by google, and we > > > can not afford hosting one for the project in the long term. Google is > > > not really known for their long-term commitments. > > > > > > I know that in the past we wanted to rebuild old releases of prometheus > > > and could not (for unrelated reasons!). If now (or in X years) the > > > goproxy decides to garbage collect dependencies untouched for x months > > > and the upstream is gone, rebuilding old releases will be even more > > > difficult. > > > > There are plenty of non-Google-run go-modules proxy. And should Google > > really shutdown hosting go-modules, I'm sure there will be even more. > > > > And even if they all disappear, the git-hosting platforms that have > > the source code can still give you the old versions of the source. > > > > And even if they all disappear, you or me or somebody else will still > > have a clone of the Git repo on their laptop. > > > > In sum, I highly doubt that reconstructing the source code for an old > > version will ever be impossible. It might be a bit inconvenient, but > > the necessity of building old versions of Prometheus is rare enough > > that it's not really of practical relevance. I would much prefer > > leaner source repositories. > > > > -- > > Björn Rabenstein > > [PGP-ID] 0x851C3DA17D748D03 > > [email] bjo...@rabenste.in > > Note: CNCF will adapt the tooling to support go.mod and go.sum so that > question is out of the table. > > -- > (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/20200310133729.GB22487%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/CA%2BT6YozyjabDDVJ-M7EWM-rF%3D8-47iPS5oeQD1Tt6wawN5mTWg%40mail.gmail.com.
Re: [prometheus-developers] Removing Vendor
On 10 Mar 14:11, Bjoern Rabenstein wrote: > On 10.03.20 13:48, Julien Pivotto wrote: > > > > As far as I know the main go proxies are maintained by google, and we > > can not afford hosting one for the project in the long term. Google is > > not really known for their long-term commitments. > > > > I know that in the past we wanted to rebuild old releases of prometheus > > and could not (for unrelated reasons!). If now (or in X years) the > > goproxy decides to garbage collect dependencies untouched for x months > > and the upstream is gone, rebuilding old releases will be even more > > difficult. > > There are plenty of non-Google-run go-modules proxy. And should Google > really shutdown hosting go-modules, I'm sure there will be even more. > > And even if they all disappear, the git-hosting platforms that have > the source code can still give you the old versions of the source. > > And even if they all disappear, you or me or somebody else will still > have a clone of the Git repo on their laptop. > > In sum, I highly doubt that reconstructing the source code for an old > version will ever be impossible. It might be a bit inconvenient, but > the necessity of building old versions of Prometheus is rare enough > that it's not really of practical relevance. I would much prefer > leaner source repositories. > > -- > Björn Rabenstein > [PGP-ID] 0x851C3DA17D748D03 > [email] bjo...@rabenste.in Note: CNCF will adapt the tooling to support go.mod and go.sum so that question is out of the table. -- (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/20200310133729.GB22487%40oxygen. signature.asc Description: PGP signature
Re: [prometheus-developers] Removing Vendor
On 10.03.20 13:48, Julien Pivotto wrote: > > As far as I know the main go proxies are maintained by google, and we > can not afford hosting one for the project in the long term. Google is > not really known for their long-term commitments. > > I know that in the past we wanted to rebuild old releases of prometheus > and could not (for unrelated reasons!). If now (or in X years) the > goproxy decides to garbage collect dependencies untouched for x months > and the upstream is gone, rebuilding old releases will be even more > difficult. There are plenty of non-Google-run go-modules proxy. And should Google really shutdown hosting go-modules, I'm sure there will be even more. And even if they all disappear, the git-hosting platforms that have the source code can still give you the old versions of the source. And even if they all disappear, you or me or somebody else will still have a clone of the Git repo on their laptop. In sum, I highly doubt that reconstructing the source code for an old version will ever be impossible. It might be a bit inconvenient, but the necessity of building old versions of Prometheus is rare enough that it's not really of practical relevance. I would much prefer leaner source repositories. -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] bjo...@rabenste.in -- 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/20200310131122.GO14683%40jahnn.
Re: [prometheus-developers] Removing Vendor
On 10 Mar 13:41, Bjoern Rabenstein wrote: > On 09.03.20 19:59, Bartłomiej Płotka wrote: > > > > 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 (: > > That's what the various go-modules proxies are for. And `go.sum` to > make sure that nobody is injecting modified code. > > In my understanding, the main reason for the `vendor` directory is > that building from vendored sources in the `vendor` directory is an > officially supported feature (introduced in Go 1.11), which should be > kept working, at least for a while, to allow a smoother transition > from previous build workflows to the go-modules one. > > From that perspective (and IMHO), the `vendor` directory can be > removed once most of the Prometheus community has fully embraced > go-modules. Personally, my main concern is that that's not so easy to > assess. The whole go-modules thing is not exactly uncontroversial even > in the Go community at large. As far as I know the main go proxies are maintained by google, and we can not afford hosting one for the project in the long term. Google is not really known for their long-term commitments. I know that in the past we wanted to rebuild old releases of prometheus and could not (for unrelated reasons!). If now (or in X years) the goproxy decides to garbage collect dependencies untouched for x months and the upstream is gone, rebuilding old releases will be even more difficult. My question about license check is still unanswered. I will ping CNCF about this question, too. > > -- > Björn Rabenstein > [PGP-ID] 0x851C3DA17D748D03 > [email] bjo...@rabenste.in -- (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/20200310124818.GA12158%40oxygen. signature.asc Description: PGP signature
Re: [prometheus-developers] Removing Vendor
On 09.03.20 19:59, Bartłomiej Płotka wrote: > > 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 (: That's what the various go-modules proxies are for. And `go.sum` to make sure that nobody is injecting modified code. In my understanding, the main reason for the `vendor` directory is that building from vendored sources in the `vendor` directory is an officially supported feature (introduced in Go 1.11), which should be kept working, at least for a while, to allow a smoother transition from previous build workflows to the go-modules one. >From that perspective (and IMHO), the `vendor` directory can be removed once most of the Prometheus community has fully embraced go-modules. Personally, my main concern is that that's not so easy to assess. The whole go-modules thing is not exactly uncontroversial even in the Go community at large. -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] bjo...@rabenste.in -- 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/20200310124142.GL14683%40jahnn.
Re: [prometheus-developers] Manage alertmanager config using Prometheus operator
On Tue, Mar 10, 2020 at 4:41 AM EnthuDeveloper wrote: > > 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, As stated in the documentation [1], the alertmanager's configuration is taken from the secret specified by the configSecret field. If undefined, the Prometheus operator will look for a secret named "alertmanager-" in the same namespace. This secret needs to have an alertmanager.yaml key as in this example [2]. [1] https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#alertmanagerspec [2] https://github.com/coreos/kube-prometheus/blob/master/manifests/alertmanager-secret.yaml > > 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. -- 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/CAM6RFu7mzA8oLVjQhgVY71qf_GweR5O_gV89CgMqL1EErhchQw%40mail.gmail.com.
