JakeHillion/storj
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
54ae9b040e
storj/go.sum

917 lines
89 KiB
Plaintext
Raw Normal View History

private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
cloud.google.com/go v0.31.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
cloud.google.com/go v0.34.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
cloud.google.com/go v0.37.0/go.mod h1:TS1dMSSfndXH133OKGwekG838Om/cQT0BUHV3HcBgoo=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
cloud.google.com/go v0.37.4/go.mod h1:NHPJ89PdicEuT9hdPXMROBD91xc5uRDxsMtSB16k7hw=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
cloud.google.com/go v0.38.0/go.mod h1:990N+gfupTy94rShfmMCWGDn0LpTmnzTp2qbd1dvSRU=
cloud.google.com/go v0.44.1/go.mod h1:iSa0KzasP4Uvy3f1mN/7PiObzGgflwredwwASm/v6AU=
cloud.google.com/go v0.44.2/go.mod h1:60680Gw3Yr4ikxnPRS/oxxkBccT6SA1yMk63TGekxKY=
cloud.google.com/go v0.45.1/go.mod h1:RpBamKRgapWJb87xiFSdk4g1CME7QZg3uwTez+TSTjc=
cloud.google.com/go v0.46.3/go.mod h1:a6bKKbmY7er1mI7TEI4lsAkts/mkhTSZK8w33B4RAg0=
cloud.google.com/go v0.52.0 h1:GGslhk/BU052LPlnI1vpp3fcbUs+hQ3E+Doti/3/vF8=
cloud.google.com/go v0.52.0/go.mod h1:pXajvRH/6o3+F9jDHZWQ5PbGhn+o8w9qiu/CffaVdO4=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
cloud.google.com/go/bigquery v1.0.1 h1:hL+ycaJpVE9M7nLoiXb/Pn10ENE2u+oddxbD8uu0ZVU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
cloud.google.com/go/bigquery v1.0.1/go.mod h1:i/xbL2UlR5RvWAURpBYZTtm/cXjCha9lbfbpx4poX+o=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
cloud.google.com/go/datastore v1.0.0 h1:Kt+gOPPp2LEPWp8CSfxhsM8ik9CcyE/gYu+0r+RnZvM=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
cloud.google.com/go/datastore v1.0.0/go.mod h1:LXYbyblFSglQ5pkeyhO+Qmw7ukd3C+pD7TKLgZqpHYE=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
cloud.google.com/go/firestore v1.1.0/go.mod h1:ulACoGHTpvq5r8rxGJ4ddJZBZqakUQqClKRT5SZwBmk=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
cloud.google.com/go/pubsub v1.0.1 h1:W9tAK3E57P75u0XLLR82LZyw8VpAnhmyTOxW9qzmyj8=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
cloud.google.com/go/pubsub v1.0.1/go.mod h1:R0Gpsv3s54REJCy4fxDixWD93lHJMoZTyQ2kNxGRt3I=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
cloud.google.com/go/storage v1.0.0 h1:VV2nUM3wwLLGh9lSABFgZMjInyUbJeaRSE64WuAIQ+4=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
cloud.google.com/go/storage v1.0.0/go.mod h1:IhtSnM/ZTZV8YYJWCY8RULGVqBDmpoyjwiyrjsg+URw=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
dmitri.shuralyov.com/app/changes v0.0.0-20180602232624-0a106ad413e3/go.mod h1:Yl+fi1br7+Rr3LqpNJf1/uxUdtRUV+Tnj0o93V2B9MU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
dmitri.shuralyov.com/gpu/mtl v0.0.0-20190408044501-666a987793e9/go.mod h1:H6x//7gZCb22OMCxBHrMx7a5I7Hp++hsVxbQ4BYO7hU=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
dmitri.shuralyov.com/html/belt v0.0.0-20180602232347-f7d459c86be0/go.mod h1:JLBrvjyP0v+ecvNYvCpyZgu5/xkfAUhi6wJj28eUfSU=
dmitri.shuralyov.com/service/change v0.0.0-20181023043359-a85b471d5412/go.mod h1:a1inKt/atXimZ4Mv927x+r7UpyzRUf4emIoiiSC2TN4=
dmitri.shuralyov.com/state v0.0.0-20180228185332-28bcc343414c/go.mod h1:0PRwlb0D6DFvNNtx+9ybjezNCa8XF0xaYcETyp6rHWU=
git.apache.org/thrift.git v0.0.0-20180902110319-2566ecd5d999/go.mod h1:fPE2ZNJGynbRyZ4dJvy6G277gSllfV2HJqblrnkyeyg=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78 h1:w+iIsaOQNcT7OZ575w+acHgRric5iCyQh+xv+KJ4HB8=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78/go.mod h1:LmzpDX56iTiv29bbRTIsUNlaFfuhWRQBWjQdVyAevI8=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/BurntSushi/toml v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/Microsoft/go-winio v0.4.11 h1:zoIOcVf0xPN1tnMVbTtEdI+P8OofVk3NObnwOQ6nK2Q=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/Microsoft/go-winio v0.4.11/go.mod h1:VhR8bwka0BXejwEJY73c50VrPtXAaKcyvVC4A4RozmA=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/Nvveen/Gotty v0.0.0-20120604004816-cd527374f1e5/go.mod h1:lmUJ/7eu/Q8D7ML55dXQrVaamCz2vxCfdQBasLZfHKk=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/OneOfOne/xxhash v1.2.2/go.mod h1:HSdplMjZKSmBqAxg5vPj2TmRDmfkzw+cTzAElWljhcU=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/Shopify/sarama v1.19.0/go.mod h1:FVkBWblsNy7DGZRfXLU0O9RCGt5g3g3yEuWXgklEdEo=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/Shopify/toxiproxy v2.1.4+incompatible/go.mod h1:OXgGpZ6Cli1/URJOF1DMxUHB2q5Ap20/P/eIdh4G0pI=
cmd/uplink: fix progressbar data race (#2987)
2019-09-10 09:51:49 +01:00
github.com/VividCortex/ewma v1.1.1 h1:MnEK4VOv6n0RSY4vtRe3h11qjxL3+t0B8yOL8iMXdcM=
github.com/VividCortex/ewma v1.1.1/go.mod h1:2Tkkvm3sRDVXaiyucHiACn4cqf7DpdyLvmxzcbUokwA=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/aead/siphash v1.0.1/go.mod h1:Nywa3cDsYNNK3gaciGTWPwHt0wlpNV15vwmswBAUSII=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc=
github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/alessio/shellescape v1.2.2 h1:8LnL+ncxhWT2TR00dfJRT25JWWrhkMZXneHVWnetDZg=
github.com/alessio/shellescape v1.2.2/go.mod h1:PZAiSCk0LJaZkiCSkPv8qIobYglO3FPpyFjDCtHLS30=
github.com/alicebob/gopher-json v0.0.0-20200520072559-a9ecdc9d1d3a h1:HbKu58rmZpUGpz5+4FfNmIU+FmZg2P3Xaj2v2bfNWmk=
github.com/alicebob/gopher-json v0.0.0-20200520072559-a9ecdc9d1d3a/go.mod h1:SGnFV6hVsYE877CKEZ6tDNTjaSXYUk6QqoIK6PrAtcc=
github.com/alicebob/miniredis/v2 v2.13.3 h1:kohgdtN58KW/r9ZDVmMJE3MrfbumwsDQStd0LPAGmmw=
github.com/alicebob/miniredis/v2 v2.13.3/go.mod h1:uS970Sw5Gs9/iK3yBg0l9Uj9s25wXxSpQUE9EaJ/Blg=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/anmitsu/go-shlex v0.0.0-20161002113705-648efa622239/go.mod h1:2FmKhYUyUczH0OGQWaF5ceTx0UBShxjsH6f8oGKYe2c=
bump storj.io/common to latest and storj.io/drpc to v0.0.11 Change-Id: I7a6e823b441eeff4621dfdf2d6577be76c9761c8
2020-03-24 17:49:20 +00:00
github.com/apache/thrift v0.12.0 h1:pODnxUFNcjP9UTLZGTdeh+j16A8lJbRvD3rOtrk/7bs=
jenkins: work around git.apache.org failures (#2944)
2019-09-04 09:30:59 +01:00
github.com/apache/thrift v0.12.0/go.mod h1:cp2SuWMxlEZw2r+iP2GNCdIi4C1qmUzdZFSVb+bacwQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/armon/circbuf v0.0.0-20150827004946-bbbad097214e/go.mod h1:3U/XgcO3hCbHZ8TKRvWD2dDTCfh9M9ya+I9JpbB7O8o=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/armon/consul-api v0.0.0-20180202201655-eb2c6b5be1b6/go.mod h1:grANhF5doyWs3UAsr3K4I6qtAmlQcZDesFNEHPZAzj8=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/armon/go-metrics v0.0.0-20180917152333-f0300d1749da/go.mod h1:Q73ZrmVTwzkszR9V5SSuryQ31EELlFMUz1kKyl939pY=
github.com/armon/go-radix v0.0.0-20180808171621-7fddfc383310/go.mod h1:ufUuZ+zHj4x4TnLV4JWEpy2hxWSpsRywHrMgIH9cCH8=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/aws/aws-sdk-go v1.17.7/go.mod h1:KmX6BPdI08NWTb3/sm4ZGu5ShLoqVDhKgpiN924inxo=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973/go.mod h1:Dwedo/Wpr24TaqPxmxbtue+5NUziq4I4S80YR8gNf3Q=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/beorn7/perks v1.0.0/go.mod h1:KWe93zE9D1o94FZ5RNwFwVgaQK1VOXiVxmqh+CedLV8=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/bgentry/speakeasy v0.1.0/go.mod h1:+zsyZBPWlz7T6j88CTgSN5bM796AkVf0kBD4zp0CCIs=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/bitly/go-hostpool v0.0.0-20171023180738-a3a6125de932/go.mod h1:NOuUCSz6Q9T7+igc/hlvDOUdtWKryOrtFyIVABv/p7k=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/bketelsen/crypt v0.0.3-0.20200106085610-5cbc8cc4026c/go.mod h1:MKsuJmJgSg28kpZDP6UIiPt0e0Oz0kqKNGyRaWEPv84=
autoupdater: use blang/semver (#3063)
2019-09-20 15:22:40 +01:00
github.com/blang/semver v3.5.1+incompatible h1:cQNTCjp13qL8KC3Nbxr/y2Bqb63oX6wdnnjpJbkM4JQ=
github.com/blang/semver v3.5.1+incompatible/go.mod h1:kRBLl5iJ+tD4TcOOxsy/0fnwebNt5EWlYSAyrTnjyyk=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869/go.mod h1:Ekp36dRnpXw/yCqJaO+ZrUyxD+3VXMFFr56k5XYrpB4=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/bradfitz/go-smtpd v0.0.0-20170404230938-deb6d6237625/go.mod h1:HYsPBTaaSFSlLx/70C2HPIMNZpVV8+vt/A+FMnYP11g=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/btcsuite/btcd v0.20.1-beta/go.mod h1:wVuoA8VJLEcwgqHBwHmzLRazpKxTv13Px/pDuV7OomQ=
github.com/btcsuite/btclog v0.0.0-20170628155309-84c8d2346e9f/go.mod h1:TdznJufoqS23FtqVCzL0ZqgP5MqXbb4fg/WgDys70nA=
github.com/btcsuite/btcutil v0.0.0-20190425235716-9e5f4b9a998d/go.mod h1:+5NJ2+qvTyV9exUAL/rxXi3DcLg2Ts+ymUAY5y4NvMg=
github.com/btcsuite/btcutil v1.0.1/go.mod h1:j9HUFwoQRsZL3V4n+qG+CUnEGHOarIxfC3Le2Yhbcts=
bump to uplink v1.2.0 Also fixup config and related tests for storj.io/common bee93690ab909580993f402b594ad5a14760c39f Change-Id: I6897d925cd28b139c1fc2b43e63b08c0cc3fb688
2020-08-03 17:36:39 +01:00
github.com/btcsuite/btcutil v1.0.2 h1:9iZ1Terx9fMIOtq1VrwdqfsATL9MC2l8ZrUY6YZ2uts=
github.com/btcsuite/btcutil v1.0.2/go.mod h1:j9HUFwoQRsZL3V4n+qG+CUnEGHOarIxfC3Le2Yhbcts=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/btcsuite/go-socks v0.0.0-20170105172521-4720035b7bfd/go.mod h1:HHNXQzUsZCxOoE+CPiyCTO6x34Zs86zZUiwtpXoGdtg=
github.com/btcsuite/goleveldb v0.0.0-20160330041536-7834afc9e8cd/go.mod h1:F+uVaaLLH7j4eDXPRvw78tMflu7Ie2bzYOH4Y8rRKBY=
github.com/btcsuite/snappy-go v0.0.0-20151229074030-0bdef8d06723/go.mod h1:8woku9dyThutzjeg+3xrA5iCpBRH8XEEg3lh6TiUghc=
github.com/btcsuite/websocket v0.0.0-20150119174127-31079b680792/go.mod h1:ghJtEyQwv5/p4Mg4C0fgbePVuGr935/5ddU9Z3TmDRY=
github.com/btcsuite/winsvc v1.0.0/go.mod h1:jsenWakMcC0zFBFurPLEAyrnc/teJEM1O46fmI40EZs=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/buger/jsonparser v0.0.0-20181115193947-bf1c66bbce23/go.mod h1:bbYlZJ7hK1yFx9hf58LP0zeX7UjIGs20ufpu3evjr+s=
all: bump storj.io/common dependency Change-Id: I2e9ba0a76380d99d8650ae6921ed0a3ffe436536
2020-01-06 20:46:06 +00:00
github.com/calebcase/tmpfile v1.0.1/go.mod h1:iErLeG/iqJr8LaQ/gYRv4GXdqssi3jg4iSzvrA06/lw=
satellite/heldamount: payments added, endpoind for payments added Change-Id: Ia2b9580bc353ef614680230c6f82c5bf6ded49c4
2020-06-26 19:43:06 +01:00
github.com/calebcase/tmpfile v1.0.2-0.20200602150926-3af473ef8439/go.mod h1:iErLeG/iqJr8LaQ/gYRv4GXdqssi3jg4iSzvrA06/lw=
bump to uplink v1.2.0 Also fixup config and related tests for storj.io/common bee93690ab909580993f402b594ad5a14760c39f Change-Id: I6897d925cd28b139c1fc2b43e63b08c0cc3fb688
2020-08-03 17:36:39 +01:00
github.com/calebcase/tmpfile v1.0.2 h1:1AGuhKiUu4J6wxz6lxuF6ck3f8G2kaV6KSEny0RGCig=
github.com/calebcase/tmpfile v1.0.2/go.mod h1:iErLeG/iqJr8LaQ/gYRv4GXdqssi3jg4iSzvrA06/lw=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/census-instrumentation/opencensus-proto v0.2.1/go.mod h1:f6KPmirojxKA12rnyqOA5BBL4O983OfeGPqjHWSTneU=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/cespare/xxhash v1.1.0/go.mod h1:XrSqR1VqqWfGrhpAt58auRo0WTKS1nRRg3ghfAqPWnc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/cheekybits/genny v1.0.0 h1:uGGa4nei+j20rOSeDeP5Of12XVm7TGUd4dJA9RDitfE=
github.com/cheekybits/genny v1.0.0/go.mod h1:+tQajlRqAUrPI7DOSpB0XAqZYtQakVtB7wXkRAgjxjQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/cheggaaa/pb/v3 v3.0.5 h1:lmZOti7CraK9RSjzExsY53+WWfub9Qv13B5m4ptEoPE=
github.com/cheggaaa/pb/v3 v3.0.5/go.mod h1:X1L61/+36nz9bjIsrDU52qHKOQukUQe2Ge+YvGuquCw=
mod: upgrade miniredis to latest miniredis 2.5.0 had a bug with matching keys with newlines. Change-Id: I9bcf998459be6d7d4e03bca3589e989e5ed2304d
2020-02-06 12:56:23 +00:00
github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWRnGsAI=
github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e/go.mod h1:nSuG5e5PlCu98SY8svDHJxuZscDgtXS6KTTbou5AhLI=
github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1/go.mod h1:Q3SI9o4m/ZMnBNeIyt5eFwwo7qiLfzFZmjNmxjkiQlU=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/client9/misspell v0.3.4/go.mod h1:qj6jICC3Q7zFZvVWo7KLAzC3yx5G7kyvSDkc90ppPyw=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/cloudfoundry/gosigar v1.1.0 h1:V/dVCzhKOdIU3WRB5inQU20s4yIgL9Dxx/Mhi0SF8eM=
github.com/cloudfoundry/gosigar v1.1.0/go.mod h1:3qLfc2GlfmwOx2+ZDaRGH3Y9fwQ0sQeaAleo2GV5pH0=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/cockroachdb/apd v1.1.0 h1:3LFP3629v+1aKXU5Q37mxmRxX/pIu1nijXydLShEq5I=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/cockroachdb/apd v1.1.0/go.mod h1:8Sl8LxpKi29FqWXR16WEFZRNSz3SoPzUzeMeY4+DwBQ=
github.com/cockroachdb/cockroach-go v0.0.0-20181001143604-e0a95dfd547c/go.mod h1:XGLbWH/ujMcbPbhZq52Nv6UrCghb1yGn//133kEsvDk=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/containerd/containerd v1.2.7 h1:8lqLbl7u1j3MmiL9cJ/O275crSq7bfwUayvvatEupQk=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/containerd/containerd v1.2.7/go.mod h1:bC6axHOhabU15QhwfG7w5PipXdVtMXFTttgp+kVtyUA=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/coreos/bbolt v1.3.2/go.mod h1:iRUV2dpdMOn7Bo10OQBFzIJO9kkE559Wcmn+qkEiiKk=
github.com/coreos/etcd v3.3.10+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/coreos/etcd v3.3.13+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/coreos/go-semver v0.2.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/coreos/go-semver v0.3.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/coreos/go-systemd v0.0.0-20181012123002-c6f51f82210d/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/coreos/go-systemd v0.0.0-20190321100706-95778dfbb74e/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/coreos/go-systemd v0.0.0-20190719114852-fd7a80b32e1f/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
github.com/cpuguy83/go-md2man/v2 v2.0.0/go.mod h1:maD7wRr/U5Z6m/iR4s+kqSMx2CaBsrgA7czyZG/E6dU=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/creack/pty v1.1.7/go.mod h1:lj5s0c3V2DBrqTV7llrYr5NG6My20zk30Fl46Y7DoTY=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/cznic/b v0.0.0-20180115125044-35e9bbe41f07/go.mod h1:URriBxXwVq5ijiJ12C7iIZqlA69nTlI+LgI6/pwftG8=
github.com/cznic/fileutil v0.0.0-20180108211300-6a051e75936f/go.mod h1:8S58EK26zhXSxzv7NQFpnliaOQsmDUxvoQO3rt154Vg=
github.com/cznic/golex v0.0.0-20170803123110-4ab7c5e190e4/go.mod h1:+bmmJDNmKlhWNG+gwWCkaBoTy39Fs+bzRxVBzoTQbIc=
github.com/cznic/internal v0.0.0-20180608152220-f44710a21d00/go.mod h1:olo7eAdKwJdXxb55TKGLiJ6xt1H0/tiiRCWKVLmtjY4=
github.com/cznic/lldb v1.1.0/go.mod h1:FIZVUmYUVhPwRiPzL8nD/mpFcJ/G7SSXjjXYG4uRI3A=
github.com/cznic/mathutil v0.0.0-20180504122225-ca4c9f2c1369/go.mod h1:e6NPNENfs9mPDVNRekM7lKScauxd5kXTr1Mfyig6TDM=
github.com/cznic/ql v1.2.0/go.mod h1:FbpzhyZrqr0PVlK6ury+PoW3T0ODUV22OeWIxcaOrSE=
github.com/cznic/sortutil v0.0.0-20150617083342-4c7342852e65/go.mod h1:q2w6Bg5jeox1B+QkJ6Wp/+Vn0G/bo3f1uY7Fn3vivIQ=
github.com/cznic/strutil v0.0.0-20171016134553-529a34b1c186/go.mod h1:AHHPPPXTw0h6pVabbcbyGRK1DckRn7r/STdZEeIDzZc=
github.com/cznic/zappy v0.0.0-20160723133515-2533cb5b45cc/go.mod h1:Y1SNZ4dRUOKXshKUbwUapqNncRrho4mkjQebgEHZLj8=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/davecgh/go-spew v0.0.0-20171005155431-ecdeabc65495/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/denisenkom/go-mssqldb v0.0.0-20190515213511-eb9f6a1743f3/go.mod h1:zAg7JM8CkOJ43xKXIj7eRO9kmWm/TW578qo+oDO6tuM=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/dgrijalva/jwt-go v3.2.0+incompatible/go.mod h1:E3ru+11k8xSBh+hMPgOLZmtrrCbhqsmaPHjLKYnJCaQ=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/dgryski/go-sip13 v0.0.0-20181026042036-e10d5fee7954/go.mod h1:vAd38F8PWV+bWy6jNmig1y/TA+kYO4g3RSRF0IAv0no=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/dhui/dktest v0.3.0 h1:kwX5a7EkLcjo7VpsPQSYJcKGbXBXdjI9FGjuUj1jn6I=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/dhui/dktest v0.3.0/go.mod h1:cyzIUfGsBEbZ6BT7tnXqAShHSXCZhSNmFl70sZ7c1yc=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/docker/distribution v2.7.0+incompatible h1:neUDAlf3wX6Ml4HdqTrbcOHXtfRN0TFIwt6YFL7N9RU=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/docker/distribution v2.7.0+incompatible/go.mod h1:J2gT2udsDAN96Uj4KfcMRqY0/ypR+oyYUYmja8H+y+w=
github.com/docker/docker v0.7.3-0.20190103212154-2b7e084dc98b/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/docker/docker v0.7.3-0.20190817195342-4760db040282 h1:mzrx39dGtGq0VEnTHjnakmczd4uFbhx2cZU3BJDsLdc=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/docker/docker v0.7.3-0.20190817195342-4760db040282/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/docker/go-connections v0.4.0 h1:El9xVISelRB7BuFusrZozjnkIM5YnzCViNKohAFqRJQ=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/docker/go-connections v0.4.0/go.mod h1:Gbd7IOopHjR8Iph03tsViu4nIes5XhDvyHbTtUxmeec=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/docker/go-units v0.3.3 h1:Xk8S3Xj5sLGlG5g67hJmYMmUgXv5N4PhkjJHHqrwnTk=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/docker/go-units v0.3.3/go.mod h1:fgPhTUdO+D/Jk86RDLlptpiXQzgHJF7gydDDbaIK4Dk=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/dustin/go-humanize v1.0.0/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/eapache/go-resiliency v1.1.0/go.mod h1:kFI+JgMyC7bLPUVY133qvEBtVayf5mFgVsvEsIPBvNs=
github.com/eapache/go-xerial-snappy v0.0.0-20180814174437-776d5712da21/go.mod h1:+020luEh2TKB4/GOp8oxxtq0Daoen/Cii55CzbTV6DU=
github.com/eapache/queue v1.1.0/go.mod h1:6eCeP0CKFpHLu8blIFXhExK/dRa7WDZfr6jVFPTqq+I=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/edsrzf/mmap-go v0.0.0-20170320065105-0bce6a688712/go.mod h1:YO35OhQPt3KJa3ryjFM5Bs14WD66h8eGKpfaBNrHW5M=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/envoyproxy/go-control-plane v0.9.1-0.20191026205805-5f8ba28d4473/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7+kN2VEUnK/pcBlmesArF7c=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/fatih/color v1.7.0/go.mod h1:Zm6kSWBoL9eyXnKyktHP6abPY2pDugNf5KwzbycvMj4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/fatih/color v1.9.0 h1:8xPHl4/q1VyqGIPif1F+1V3Y3lSmrq01EabUW3CoW5s=
github.com/fatih/color v1.9.0/go.mod h1:eQcE1qtQxscV5RaZvpXrrb8Drkc3/DdQ+uUYCNjL+zU=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/flynn/go-shlex v0.0.0-20150515145356-3f9db97f8568/go.mod h1:xEzjJPgXI435gkrCt3MPfRiAkVrwSbHsst4LCFVfpJc=
github.com/francoispqt/gojay v1.2.13/go.mod h1:ehT5mTG4ua4581f1++1WLG0vPdaA9HaiDsoyrBGkyDY=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/fsnotify/fsnotify v1.4.7 h1:IXs+QLmnXW2CcXuY+8Mzv/fWEsPGWxqefPtCP5CnV9I=
github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/fsnotify/fsnotify v1.4.9 h1:hsms1Qyu0jgnwNXIxa+/V/PDsU6CfLf6CNO8H7IWoS4=
github.com/fsnotify/fsnotify v1.4.9/go.mod h1:znqG4EE+3YCdAaPaxE2ZRY/06pZUdp0tY4IgpuI1SZQ=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/fsouza/fake-gcs-server v1.7.0/go.mod h1:5XIRs4YvwNbNoz+1JF8j6KLAyDh7RHGAyAK3EP2EsNk=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/ghodss/yaml v1.0.0/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/gliderlabs/ssh v0.1.1/go.mod h1:U7qILu1NlMHj9FlMhZLlkCdDnU1DBEAqr0aevW3Awn0=
github.com/go-errors/errors v1.0.1/go.mod h1:f4zRHt4oKfwPJE5k8C9vpYG+aDHdBFUsgrm6/TyX73Q=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/go-gl/glfw v0.0.0-20190409004039-e6da0acd62b1/go.mod h1:vR7hzQXu2zJy9AVAgeJqvqgH9Q5CA+iKCZ2gyEVpxRU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/go-gl/glfw/v3.3/glfw v0.0.0-20191125211704-12ad95a8df72/go.mod h1:tQ2UAYgL5IevRw8kRxooKSPJfGvJ9fJQFa0TUsXzTg8=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/go-kit/kit v0.8.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
github.com/go-logfmt/logfmt v0.3.0/go.mod h1:Qt1PoO58o5twSAckw1HlFXLmHsOX5/0LbT9GBnD5lWE=
github.com/go-logfmt/logfmt v0.4.0/go.mod h1:3RMwSq7FuexP4Kalkev3ejPJsZTpXXBr9+V4qmtdjCk=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/go-redis/redis v6.15.9+incompatible h1:K0pv1D7EQUjfyoMql+r/jZqCLizCGKFlFgcHWWmHQjg=
github.com/go-redis/redis v6.15.9+incompatible/go.mod h1:NAIEuMOZ/fxfXJIrKDQDz8wamY7mA7PouImQ2Jvg6kA=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/go-sql-driver/mysql v1.4.1/go.mod h1:zAC/RDZ24gD3HViQzih4MyKcchzm+sOG5ZlKdlhCg5w=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/gocql/gocql v0.0.0-20190301043612-f6df8288f9b4/go.mod h1:4Fw1eo5iaEhDUs8XyuhSVCVy52Jq3L+/3GJgYkwc+/0=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/gofrs/uuid v3.2.0+incompatible h1:y12jRkkFxsd7GpqdSZ+/KCs/fJbqpEXSGd4+jfEaewE=
github.com/gofrs/uuid v3.2.0+incompatible/go.mod h1:b2aQJv3Z4Fp6yNu3cdSllBxTCLRxnplIgP/c0N/04lM=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/gogo/protobuf v1.1.1/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/gogo/protobuf v1.2.0/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/gogo/protobuf v1.2.1/go.mod h1:hp+jE20tsWTFYpLwKvXlhS1hjn+gTNwPg2I6zVXpSg4=
bump to uplink v1.2.0 Also fixup config and related tests for storj.io/common bee93690ab909580993f402b594ad5a14760c39f Change-Id: I6897d925cd28b139c1fc2b43e63b08c0cc3fb688
2020-08-03 17:36:39 +01:00
github.com/gogo/protobuf v1.3.1 h1:DqDEcV5aeaTmdFBePNpYsp3FlcVH/2ISVVM9Qf8PSls=
github.com/gogo/protobuf v1.3.1/go.mod h1:SlYgWuQ5SjCEi6WLHjHCa1yvBfUnHcTbrrZtXPKa29o=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/golang-migrate/migrate/v4 v4.7.0 h1:gONcHxHApDTKXDyLH/H97gEHmpu1zcnnbAaq2zgrPrs=
github.com/golang-migrate/migrate/v4 v4.7.0/go.mod h1:Qvut3N4xKWjoH3sokBccML6WyHSnggXm/DvMMnTsQIc=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b h1:VKtxabqXZkF25pY9ekfRL6a582T4P37/31XEstQ5p58=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/golang/groupcache v0.0.0-20190129154638-5b532d6fd5ef/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/golang/groupcache v0.0.0-20190702054246-869f871628b6/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/golang/groupcache v0.0.0-20191027212112-611e8accdfc9/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7 h1:5ZkaAPbicIKTF2I64qf5Fh8Aa83Q/dnOafMYV0OMwjA=
github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/golang/lint v0.0.0-20180702182130-06c8688daad7/go.mod h1:tluoj9z5200jBnyusfRPU2LqT6J+DAorxEvtC7LHB+E=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/golang/mock v1.1.1/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/golang/mock v1.2.0/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/golang/mock v1.3.1 h1:qGJ6qTW+x6xX/my+8YUVl4WNpX9B7+/l2tRsHGZ7f2s=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/golang/mock v1.3.1/go.mod h1:sBzyDLLjw3U8JLTeZvSv8jJB+tU5PVekmnlKIyFUx0Y=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/golang/mock v1.4.0/go.mod h1:UOMv5ysSaYNkG+OFQykRIcU/QvvxJf3p21QfJ2Bt3cw=
github.com/golang/mock v1.4.4 h1:l75CXGRSwbaYNpl/Z2X1XIIAMSCquvXgpVZDhwEIJsc=
github.com/golang/mock v1.4.4/go.mod h1:l3mdAwkq5BuhzHwde/uurv3sEJeZMXNpwsxVWU71h+4=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/golang/protobuf v1.3.1/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
pkg/auth: use grpc.WithPerRPCCredentials (#2670)
2019-07-31 12:57:13 +01:00
github.com/golang/protobuf v1.3.2 h1:6nsPYzhq5kReh6QImI3k5qWzO4PEbvbIW2cwSfR/6xs=
github.com/golang/protobuf v1.3.2/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/golang/protobuf v1.4.0-rc.1/go.mod h1:ceaxUfeHdC40wWswd/P6IGgMaK3YpKi5j83Wpe3EHw8=
github.com/golang/protobuf v1.4.0-rc.1.0.20200221234624-67d41d38c208/go.mod h1:xKAWHe0F5eneWXFV3EuXVDTCmh+JuBKY0li0aMyXATA=
github.com/golang/protobuf v1.4.0-rc.2/go.mod h1:LlEzMj4AhA7rCAGe4KMBDvJI+AwstrUpVNzEA03Pprs=
github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0/go.mod h1:WU3c8KckQ9AFe+yFwt9sWVRKCVIyN9cPHBJSNnbL67w=
github.com/golang/protobuf v1.4.0/go.mod h1:jodUvKwWbYaEsadDk5Fwe5c77LiNKVO9IDvqG2KuDX0=
github.com/golang/protobuf v1.4.2 h1:+Z5KGCizgyZCbGh1KZqA0fcLLkwbsjIzS4aV2v7wJX0=
github.com/golang/protobuf v1.4.2/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/golang/snappy v0.0.0-20170215233205-553a64147049/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/golang/snappy v0.0.0-20180518054509-2e65f85255db/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/golang/snappy v0.0.1/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/google/go-cmp v0.3.0/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/google/go-cmp v0.3.1/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/google/go-cmp v0.4.0/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/google/go-cmp v0.5.2 h1:X2ev0eStA3AbceY54o37/0PQ/UWqKEiiO2dKL5OPaFM=
github.com/google/go-cmp v0.5.2/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/google/go-github v17.0.0+incompatible/go.mod h1:zLgOLi98H3fifZn+44m+umXrS52loVEgC2AApnigrVQ=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/google/go-querystring v1.0.0/go.mod h1:odCYkC5MyYFN7vkCjXpyrEuKhc/BUO6wN/zVPAxq5ck=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/google/martian v2.1.0+incompatible h1:/CP5g8u/VJHijgedC/Legn3BAbAaWPgecwXBIDzw5no=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/google/martian v2.1.0+incompatible/go.mod h1:9I4somxYTbIHy5NJKHRl3wXiIaQGbYVAs8BPL6v8lEs=
github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/google/pprof v0.0.0-20190515194954-54271f7e092f/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
github.com/google/pprof v0.0.0-20191218002539-d4f498aebedc/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
github.com/google/pprof v0.0.0-20200229191704-1ebb73c60ed3 h1:SRgJV+IoxM5MKyFdlSUeNy6/ycRUF2yBAKdAQswoHUk=
github.com/google/pprof v0.0.0-20200229191704-1ebb73c60ed3/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/googleapis/gax-go v2.0.0+incompatible h1:j0GKcs05QVmm7yesiZq2+9cxHkNK9YM6zKx4D2qucQU=
github.com/googleapis/gax-go v2.0.0+incompatible/go.mod h1:SFVmujtThgffbyetf+mdk2eWhX2bMyUtNHzFKcPA9HY=
github.com/googleapis/gax-go/v2 v2.0.3/go.mod h1:LLvjysVCY1JZeum8Z6l8qUty8fiNwE08qbEPm1M08qg=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/googleapis/gax-go/v2 v2.0.5 h1:sjZBwGj9Jlw33ImPtvFviGYvseOtDM7hkSKB7+Tv3SM=
github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/gopherjs/gopherjs v0.0.0-20181017120253-0766667cb4d1 h1:EGx4pi6eqNxGaHF6qqu48+N2wcFQ5qg5FXgOdqsJ5d8=
github.com/gopherjs/gopherjs v0.0.0-20181017120253-0766667cb4d1/go.mod h1:wJfORRmW1u3UXTncJ5qlYoELFm8eSnnEO6hX4iZ3EWY=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/gorilla/context v1.1.1/go.mod h1:kBGZzfjB9CEq2AlWe17Uuf7NDRt0dE0s8S51q0aT7Yg=
github.com/gorilla/mux v1.6.2/go.mod h1:1lud6UwP+6orDFRuTfBEV8e9/aOM/c4fVVCaMa2zaAs=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/gorilla/mux v1.7.1/go.mod h1:1lud6UwP+6orDFRuTfBEV8e9/aOM/c4fVVCaMa2zaAs=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/gorilla/mux v1.8.0 h1:i40aqfkR1h2SlN9hojwV5ZA91wcXFOvkdNIeFDP5koI=
github.com/gorilla/mux v1.8.0/go.mod h1:DVbg23sWSpFRCP0SfiEN6jmj59UnW/n46BH5rLB71So=
github.com/gorilla/schema v1.2.0 h1:YufUaxZYCKGFuAq3c96BOhjgd5nmXiOY9NGzF247Tsc=
github.com/gorilla/schema v1.2.0/go.mod h1:kgLaKoK1FELgZqMAVxx/5cbj0kT+57qxUrAlIO2eleU=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/gorilla/websocket v1.4.0/go.mod h1:E7qHFY5m1UJ88s3WnNqhKjPHQ0heANvMoAMk2YaljkQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/gorilla/websocket v1.4.2/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE=
go.mod: unlock graphql dependency and bump to latest Change-Id: I40026f6c8de155e024f5fbb51105546065393034
2020-02-25 11:17:49 +00:00
github.com/graphql-go/graphql v0.7.9 h1:5Va/Rt4l5g3YjwDnid3vFfn43faaQBq7rMcIZ0VnV34=
github.com/graphql-go/graphql v0.7.9/go.mod h1:k6yrAYQaSP59DC5UVxbgxESlmVyojThKdORUqGDGmrI=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/grpc-ecosystem/go-grpc-middleware v1.0.0/go.mod h1:FiyG127CGDf3tlThmgyCl78X/SZQqEOJBCDaAfeWzPs=
github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0/go.mod h1:8NvIoxWQoOIhqOTXgfV/d3M/q6VIi02HzZEHgUlZvzk=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/grpc-ecosystem/grpc-gateway v1.5.0/go.mod h1:RSKVYQBd5MCa4OVpNdGskqpgL2+G+NZTnrVHpWWfpdw=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/grpc-ecosystem/grpc-gateway v1.9.0/go.mod h1:vNeuVxBJEsws4ogUvrchl83t/GYV9WGTSLVdBhOQFDY=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/hailocab/go-hostpool v0.0.0-20160125115350-e80d13ce29ed/go.mod h1:tMWxXQ9wFIaZeTI9F+hmhFiGpFmhOHzyShyFUhRm0H4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/hashicorp/consul/api v1.1.0/go.mod h1:VmuI/Lkw1nC05EYQWNKwWGbkg+FbDBtguAZLlVdkD9Q=
github.com/hashicorp/consul/sdk v0.1.1/go.mod h1:VKf9jXwCTEY1QZP2MOLRhb5i/I/ssyNV1vwHyQBF0x8=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/hashicorp/errwrap v1.0.0 h1:hLrqtEDnRye3+sgx6z4qVLNuviH3MR5aQ0ykNJa/UYA=
github.com/hashicorp/errwrap v1.0.0/go.mod h1:YH+1FKiLXxHSkmPseP+kNlulaMuP3n2brvKWEqk/Jc4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/hashicorp/go-cleanhttp v0.5.1/go.mod h1:JpRdi6/HCYpAwUzNwuwqhbovhLtngrth3wmdIIUrZ80=
github.com/hashicorp/go-immutable-radix v1.0.0/go.mod h1:0y9vanUI8NX6FsYoO3zeMjhV/C5i9g4Q3DwcSNZ4P60=
github.com/hashicorp/go-msgpack v0.5.3/go.mod h1:ahLV/dePpqEmjfWmKiqvPkv/twdG7iPBM1vqhUKIvfM=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/hashicorp/go-multierror v1.0.0 h1:iVjPR7a6H0tWELX5NxNe7bYopibicUzc7uPribsnS6o=
github.com/hashicorp/go-multierror v1.0.0/go.mod h1:dHtQlpGsu+cZNNAkkCN/P3hoUDHhCYQXV3UM06sGGrk=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/hashicorp/go-rootcerts v1.0.0/go.mod h1:K6zTfqpRlCUIjkwsN4Z+hiSfzSTQa6eBIzfwKfwNnHU=
github.com/hashicorp/go-sockaddr v1.0.0/go.mod h1:7Xibr9yA9JjQq1JpNB2Vw7kxv8xerXegt+ozgdvDeDU=
github.com/hashicorp/go-syslog v1.0.0/go.mod h1:qPfqrKkXGihmCqbJM2mZgkZGvKG1dFdvsLplgctolz4=
github.com/hashicorp/go-uuid v1.0.0/go.mod h1:6SBZvOh/SIDV7/2o3Jml5SYk/TvGqwFJ/bN7x4byOro=
github.com/hashicorp/go-uuid v1.0.1/go.mod h1:6SBZvOh/SIDV7/2o3Jml5SYk/TvGqwFJ/bN7x4byOro=
github.com/hashicorp/go.net v0.0.1/go.mod h1:hjKkEWcCURg++eb33jQU7oqQcI9XDCnUzHA0oac0k90=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/hashicorp/hcl v1.0.0 h1:0Anlzjpi4vEasTeNFn2mLJgTSwt0+6sfsiTG8qcWGx4=
github.com/hashicorp/hcl v1.0.0/go.mod h1:E5yfLk+7swimpb2L/Alb/PJmXilQ/rhwaUYs4T20WEQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/hashicorp/logutils v1.0.0/go.mod h1:QIAnNjmIWmVIIkWDTG1z5v++HQmx9WQRO+LraFDTW64=
github.com/hashicorp/mdns v1.0.0/go.mod h1:tL+uN++7HEJ6SQLQ2/p+z2pH24WQKWjBPkE0mNTz8vQ=
github.com/hashicorp/memberlist v0.1.3/go.mod h1:ajVTdAv/9Im8oMAAj5G31PhhMCZJV2pPBoIllUwCN7I=
github.com/hashicorp/serf v0.8.2/go.mod h1:6hOLApaqBFA1NXqRQAsxw9QxuDEvNxSQRwA/JwenrHc=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/hpcloud/tail v1.0.0 h1:nfCOvKYfkgYP8hkirhJocXT2+zOD8yUNjXaWfTlyFKI=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/ianlancetaylor/demangle v0.0.0-20181102032728-5e5cf60278f6/go.mod h1:aSSvb/t6k1mPoxDqO4vJh6VOCGPwU4O0C2/Eqndh1Sc=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/inconshreveable/mousetrap v1.0.0 h1:Z8tu5sraLXCXIcARxBp/8cbvlwVa7Z1NHg9XEKhtSvM=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/inconshreveable/mousetrap v1.0.0/go.mod h1:PxqpIevigyE2G7u3NXJIT2ANytuPF1OarO4DADm73n8=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/jackc/chunkreader v1.0.0 h1:4s39bBR8ByfqH+DKm8rQA3E1LHZWB9XWcrz8fqaZbe0=
github.com/jackc/chunkreader v1.0.0/go.mod h1:RT6O25fNZIuasFJRyZ4R/Y2BbhasbmZXF9QQ7T3kePo=
github.com/jackc/chunkreader/v2 v2.0.0/go.mod h1:odVSm741yZoC3dpHEUXIqA9tQRhFrgOHwnPIn9lDKlk=
github.com/jackc/chunkreader/v2 v2.0.1 h1:i+RDz65UE+mmpjTfyz0MoVTnzeYxroil2G82ki7MGG8=
github.com/jackc/chunkreader/v2 v2.0.1/go.mod h1:odVSm741yZoC3dpHEUXIqA9tQRhFrgOHwnPIn9lDKlk=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/jackc/fake v0.0.0-20150926172116-812a484cc733/go.mod h1:WrMFNQdiFJ80sQsxDoMokWK1W5TQtxBFNpzWTD84ibQ=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/jackc/pgconn v0.0.0-20190420214824-7e0022ef6ba3/go.mod h1:jkELnwuX+w9qN5YIfX0fl88Ehu4XC3keFuOJJk9pcnA=
github.com/jackc/pgconn v0.0.0-20190824142844-760dd75542eb/go.mod h1:lLjNuW/+OfW9/pnVKPazfWOgNfH2aPem8YQ7ilXGvJE=
github.com/jackc/pgconn v0.0.0-20190831204454-2fabfa3c18b7/go.mod h1:ZJKsE/KZfsUgOEh9hBm+xYTstcNHg7UPMVJqRfQxq4s=
github.com/jackc/pgconn v1.4.0/go.mod h1:Y2O3ZDF0q4mMacyWV3AstPJpeHXWGEetiFttmq5lahk=
github.com/jackc/pgconn v1.5.0/go.mod h1:QeD3lBfpTFe8WUnPZWN5KY/mB8FGMIYRdd8P8Jr0fAI=
github.com/jackc/pgconn v1.5.1-0.20200601181101-fa742c524853/go.mod h1:QeD3lBfpTFe8WUnPZWN5KY/mB8FGMIYRdd8P8Jr0fAI=
go.mod: update pgx to v4.9.0 Fix query to use TextArray instead of VarcharArray. Fix queries to use the correct type. Change-Id: Ibb7e55adba277d05778118d81ca697470e72c374
2020-09-29 10:53:15 +01:00
github.com/jackc/pgconn v1.7.0 h1:pwjzcYyfmz/HQOQlENvG1OcDqauTGaqlVahq934F0/U=
github.com/jackc/pgconn v1.7.0/go.mod h1:sF/lPpNEMEOp+IYhyQGdAvrG20gWf6A1tKlr0v7JMeA=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/jackc/pgio v1.0.0 h1:g12B9UwVnzGhueNavwioyEEpAmqMe1E/BN9ES+8ovkE=
github.com/jackc/pgio v1.0.0/go.mod h1:oP+2QK2wFfUWgr+gxjoBH9KGBb31Eio69xUb0w5bYf8=
github.com/jackc/pgmock v0.0.0-20190831213851-13a1b77aafa2 h1:JVX6jT/XfzNqIjye4717ITLaNwV9mWbJx0dLCpcRzdA=
github.com/jackc/pgmock v0.0.0-20190831213851-13a1b77aafa2/go.mod h1:fGZlG77KXmcq05nJLRkk0+p82V8B8Dw8KN2/V9c/OAE=
github.com/jackc/pgpassfile v1.0.0 h1:/6Hmqy13Ss2zCq62VdNG8tM1wchn8zjSGOBJ6icpsIM=
github.com/jackc/pgpassfile v1.0.0/go.mod h1:CEx0iS5ambNFdcRtxPj5JhEz+xB6uRky5eyVu/W2HEg=
github.com/jackc/pgproto3 v1.1.0 h1:FYYE4yRw+AgI8wXIinMlNjBbp/UitDJwfj5LqqewP1A=
github.com/jackc/pgproto3 v1.1.0/go.mod h1:eR5FA3leWg7p9aeAqi37XOTgTIbkABlvcPB3E5rlc78=
github.com/jackc/pgproto3/v2 v2.0.0-alpha1.0.20190420180111-c116219b62db/go.mod h1:bhq50y+xrl9n5mRYyCBFKkpRVTLYJVWeCc+mEAI3yXA=
github.com/jackc/pgproto3/v2 v2.0.0-alpha1.0.20190609003834-432c2951c711/go.mod h1:uH0AWtUmuShn0bcesswc4aBTWGvw0cAxIJp+6OB//Wg=
github.com/jackc/pgproto3/v2 v2.0.0-rc3/go.mod h1:ryONWYqW6dqSg1Lw6vXNMXoBJhpzvWKnT95C46ckYeM=
github.com/jackc/pgproto3/v2 v2.0.0-rc3.0.20190831210041-4c03ce451f29/go.mod h1:ryONWYqW6dqSg1Lw6vXNMXoBJhpzvWKnT95C46ckYeM=
github.com/jackc/pgproto3/v2 v2.0.1/go.mod h1:WfJCnwN3HIg9Ish/j3sgWXnAfK8A9Y0bwXYU5xKaEdA=
go.mod: update pgx to v4.9.0 Fix query to use TextArray instead of VarcharArray. Fix queries to use the correct type. Change-Id: Ibb7e55adba277d05778118d81ca697470e72c374
2020-09-29 10:53:15 +01:00
github.com/jackc/pgproto3/v2 v2.0.5 h1:NUbEWPmCQZbMmYlTjVoNPhc0CfnYyz2bfUAh6A5ZVJM=
github.com/jackc/pgproto3/v2 v2.0.5/go.mod h1:WfJCnwN3HIg9Ish/j3sgWXnAfK8A9Y0bwXYU5xKaEdA=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/jackc/pgservicefile v0.0.0-20200307190119-3430c5407db8/go.mod h1:vsD4gTJCa9TptPL8sPkXrLZ+hDuNrZCnj29CQpr4X1E=
go.mod: update pgx to v4.9.0 Fix query to use TextArray instead of VarcharArray. Fix queries to use the correct type. Change-Id: Ibb7e55adba277d05778118d81ca697470e72c374
2020-09-29 10:53:15 +01:00
github.com/jackc/pgservicefile v0.0.0-20200714003250-2b9c44734f2b h1:C8S2+VttkHFdOOCXJe+YGfa4vHYwlt4Zx+IVXQ97jYg=
github.com/jackc/pgservicefile v0.0.0-20200714003250-2b9c44734f2b/go.mod h1:vsD4gTJCa9TptPL8sPkXrLZ+hDuNrZCnj29CQpr4X1E=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/jackc/pgtype v0.0.0-20190421001408-4ed0de4755e0/go.mod h1:hdSHsc1V01CGwFsrv11mJRHWJ6aifDLfdV3aVjFF0zg=
github.com/jackc/pgtype v0.0.0-20190824184912-ab885b375b90/go.mod h1:KcahbBH1nCMSo2DXpzsoWOAfFkdEtEJpPbVLq8eE+mc=
github.com/jackc/pgtype v0.0.0-20190828014616-a8802b16cc59/go.mod h1:MWlu30kVJrUS8lot6TQqcg7mtthZ9T0EoIBFiJcmcyw=
github.com/jackc/pgtype v1.2.0/go.mod h1:5m2OfMh1wTK7x+Fk952IDmI4nw3nPrvtQdM0ZT4WpC0=
github.com/jackc/pgtype v1.3.1-0.20200510190516-8cd94a14c75a/go.mod h1:vaogEUkALtxZMCH411K+tKzNpwzCKU+AnPzBKZ+I+Po=
github.com/jackc/pgtype v1.3.1-0.20200606141011-f6355165a91c/go.mod h1:cvk9Bgu/VzJ9/lxTO5R5sf80p0DiucVtN7ZxvaC4GmQ=
go.mod: update pgx to v4.9.0 Fix query to use TextArray instead of VarcharArray. Fix queries to use the correct type. Change-Id: Ibb7e55adba277d05778118d81ca697470e72c374
2020-09-29 10:53:15 +01:00
github.com/jackc/pgtype v1.5.0 h1:jzBqRk2HFG2CV4AIwgCI2PwTgm6UUoCAK2ofHHRirtc=
github.com/jackc/pgtype v1.5.0/go.mod h1:JCULISAZBFGrHaOXIIFiyfzW5VY0GRitRr8NeJsrdig=
satellitedb/repairqueue: runs a different implementation of the query within Select() for postgres vs cockroach Change-Id: Ie34dbdb9d870d7d9f8f269702b6b3bad0c55b98e
2019-12-03 05:21:46 +00:00
github.com/jackc/pgx v3.2.0+incompatible h1:0Vihzu20St42/UDsvZGdNE6jak7oi/UOeMzwMPHkgFY=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/jackc/pgx v3.2.0+incompatible/go.mod h1:0ZGrqGqkRlliWnWB4zKnWtjbSWbGkVEFm4TeybAXq+I=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/jackc/pgx/v4 v4.0.0-20190420224344-cc3461e65d96/go.mod h1:mdxmSJJuR08CZQyj1PVQBHy9XOp5p8/SHH6a0psbY9Y=
github.com/jackc/pgx/v4 v4.0.0-20190421002000-1b8f0016e912/go.mod h1:no/Y67Jkk/9WuGR0JG/JseM9irFbnEPbuWV2EELPNuM=
github.com/jackc/pgx/v4 v4.0.0-pre1.0.20190824185557-6972a5742186/go.mod h1:X+GQnOEnf1dqHGpw7JmHqHc1NxDoalibchSk9/RWuDc=
github.com/jackc/pgx/v4 v4.5.0/go.mod h1:EpAKPLdnTorwmPUUsqrPxy5fphV18j9q3wrfRXgo+kA=
github.com/jackc/pgx/v4 v4.6.1-0.20200510190926-94ba730bb1e9/go.mod h1:t3/cdRQl6fOLDxqtlyhe9UWgfIi9R8+8v8GKV5TRA/o=
github.com/jackc/pgx/v4 v4.6.1-0.20200606145419-4e5062306904/go.mod h1:ZDaNWkt9sW1JMiNn0kdYBaLelIhw7Pg4qd+Vk6tw7Hg=
go.mod: update pgx to v4.9.0 Fix query to use TextArray instead of VarcharArray. Fix queries to use the correct type. Change-Id: Ibb7e55adba277d05778118d81ca697470e72c374
2020-09-29 10:53:15 +01:00
github.com/jackc/pgx/v4 v4.9.0 h1:6STjDqppM2ROy5p1wNDcsC7zJTjSHeuCsguZmXyzx7c=
github.com/jackc/pgx/v4 v4.9.0/go.mod h1:MNGWmViCgqbZck9ujOOBN63gK9XVGILXWCvKLGKmnms=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/jackc/puddle v0.0.0-20190413234325-e4ced69a3a2b/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
github.com/jackc/puddle v0.0.0-20190608224051-11cab39313c9/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
github.com/jackc/puddle v1.1.0/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
github.com/jackc/puddle v1.1.1/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
go.mod: update pgx to v4.9.0 Fix query to use TextArray instead of VarcharArray. Fix queries to use the correct type. Change-Id: Ibb7e55adba277d05778118d81ca697470e72c374
2020-09-29 10:53:15 +01:00
github.com/jackc/puddle v1.1.2/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/jellevandenhooff/dkim v0.0.0-20150330215556-f50fe3d243e1/go.mod h1:E0B/fFc00Y+Rasa88328GlI/XbtyysCtTHZS8h7IrBU=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/jessevdk/go-flags v0.0.0-20141203071132-1679536dcc89/go.mod h1:4FA24M0QyGHXBuZZK/XkWh8h0e1EYbRYJSGM75WSRxI=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/jmespath/go-jmespath v0.0.0-20180206201540-c2b33e8439af/go.mod h1:Nht3zPeWKUH0NzdCt2Blrr5ys8VGpn0CEB0cQHVjt7k=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/jonboulle/clockwork v0.1.0/go.mod h1:Ii8DK3G1RaLaWxj9trq07+26W01tbo22gdxWY5EU2bo=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/jrick/logrotate v1.0.0/go.mod h1:LNinyqDIJnpAur+b8yyulnQw/wDuN1+BYKlTRt3OuAQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/json-iterator/go v1.1.6/go.mod h1:+SdeFBvtyEkXs7REEP0seUULqWtbJapLOCVDaaPEHmU=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024/go.mod h1:6v2b51hI/fHJwM22ozAgKL4VKDeJcHhJFhtBdhmNjmU=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/jstemmer/go-junit-report v0.9.1 h1:6QPYqodiu3GuPL+7mfx+NwDdp2eTkp9IfEUpgAwUN0o=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/jstemmer/go-junit-report v0.9.1/go.mod h1:Brl9GWCQeLvo8nXZwPNNblvFj/XSXhF0NWZEnDohbsk=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/jtolds/gls v4.20.0+incompatible h1:xdiiI2gbIgH/gLH7ADydsJ1uDOEzR8yvV7C0MuV77Wo=
github.com/jtolds/gls v4.20.0+incompatible/go.mod h1:QJZ7F/aHp+rZTRtaJ1ow/lLfFfVYBRgL+9YlvaHOwJU=
all: use monkit v3 this commit updates our monkit dependency to the v3 version where it outputs in an influx style. this makes discovery much easier as many tools are built to look at it this way. graphite and rothko will suffer some due to no longer being a tree based on dots. hopefully time will exist to update rothko to index based on the new metric format. it adds an influx output for the statreceiver so that we can write to influxdb v1 or v2 directly. Change-Id: Iae9f9494a6d29cfbd1f932a5e71a891b490415ff
2019-11-08 20:40:39 +00:00
github.com/jtolds/monkit-hw/v2 v2.0.0-20191108235325-141a0da276b3 h1:dITCBge70U9RDyZUL/Thn/yAT/ct4Rz40mNUX51dFCk=
github.com/jtolds/monkit-hw/v2 v2.0.0-20191108235325-141a0da276b3/go.mod h1:eo5po8nCwRcvZIIR8eGi7PKthzXuunpXzUmXzxCBfBc=
upgrade dependencies for trace db debug endpoint Change-Id: I4de658b361bb39ce28dc31b982895bb4f45b580a
2020-03-03 22:15:14 +00:00
github.com/jtolds/tracetagger/v2 v2.0.0-rc5 h1:SriMFVtftPsQmG+0xaABotz9HnoKoo1QM/oggqfpGh8=
github.com/jtolds/tracetagger/v2 v2.0.0-rc5/go.mod h1:61Fh+XhbBONy+RsqkA+xTtmaFbEVL040m9FAF/hTrjQ=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/julienschmidt/httprouter v1.2.0/go.mod h1:SYymIcj16QtmaHHD7aYtjjsJG7VTCxuUUipMqKk8s4w=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0/go.mod h1:1NbS8ALrpOvjt0rHPNLyCIeMtbizbir8U//inJ+zuB8=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/kisielk/errcheck v1.1.0/go.mod h1:EZBBE59ingxPouuu3KfxchcWSUPOHkagtvWXihfKN4Q=
bump to uplink v1.2.0 Also fixup config and related tests for storj.io/common bee93690ab909580993f402b594ad5a14760c39f Change-Id: I6897d925cd28b139c1fc2b43e63b08c0cc3fb688
2020-08-03 17:36:39 +01:00
github.com/kisielk/errcheck v1.2.0/go.mod h1:/BMXB+zMLi60iA8Vv6Ksmxu/1UDYcXs4uQLJ+jE2L00=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
github.com/kkdai/bstream v0.0.0-20161212061736-f391b8402d23/go.mod h1:J+Gs4SYgM6CZQHDETBtE9HaSEkGmuNXF86RwHhHUvq4=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/konsorten/go-windows-terminal-sequences v1.0.2 h1:DB17ag19krx9CFsz4o3enTrPXyIXCl+2iCXH/aMAp9s=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/konsorten/go-windows-terminal-sequences v1.0.2/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/kr/logfmt v0.0.0-20140226030751-b84e30acd515/go.mod h1:+0opPa2QZZtGFBFZlji/RkVcI2GknAs/DXo4wKdlNEc=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/kr/pretty v0.1.0 h1:L/CwN0zerZDmRFUapSPitk6f+Q3+0za1rQkzVuMiMFI=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo=
github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/kr/pty v1.1.3/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/kr/pty v1.1.8/go.mod h1:O1sed60cT9XZ5uDucP5qwvh+TE3NnUj51EiZO/lmSfw=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/kr/text v0.1.0 h1:45sCR5RtlFHMR4UwH9sdQ5TC8v0qDQCHnXt+kaKSTVE=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/kshvakov/clickhouse v1.3.5/go.mod h1:DMzX7FxRymoNkVgizH0DWAL8Cur7wHLgx3MUnGwJqpE=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/lib/pq v1.0.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/lib/pq v1.1.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo=
github.com/lib/pq v1.2.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo=
mod: bump common and some other packages Change-Id: Icf73220f5182f5a2fd1431471825948c300c0bea
2020-01-07 16:09:54 +00:00
github.com/lib/pq v1.3.0 h1:/qkRGz8zljWiDcFvgpwUpwIAPu3r07TDvs3Rws+o/pU=
github.com/lib/pq v1.3.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/lucas-clemente/quic-go v0.7.1-0.20201102053916-272229abf044 h1:M6zB4Rs4SJDk9IBIvC3ozl23+b0d1Q7NOlHnbxuc3AY=
github.com/lucas-clemente/quic-go v0.7.1-0.20201102053916-272229abf044/go.mod h1:ZUygOqIoai0ASXXLJ92LTnKdbqh9MHCLTX6Nr1jUrK0=
github.com/lunixbochs/vtclean v1.0.0/go.mod h1:pHhQNgMf3btfWnGBVipUOjRYhoOsdGqdm/+2c2E2WMI=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/magiconair/properties v1.8.0/go.mod h1:PppfXfuXeibc/6YijjN8zIbojt8czPbwD3XqdrwzmxQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/magiconair/properties v1.8.1 h1:ZC2Vc7/ZFkGmsVC9KvOjumD+G5lXy2RtTKyzRKO2BQ4=
github.com/magiconair/properties v1.8.1/go.mod h1:PppfXfuXeibc/6YijjN8zIbojt8czPbwD3XqdrwzmxQ=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/mailru/easyjson v0.0.0-20190312143242-1de009706dbe/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc=
github.com/marten-seemann/qpack v0.2.1/go.mod h1:F7Gl5L1jIgN1D11ucXefiuJS9UMVP2opoCp2jDKb7wc=
github.com/marten-seemann/qtls v0.10.0 h1:ECsuYUKalRL240rRD4Ri33ISb7kAQ3qGDlrrl55b2pc=
github.com/marten-seemann/qtls v0.10.0/go.mod h1:UvMd1oaYDACI99/oZUYLzMCkBXQVT0aGm99sJhbT8hs=
github.com/marten-seemann/qtls-go1-15 v0.1.1 h1:LIH6K34bPVttyXnUWixk0bzH6/N07VxbSabxn5A5gZQ=
github.com/marten-seemann/qtls-go1-15 v0.1.1/go.mod h1:GyFwywLKkRt+6mfU99csTEY1joMZz5vmB1WNZH3P81I=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/mattn/go-colorable v0.0.9/go.mod h1:9vuHe8Xs5qXnSaW/c/ABM9alt+Vo+STaOChaDxuIBZU=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/mattn/go-colorable v0.1.1/go.mod h1:FuOcm+DKB9mbwrcAfNl7/TZVBZ6rcnceauSikq3lYCQ=
cmd/uplink: fix progressbar data race (#2987)
2019-09-10 09:51:49 +01:00
github.com/mattn/go-colorable v0.1.2/go.mod h1:U0ppj6V5qS13XJ6of8GYAs25YV2eR4EVcfRqFIhoBtE=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/mattn/go-colorable v0.1.4/go.mod h1:U0ppj6V5qS13XJ6of8GYAs25YV2eR4EVcfRqFIhoBtE=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/mattn/go-colorable v0.1.6 h1:6Su7aK7lXmJ/U79bYtBjLNaha4Fs1Rg9plHpcH+vvnE=
github.com/mattn/go-colorable v0.1.6/go.mod h1:u6P/XSegPjTcexA+o6vUJrdnUu04hMope9wVRipJSqc=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/mattn/go-isatty v0.0.3/go.mod h1:M+lRXTBqGeGNdLjl/ufCoiOlB5xdOkqRJdNxMWT7Zi4=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/mattn/go-isatty v0.0.5/go.mod h1:Iq45c/XA43vh69/j3iqttzPXn0bhXyGjM0Hdxcsrc5s=
github.com/mattn/go-isatty v0.0.7/go.mod h1:Iq45c/XA43vh69/j3iqttzPXn0bhXyGjM0Hdxcsrc5s=
cmd/uplink: fix progressbar data race (#2987)
2019-09-10 09:51:49 +01:00
github.com/mattn/go-isatty v0.0.8/go.mod h1:Iq45c/XA43vh69/j3iqttzPXn0bhXyGjM0Hdxcsrc5s=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/mattn/go-isatty v0.0.9/go.mod h1:YNRxwqDuOph6SZLI9vUUz6OYw3QyUt7WiY2yME+cCiQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/mattn/go-isatty v0.0.11/go.mod h1:PhnuNfih5lzO57/f3n+odYbM4JtupLOxQOAqxQCu2WE=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/mattn/go-isatty v0.0.12 h1:wuysRhFDzyxgEmMf5xjvJ2M9dZoWAXNNr5LSBS7uHXY=
github.com/mattn/go-isatty v0.0.12/go.mod h1:cbi8OIDigv2wuxKPP5vlRcQ1OAZbq2CE4Kysco4FUpU=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/mattn/go-runewidth v0.0.7 h1:Ei8KR0497xHyKJPAv59M1dkC+rOZCMBJ+t3fZ+twI54=
github.com/mattn/go-runewidth v0.0.7/go.mod h1:H031xJmbD/WCDINGzjvQ9THkh0rPKHF+m2gUSrubnMI=
cmd/statreceiver: lua-scriptable stat receiver (#636) * cmd/statreceiver: lua-scriptable stat receiver Change-Id: I3ce0fe3f1ef4b1f4f27eed90bac0e91cfecf22d7 * some updates Change-Id: I7c3485adcda1278fce01ae077b4761b3ddb9fb7a * more comments Change-Id: I0bb22993cd934c3d40fc1da80d07e49e686b80dd * linter fixes Change-Id: Ied014304ecb9aadcf00a6b66ad28f856a428d150 * catch errors Change-Id: I6e1920f1fd941e66199b30bc427285c19769fc70 * review feedback Change-Id: I9d4051851eab18970c5f5ddcf4ff265508e541d3 * errorgroup improvements Change-Id: I4699dda3022f0485fbb50c9dafe692d3921734ff * too tricky the previous thing was better for memory with lots of errors at a time but https://play.golang.org/p/RweTMRjoSCt is too much of a foot gun Change-Id: I23f0b3d77dd4288fcc20b3756a7110359576bf44
2018-12-11 18:24:31 +00:00
github.com/mattn/go-sqlite3 v1.10.0/go.mod h1:FPy6KqzDD04eiIsT53CuJW3U88zkxoIYsOqkbpncsNc=
mod: update sqlite to v3.31.1 Change-Id: Ia2885f5385ffa227b8576c1d9e1c8bbba0c5d13d
2020-05-04 15:34:27 +01:00
github.com/mattn/go-sqlite3 v2.0.3+incompatible h1:gXHsfypPkaMZrKbD5209QV9jbUTJKjyR5WD3HYQSd+U=
github.com/mattn/go-sqlite3 v2.0.3+incompatible/go.mod h1:FPy6KqzDD04eiIsT53CuJW3U88zkxoIYsOqkbpncsNc=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/matttproud/golang_protobuf_extensions v1.0.1/go.mod h1:D8He9yQNgCq6Z5Ld7szi9bcBfOoFv/3dc6xSMkL2PC0=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/microcosm-cc/bluemonday v1.0.1/go.mod h1:hsXNsILzKxV+sX77C5b8FSuKF00vh2OMYv+xgHpAMF4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/miekg/dns v1.0.14/go.mod h1:W1PPwlIAgtquWBMBEV9nkV9Cazfe8ScdGz/Lj7v3Nrg=
Use sha256-simd for hashing (#1656)
2019-04-04 09:12:08 +01:00
github.com/minio/sha256-simd v0.0.0-20190328051042-05b4dd3047e5/go.mod h1:2FMWW+8GMoPweT6+pI63m9YE3Lmw4J71hV56Chs1E/U=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/mitchellh/cli v1.0.0/go.mod h1:hNIlj7HEI86fIcpObd7a0FcrxTWetlwJDGcceTlRvqc=
github.com/mitchellh/go-homedir v1.0.0/go.mod h1:SfyaCUpYCn1Vlf4IUYiD9fPX4A5wJrkLzIz1N1q0pr0=
storagenode/cmd: create start graceful exit CLI (#3202)
2019-10-11 14:58:12 +01:00
github.com/mitchellh/go-homedir v1.1.0/go.mod h1:SfyaCUpYCn1Vlf4IUYiD9fPX4A5wJrkLzIz1N1q0pr0=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/mitchellh/go-testing-interface v1.0.0/go.mod h1:kRemZodwjscx+RGhAo8eIhFbs2+BFgRtFPeD/KE+zxI=
github.com/mitchellh/gox v0.4.0/go.mod h1:Sd9lOJ0+aimLBi73mGofS1ycjY8lL3uZM3JPS42BGNg=
github.com/mitchellh/iochan v1.0.0/go.mod h1:JwYml1nuB7xOzsp52dPpHFffvOCDupsG0QubkSMEySY=
github.com/mitchellh/mapstructure v0.0.0-20160808181253-ca63d7c062ee/go.mod h1:FVVH3fgwuzCH5S8UJGiWEs2h04kUh9fWfEaFds41c1Y=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/mitchellh/mapstructure v1.1.2 h1:fmNYVwqnSfB9mZU6OS2O6GsXM+wcskZDuKQzvN1EDeE=
github.com/mitchellh/mapstructure v1.1.2/go.mod h1:FVVH3fgwuzCH5S8UJGiWEs2h04kUh9fWfEaFds41c1Y=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
github.com/modern-go/reflect2 v1.0.1/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/morikuni/aec v0.0.0-20170113033406-39771216ff4c h1:nXxl5PrvVm2L/wCy8dQu6DMTwH4oIuGN8GJDAlqDdVE=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/morikuni/aec v0.0.0-20170113033406-39771216ff4c/go.mod h1:BbKIizmSmc5MMPqRYbxO4ZU0S0+P200+tUnFx7PXmsc=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/mwitkow/go-conntrack v0.0.0-20161129095857-cc309e4a2223/go.mod h1:qRWi+5nqEBWmkhHvq77mSJWrCKwh8bxhgT7d/eI7P4U=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/nakagami/firebirdsql v0.0.0-20190310045651-3c02a58cfed8/go.mod h1:86wM1zFnC6/uDBfZGNwB65O+pR2OFi5q/YQaEUid1qA=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/neelance/astrewrite v0.0.0-20160511093645-99348263ae86/go.mod h1:kHJEU3ofeGjhHklVoIGuVj85JJwZ6kWPaJwCIxgnFmo=
github.com/neelance/sourcemap v0.0.0-20151028013722-8c68805598ab/go.mod h1:Qr6/a/Q4r9LP1IltGz7tA7iOK1WonHEYhu1HRBA7ZiM=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/nsf/jsondiff v0.0.0-20200515183724-f29ed568f4ce h1:RPclfga2SEJmgMmz2k+Mg7cowZ8yv4Trqw9UsJby758=
github.com/nsf/jsondiff v0.0.0-20200515183724-f29ed568f4ce/go.mod h1:uFMI8w+ref4v2r9jz+c9i1IfIttS/OkmLfrk1jne5hs=
github.com/nsf/termbox-go v0.0.0-20200418040025-38ba6e5628f1 h1:lh3PyZvY+B9nFliSGTn5uFuqQQJGuNrD0MLCokv09ag=
github.com/nsf/termbox-go v0.0.0-20200418040025-38ba6e5628f1/go.mod h1:IuKpRQcYE1Tfu+oAQqaLisqDeXgjyyltCfsaoYN18NQ=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/nxadm/tail v1.4.4 h1:DQuhQpB1tVlglWS2hLQ5OV6B5r8aGxSrPc5Qo6uTN78=
github.com/nxadm/tail v1.4.4/go.mod h1:kenIhsEOeOJmVchQTgglprH7qJGnHDVpk1VPCcaMI8A=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/oklog/ulid v1.3.1/go.mod h1:CirwcVhetQ6Lv90oh/F+FBtV6XMibvdAFo93nm5qn4U=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/onsi/ginkgo v1.7.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/onsi/ginkgo v1.10.3 h1:OoxbjfXVZyod1fmWYhI7SEyaD8B00ynP3T+D5GiyHOY=
all: use monkit v3 this commit updates our monkit dependency to the v3 version where it outputs in an influx style. this makes discovery much easier as many tools are built to look at it this way. graphite and rothko will suffer some due to no longer being a tree based on dots. hopefully time will exist to update rothko to index based on the new metric format. it adds an influx output for the statreceiver so that we can write to influxdb v1 or v2 directly. Change-Id: Iae9f9494a6d29cfbd1f932a5e71a891b490415ff
2019-11-08 20:40:39 +00:00
github.com/onsi/ginkgo v1.10.3/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/onsi/ginkgo v1.12.1/go.mod h1:zj2OWP4+oCPe1qIXoGWkgMRwljMUYCdkwsT2108oapk=
github.com/onsi/ginkgo v1.14.0 h1:2mOpI4JVVPBN+WQRa0WKH2eXR+Ey+uK4n7Zj0aYpIQA=
github.com/onsi/ginkgo v1.14.0/go.mod h1:iSB4RoI2tjJc9BBv4NKIKWKya62Rps+oPG/Lv9klQyY=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/onsi/gomega v1.4.3/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/onsi/gomega v1.7.1 h1:K0jcRCwNQM3vFGh1ppMtDh/+7ApJrjldlX8fA0jDTLQ=
all: use monkit v3 this commit updates our monkit dependency to the v3 version where it outputs in an influx style. this makes discovery much easier as many tools are built to look at it this way. graphite and rothko will suffer some due to no longer being a tree based on dots. hopefully time will exist to update rothko to index based on the new metric format. it adds an influx output for the statreceiver so that we can write to influxdb v1 or v2 directly. Change-Id: Iae9f9494a6d29cfbd1f932a5e71a891b490415ff
2019-11-08 20:40:39 +00:00
github.com/onsi/gomega v1.7.1/go.mod h1:XdKZgCCFLUoM/7CFJVPcG8C1xQ1AJ0vpAezJrB7JYyY=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/onsi/gomega v1.10.1 h1:o0+MgICZLuZ7xjH7Vx6zS/zcu93/BEp1VwkIW1mEXCE=
github.com/onsi/gomega v1.10.1/go.mod h1:iN09h71vgCQne3DLsj+A5owkum+a2tYe+TOCB1ybHNo=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/opencontainers/go-digest v1.0.0-rc1 h1:WzifXhOVOEOuFYOJAW6aQqW0TooG2iki3E3Ii+WN7gQ=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/opencontainers/go-digest v1.0.0-rc1/go.mod h1:cMLVZDEM3+U2I4VmLI6N8jQYUd2OVphdqWwCJHrFt2s=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/opencontainers/image-spec v1.0.1 h1:JMemWkRwHx4Zj+fVxWoMCFm/8sYGGrUVojFA6h/TRcI=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/opencontainers/image-spec v1.0.1/go.mod h1:BtxoFyWECRxE4U/7sNtV5W15zMzWCbyJoFRP3s7yZA0=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/openzipkin/zipkin-go v0.1.1/go.mod h1:NtoC/o8u3JlF1lSlyPNswIbeQH9bJTmOf0Erfk+hxe8=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/openzipkin/zipkin-go v0.1.6/go.mod h1:QgAqvLzwWbR/WpD4A3cGpPtJrZXNIiJc5AZX7/PBEpw=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/pascaldekloe/goe v0.0.0-20180627143212-57f6aae5913c/go.mod h1:lzWF7FIEvWOWxwDKqyGYQf6ZUaNfKdP144TG7ZOy1lc=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/pelletier/go-toml v1.2.0 h1:T5zMGML61Wp+FlcbWjRDT7yAxhJNAiPPLOFECq181zc=
github.com/pelletier/go-toml v1.2.0/go.mod h1:5z9KED0ma1S8pY6P1sdut58dfprrGBbd/94hg7ilaic=
github.com/pierrec/lz4 v2.0.5+incompatible/go.mod h1:pdkljMzZIN41W+lC3N2tnIh5sFi+IEE17M5jbnwPHcY=
github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
Upgrade monkit-hw (#984)
2019-01-07 19:11:11 +00:00
github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
cmd;pkg/server: init tracing collector in all processes Add tracing handler in drpc server. Initializing tracing collector in admin, satellite api, garbage collection, satellite core, repaier, storagenode. Change-Id: Ie98420e35dfc6913836ebd82b517d9d12877aefc Change-Id: I91057b6265a4ac8bde033dfde692b8a28acca99f
2020-03-30 16:22:32 +01:00
github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/posener/complete v1.1.1/go.mod h1:em0nMJCgc9GFtwrmVmEMR/ZL6WyhyjMBndrE9hABlRI=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/prometheus/client_golang v0.8.0/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/prometheus/client_golang v0.9.1/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/prometheus/client_golang v0.9.3-0.20190127221311-3c4408c8b829/go.mod h1:p2iRAGwDERtqlqzRXnrOVns+ignqQo//hLXqYxZYVNs=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/prometheus/client_golang v0.9.3/go.mod h1:/TN21ttK/J9q6uSwhBd54HahCDft0ttaMvbicHlPoso=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
github.com/prometheus/client_model v0.0.0-20180712105110-5c3871d89910/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/prometheus/client_model v0.0.0-20190115171406-56726106282f/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/prometheus/common v0.0.0-20180801064454-c7de2306084e/go.mod h1:daVV7qP5qjZbuso7PdcryaAu0sAZbrN9i7WWcTMWvro=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/prometheus/common v0.0.0-20181113130724-41aa239b4cce/go.mod h1:daVV7qP5qjZbuso7PdcryaAu0sAZbrN9i7WWcTMWvro=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/prometheus/common v0.2.0/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/prometheus/common v0.4.0/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/prometheus/procfs v0.0.0-20180725123919-05ee40e3a273/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/prometheus/procfs v0.0.0-20181005140218-185b4288413d/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/prometheus/procfs v0.0.0-20190117184657-bf6a532e95b1/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/prometheus/procfs v0.0.0-20190507164030-5867b95ac084/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA=
github.com/prometheus/tsdb v0.7.1/go.mod h1:qhTCs0VvXwvX/y3TZrWD7rabWM+ijKTux40TwIPHuXU=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/rcrowley/go-metrics v0.0.0-20181016184325-3113b8401b8a/go.mod h1:bCqnVzQkZxMG4s8nGwiZ5l3QUCyqpo9Y+/ZMZ9VjZe4=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/rogpeppe/fastuuid v0.0.0-20150106093220-6724a57986af/go.mod h1:XWv6SoW27p1b0cqNHllgS5HIMJraePCO15w5zCzIWYg=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/rs/xid v1.2.1/go.mod h1:+uKXf+4Djp6Md1KODXJxgGQPKngRmWyn10oCKFzNHOQ=
github.com/rs/zerolog v1.13.0/go.mod h1:YbFCdg8HfsridGWAh22vktObvhZbQsZXe4/zB0OKkWU=
github.com/rs/zerolog v1.15.0/go.mod h1:xYTKnLHcpfU2225ny5qZjxnj9NvkumZYjJHlAThCjNc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/russross/blackfriday v1.5.2/go.mod h1:JO/DiYxRf+HjHt06OyowR9PTA263kcR/rfWxYHBV53g=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
github.com/russross/blackfriday/v2 v2.0.1/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/ryanuber/columnize v0.0.0-20160712163229-9b3edd62028f/go.mod h1:sm1tb6uqfes/u+d4ooFouqFdy9/2g9QGwK3SQygK0Ts=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/sean-/seed v0.0.0-20170313163322-e2103e2c3529/go.mod h1:DxrIzT+xaE7yg65j358z/aeFdxmN0P9QXhEzd20vsDc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/sergi/go-diff v1.0.0/go.mod h1:0CfEIISq7TuYL3j771MWULgwwjU+GofnZX9QAmXWZgo=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/shopspring/decimal v0.0.0-20180709203117-cd690d0c9e24/go.mod h1:M+9NzErvs504Cn4c5DxATwIqPbtswREoFCre64PpcG4=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/shopspring/decimal v0.0.0-20200227202807-02e2044944cc/go.mod h1:DKyhrW/HYNuLGql+MJL6WCR6knT2jwCFRcu2hWCYk4o=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/shopspring/decimal v1.2.0 h1:abSATXmQEYyShuxI4/vyW3tV1MrKAJzCZ/0zLUXYbsQ=
github.com/shopspring/decimal v1.2.0/go.mod h1:DKyhrW/HYNuLGql+MJL6WCR6knT2jwCFRcu2hWCYk4o=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/shurcooL/component v0.0.0-20170202220835-f88ec8f54cc4/go.mod h1:XhFIlyj5a1fBNx5aJTbKoIq0mNaPvOagO+HjB3EtxrY=
github.com/shurcooL/events v0.0.0-20181021180414-410e4ca65f48/go.mod h1:5u70Mqkb5O5cxEA8nxTsgrgLehJeAw6Oc4Ab1c/P1HM=
github.com/shurcooL/github_flavored_markdown v0.0.0-20181002035957-2122de532470/go.mod h1:2dOwnU2uBioM+SGy2aZoq1f/Sd1l9OkAeAUvjSyvgU0=
github.com/shurcooL/go v0.0.0-20180423040247-9e1955d9fb6e/go.mod h1:TDJrrUr11Vxrven61rcy3hJMUqaf/CLWYhHNPmT14Lk=
github.com/shurcooL/go-goon v0.0.0-20170922171312-37c2f522c041/go.mod h1:N5mDOmsrJOB+vfqUK+7DmDyjhSLIIBnXo9lvZJj3MWQ=
github.com/shurcooL/gofontwoff v0.0.0-20180329035133-29b52fc0a18d/go.mod h1:05UtEgK5zq39gLST6uB0cf3NEHjETfB4Fgr3Gx5R9Vw=
github.com/shurcooL/gopherjslib v0.0.0-20160914041154-feb6d3990c2c/go.mod h1:8d3azKNyqcHP1GaQE/c6dDgjkgSx2BZ4IoEi4F1reUI=
github.com/shurcooL/highlight_diff v0.0.0-20170515013008-09bb4053de1b/go.mod h1:ZpfEhSmds4ytuByIcDnOLkTHGUI6KNqRNPDLHDk+mUU=
github.com/shurcooL/highlight_go v0.0.0-20181028180052-98c3abbbae20/go.mod h1:UDKB5a1T23gOMUJrI+uSuH0VRDStOiUVSjBTRDVBVag=
github.com/shurcooL/home v0.0.0-20181020052607-80b7ffcb30f9/go.mod h1:+rgNQw2P9ARFAs37qieuu7ohDNQ3gds9msbT2yn85sg=
github.com/shurcooL/htmlg v0.0.0-20170918183704-d01228ac9e50/go.mod h1:zPn1wHpTIePGnXSHpsVPWEktKXHr6+SS6x/IKRb7cpw=
github.com/shurcooL/httperror v0.0.0-20170206035902-86b7830d14cc/go.mod h1:aYMfkZ6DWSJPJ6c4Wwz3QtW22G7mf/PEgaB9k/ik5+Y=
github.com/shurcooL/httpfs v0.0.0-20171119174359-809beceb2371/go.mod h1:ZY1cvUeJuFPAdZ/B6v7RHavJWZn2YPVFQ1OSXhCGOkg=
github.com/shurcooL/httpgzip v0.0.0-20180522190206-b1c53ac65af9/go.mod h1:919LwcH0M7/W4fcZ0/jy0qGght1GIhqyS/EgWGH2j5Q=
github.com/shurcooL/issues v0.0.0-20181008053335-6292fdc1e191/go.mod h1:e2qWDig5bLteJ4fwvDAc2NHzqFEthkqn7aOZAOpj+PQ=
github.com/shurcooL/issuesapp v0.0.0-20180602232740-048589ce2241/go.mod h1:NPpHK2TI7iSaM0buivtFUc9offApnI0Alt/K8hcHy0I=
github.com/shurcooL/notifications v0.0.0-20181007000457-627ab5aea122/go.mod h1:b5uSkrEVM1jQUspwbixRBhaIjIzL2xazXp6kntxYle0=
github.com/shurcooL/octicon v0.0.0-20181028054416-fa4f57f9efb2/go.mod h1:eWdoE5JD4R5UVWDucdOPg1g2fqQRq78IQa9zlOV1vpQ=
github.com/shurcooL/reactions v0.0.0-20181006231557-f2e0b4ca5b82/go.mod h1:TCR1lToEk4d2s07G3XGfz2QrgHXg4RJBvjrOozvoWfk=
github.com/shurcooL/sanitized_anchor_name v0.0.0-20170918181015-86672fcb3f95/go.mod h1:1NzhyTcUVG4SuEtjjoZeVRXNmyL/1OwPU0+IJeTBvfc=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
github.com/shurcooL/sanitized_anchor_name v1.0.0/go.mod h1:1NzhyTcUVG4SuEtjjoZeVRXNmyL/1OwPU0+IJeTBvfc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/shurcooL/users v0.0.0-20180125191416-49c67e49c537/go.mod h1:QJTqeLYEDaXHZDBsXlPCDqdhQuJkuw4NOtaxYe3xii4=
github.com/shurcooL/webdavfs v0.0.0-20170829043945-18c3829fa133/go.mod h1:hKmq5kWdCj2z2KEozexVbfEZIWiTjhE0+UjmZgPqehw=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/sirupsen/logrus v1.4.1/go.mod h1:ni0Sbl8bgC9z8RoU9G6nDWqqs/fq4eDPysMBDgk/93Q=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/smartystreets/assertions v0.0.0-20180927180507-b2de0cb4f26d h1:zE9ykElWQ6/NYmHa3jpm/yHnI4xSofP+UP6SpjHcSeM=
github.com/smartystreets/assertions v0.0.0-20180927180507-b2de0cb4f26d/go.mod h1:OnSkiWE9lh6wB0YB77sQom3nweQdgAjqCqsofrRNTgc=
github.com/smartystreets/goconvey v1.6.4 h1:fv0U8FUIMPNf1L9lnHLvLhgicrIVChEkdzIKYqbNC9s=
github.com/smartystreets/goconvey v1.6.4/go.mod h1:syvi0/a8iFYH4r/RixwvyeAJjdLS9QV7WQ/tjFTllLA=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/soheilhy/cmux v0.1.4/go.mod h1:IM3LyeVVIOuxMH7sFAkER9+bJ4dT7Ms6E4xg4kGIyLM=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/sourcegraph/annotate v0.0.0-20160123013949-f4cad6c6324d/go.mod h1:UdhH50NIW0fCiwBSr0co2m7BnFLdv4fQTgdqdJTHFeE=
github.com/sourcegraph/syntaxhighlight v0.0.0-20170531221838-bd320f5d308e/go.mod h1:HuIsMU8RRBOtsCgI77wP899iHVBQpCmg4ErYMZB+2IA=
all: use monkit v3 this commit updates our monkit dependency to the v3 version where it outputs in an influx style. this makes discovery much easier as many tools are built to look at it this way. graphite and rothko will suffer some due to no longer being a tree based on dots. hopefully time will exist to update rothko to index based on the new metric format. it adds an influx output for the statreceiver so that we can write to influxdb v1 or v2 directly. Change-Id: Iae9f9494a6d29cfbd1f932a5e71a891b490415ff
2019-11-08 20:40:39 +00:00
github.com/spacemonkeygo/monkit/v3 v3.0.0-20191108235033-eacca33b3037/go.mod h1:JcK1pCbReQsOsMKF/POFSZCq7drXFybgGmbc27tuwes=
upgrade dependencies for trace db debug endpoint Change-Id: I4de658b361bb39ce28dc31b982895bb4f45b580a
2020-03-03 22:15:14 +00:00
github.com/spacemonkeygo/monkit/v3 v3.0.4/go.mod h1:JcK1pCbReQsOsMKF/POFSZCq7drXFybgGmbc27tuwes=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
github.com/spacemonkeygo/monkit/v3 v3.0.5/go.mod h1:JcK1pCbReQsOsMKF/POFSZCq7drXFybgGmbc27tuwes=
all: use DialNodeURL throughout the codebase Change-Id: Iaf9ae3aeef7305c937f2660c929744db2d88776c
2020-05-19 16:49:13 +01:00
github.com/spacemonkeygo/monkit/v3 v3.0.7-0.20200515175308-072401d8c752 h1:WcQDknqg0qajLNYKv3mXgbkWlYs5rPgZehGJFWePHVI=
github.com/spacemonkeygo/monkit/v3 v3.0.7-0.20200515175308-072401d8c752/go.mod h1:kj1ViJhlyADa7DiA4xVnTuPA46lFKbM7mxQTrXCuJP4=
mod: bump dependencies Change-Id: I61beaf9793609f7614478cfa604b2721d9010b52
2020-10-30 14:17:55 +00:00
github.com/spacemonkeygo/monkit/v3 v3.0.7 h1:LsGdIXl8mccqJrYEh4Uf4sLVGu/g0tjhNqQzdn9MzVk=
github.com/spacemonkeygo/monkit/v3 v3.0.7/go.mod h1:kj1ViJhlyADa7DiA4xVnTuPA46lFKbM7mxQTrXCuJP4=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/spacemonkeygo/monotime v0.0.0-20180824235756-e3f48a95f98a/go.mod h1:ul4bvvnCOPZgq8w0nTkSmWVg/hauVpFS97Am1YM1XXo=
github.com/spacemonkeygo/spacelog v0.0.0-20180420211403-2296661a0572 h1:RC6RW7j+1+HkWaX/Yh71Ee5ZHaHYt7ZP4sQgUrm6cDU=
github.com/spacemonkeygo/spacelog v0.0.0-20180420211403-2296661a0572/go.mod h1:w0SWMsp6j9O/dk4/ZpIhL+3CkG8ofA2vuv7k+ltqUMc=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
github.com/spaolacci/murmur3 v0.0.0-20180118202830-f09979ecbc72/go.mod h1:JwIasOWyU6f++ZhiEuf87xNszmSA2myDM2Kzu9HwQUA=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/spf13/afero v1.1.2 h1:m8/z1t7/fwjysjQRYbP0RD+bUIF/8tJwPdEZsI83ACI=
github.com/spf13/afero v1.1.2/go.mod h1:j4pytiNVoe2o6bmDsKpLACNPDBIoEAkihy7loJ1B0CQ=
Command line flags features and cleanup (#2068) * change BindSetup to be an option to Bind * add process.Bind to allow composite structures * hack fix for noprefix flags * used tagged version of structs Before this PR, some flags were created by calling `cfgstruct.Bind` and having their fields create a flag. Once the flags were parsed, `viper` was used to acquire all the values from them and config files, and the fields in the struct were set through the flag interface. This doesn't work for slices of things on config structs very well, since it can only set strings, and for a string slice, it turns out that the implementation in `pflag` appends an entry rather than setting it. This changes three things: 1. Only have a `Bind` call instead of `Bind` and `BindSetup`, and make `BindSetup` an option instead. 2. Add a `process.Bind` call that takes in a `*cobra.Cmd`, binds the struct to the command's flags, and keeps track of that struct in a global map keyed by the command. 3. Use `viper` to get the values and load them into the bound configuration structs instead of using the flags to propagate the changes. In this way, we can support whatever rich configuration we want in the config yaml files, while still getting command like flags when important.
2019-05-29 18:56:22 +01:00
github.com/spf13/cast v1.3.0 h1:oget//CVOEoFewqQxwr0Ej5yjygnqGkvggSE/gB35Q8=
github.com/spf13/cast v1.3.0/go.mod h1:Qx5cxh0v+4UWYiBimWS+eyWzqEqokIECu5etghLkUJE=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
github.com/spf13/cobra v0.0.6/go.mod h1:/6GTrnGXV9HjY+aR4k0oJ5tcvakLuG6EuKReYlHNrgE=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/spf13/cobra v1.0.0 h1:6m/oheQuQ13N9ks4hubMG6BnvwOeaJrqSPLahSnczz8=
github.com/spf13/cobra v1.0.0/go.mod h1:/6GTrnGXV9HjY+aR4k0oJ5tcvakLuG6EuKReYlHNrgE=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/spf13/jwalterweatherman v1.0.0 h1:XHEdyB+EcvlqZamSM4ZOMGlc93t6AcsBEu9Gc1vn7yk=
github.com/spf13/jwalterweatherman v1.0.0/go.mod h1:cQK4TGJAtQXfYWX+Ddv3mKDzgVb68N+wFjFa4jdeBTo=
github.com/spf13/pflag v1.0.3/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
github.com/spf13/pflag v1.0.5 h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA=
github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/spf13/viper v1.4.0/go.mod h1:PTJ7Z/lr49W6bUbkmS1V3by4uWynFiR9p7+dSq/yZzE=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/spf13/viper v1.7.1 h1:pM5oEahlgWv/WnHXpgbKz7iLIxRf65tye2Ci+XFK5sk=
github.com/spf13/viper v1.7.1/go.mod h1:8WkrPz2fc9jxqZNCJI/76HCieCp4Q8HaLFoCha5qpdg=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
Certificate revocation (#836) * wip certificate revocation * refactor tests * wip testing * testing * review fixes * integration fix attempt #1 * review fixes * integration fix attempt #2 * linter fixes * add copywrite * integration fix attemp #3 * more testing * more tests * go mod tidy * review fixes * linter fixes
2018-12-13 20:01:43 +00:00
github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/stretchr/objx v0.2.0/go.mod h1:qt09Ya8vawLte6SNmTgCsAVtYtaKzEcn8ATUoHMkEqE=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
all: use monkit v3 this commit updates our monkit dependency to the v3 version where it outputs in an influx style. this makes discovery much easier as many tools are built to look at it this way. graphite and rothko will suffer some due to no longer being a tree based on dots. hopefully time will exist to update rothko to index based on the new metric format. it adds an influx output for the statreceiver so that we can write to influxdb v1 or v2 directly. Change-Id: Iae9f9494a6d29cfbd1f932a5e71a891b490415ff
2019-11-08 20:40:39 +00:00
github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4=
bump storj.io/common to latest and storj.io/drpc to v0.0.11 Change-Id: I7a6e823b441eeff4621dfdf2d6577be76c9761c8
2020-03-24 17:49:20 +00:00
github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/stretchr/testify v1.6.1 h1:hDPOHmpOpP40lSULcqw7IrRb/u7w6RpDC9399XyoNd0=
github.com/stretchr/testify v1.6.1/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=
satellite/payments: add finalize invoice command Change-Id: Ib74dc8fd352e9576a302f5923439f5e50f69c9f0
2020-06-09 16:18:36 +01:00
github.com/stripe/stripe-go v70.15.0+incompatible h1:hNML7M1zx8RgtepEMlxyu/FpVPrP7KZm1gPFQquJQvM=
github.com/stripe/stripe-go v70.15.0+incompatible/go.mod h1:A1dQZmO/QypXmsL0T8axYZkSN/uA/T/A64pfKdBAMiY=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/subosito/gotenv v1.2.0 h1:Slr1R9HxAlEKefgq5jn9U+DnETlIUa6HfgEzj0g5d7s=
github.com/subosito/gotenv v1.2.0/go.mod h1:N0PQaV/YGNqwC0u51sEeR/aUtSLEXKX9iv69rRypqCw=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/tarm/serial v0.0.0-20180830185346-98f6abe2eb07/go.mod h1:kDXzergiv9cbyO7IOYJZWg1U88JhDg3PB6klq9Hg2pA=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/tidwall/pretty v0.0.0-20180105212114-65a9db5fad51/go.mod h1:XNkn88O1ChpSDQmQeStsy+sBenx6DDtFZJxhVysOjyk=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/tmc/grpc-websocket-proxy v0.0.0-20190109142713-0ad062ec5ee5/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U=
github.com/ugorji/go v1.1.4/go.mod h1:uQMGLiO92mf5W77hV/PUCpI3pbzQx3CRekS0kk+RGrc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
github.com/viant/assertly v0.4.8/go.mod h1:aGifi++jvCrUaklKEKT0BU95igDNaqkvz+49uaYMPRU=
github.com/viant/toolbox v0.24.0/go.mod h1:OxMCG57V0PXuIP2HNQrtJf2CjqdmbrOx5EkMILuUhzM=
storj: update to uplink v1.1.1 Change-Id: Ia62f3a84cbca89320714e819fc445606365f0647
2020-06-12 13:11:47 +01:00
github.com/vivint/infectious v0.0.0-20200605153912-25a574ae18a3 h1:zMsHhfK9+Wdl1F7sIKLyx3wrOFofpb3rWFbA4HgcK5k=
github.com/vivint/infectious v0.0.0-20200605153912-25a574ae18a3/go.mod h1:R0Gbuw7ElaGSLOZUSwBm/GgVwMd30jWxBDdAyMOeTuc=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
github.com/xanzy/go-gitlab v0.15.0/go.mod h1:8zdQa/ri1dfn8eS3Ir1SyfvOKlw7WBJ8DVThkpGiXrs=
github.com/xdg/scram v0.0.0-20180814205039-7eeb5667e42c/go.mod h1:lB8K/P019DLNhemzwFU4jHLhdvlE6uDZjXFejJXr49I=
github.com/xdg/stringprep v1.0.0/go.mod h1:Jhud4/sHMO4oL310DaZAKk9ZaJ08SJfe+sJh0HrGL1Y=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2/go.mod h1:UETIi67q53MR2AWcXfiuqkDkRtnGDLqkBTpCHuJHxtU=
github.com/xordataexchange/crypt v0.0.3-0.20170626215501-b2862e3d0a77/go.mod h1:aYKd//L2LvnjZzWKhF00oedf4jCCReLcmhLdhm1A27Q=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
github.com/yuin/gopher-lua v0.0.0-20191220021717-ab39c6098bdb h1:ZkM6LRnq40pR1Ox0hTHlnpkcOTuFIDQpZ1IN8rKKhX0=
github.com/yuin/gopher-lua v0.0.0-20191220021717-ab39c6098bdb/go.mod h1:gqRgreBUhTSL0GeU64rtZ3Uq3wtjOa/TB2YfrtkCbVQ=
storagenode: monitor available space and bandwidth Change-Id: I5763597327c5b32982faab8910c136c6c8dc18c5
2020-02-09 00:04:23 +00:00
github.com/zeebo/admission/v2 v2.0.0/go.mod h1:gSeHGelDHW7Vq6UyJo2boeSt/6Dsnqpisv0i4YZSOyM=
cmd/uplink: Enable telemetry on ctx Change-Id: I26ffbbb72b9f2ca71b629ba12637c74c2aa072c3
2020-03-11 12:45:38 +00:00
github.com/zeebo/admission/v3 v3.0.1 h1:/IWg2jLhfjBOUhhdKcbweSzcY3QlbbE57sqvU72EpqA=
github.com/zeebo/admission/v3 v3.0.1/go.mod h1:BP3isIv9qa2A7ugEratNq1dnl2oZRXaQUGdU7WXKtbw=
Command line flags features and cleanup (#2068) * change BindSetup to be an option to Bind * add process.Bind to allow composite structures * hack fix for noprefix flags * used tagged version of structs Before this PR, some flags were created by calling `cfgstruct.Bind` and having their fields create a flag. Once the flags were parsed, `viper` was used to acquire all the values from them and config files, and the fields in the struct were set through the flag interface. This doesn't work for slices of things on config structs very well, since it can only set strings, and for a string slice, it turns out that the implementation in `pflag` appends an entry rather than setting it. This changes three things: 1. Only have a `Bind` call instead of `Bind` and `BindSetup`, and make `BindSetup` an option instead. 2. Add a `process.Bind` call that takes in a `*cobra.Cmd`, binds the struct to the command's flags, and keeps track of that struct in a global map keyed by the command. 3. Use `viper` to get the values and load them into the bound configuration structs instead of using the flags to propagate the changes. In this way, we can support whatever rich configuration we want in the config yaml files, while still getting command like flags when important.
2019-05-29 18:56:22 +01:00
github.com/zeebo/assert v0.0.0-20181109011804-10f827ce2ed6/go.mod h1:yssERNPivllc1yU3BvpjYI5BUW+zglcz6QWqeVRL5t0=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
github.com/zeebo/assert v1.1.0 h1:hU1L1vLTHsnO8x8c9KAR5GmM5QscxHg5RNU5z5qbUWY=
upgrade drpc so that we have the monkit metric capability Change-Id: Icdd08478aeff4fbd7148975eca8a21fac41289d7
2020-02-02 20:15:38 +00:00
github.com/zeebo/assert v1.1.0/go.mod h1:Pq9JiuJQpG8JLJdtkwrJESF0Foym2/D9XMU5ciN/wJ0=
Command line flags features and cleanup (#2068) * change BindSetup to be an option to Bind * add process.Bind to allow composite structures * hack fix for noprefix flags * used tagged version of structs Before this PR, some flags were created by calling `cfgstruct.Bind` and having their fields create a flag. Once the flags were parsed, `viper` was used to acquire all the values from them and config files, and the fields in the struct were set through the flag interface. This doesn't work for slices of things on config structs very well, since it can only set strings, and for a string slice, it turns out that the implementation in `pflag` appends an entry rather than setting it. This changes three things: 1. Only have a `Bind` call instead of `Bind` and `BindSetup`, and make `BindSetup` an option instead. 2. Add a `process.Bind` call that takes in a `*cobra.Cmd`, binds the struct to the command's flags, and keeps track of that struct in a global map keyed by the command. 3. Use `viper` to get the values and load them into the bound configuration structs instead of using the flags to propagate the changes. In this way, we can support whatever rich configuration we want in the config yaml files, while still getting command like flags when important.
2019-05-29 18:56:22 +01:00
github.com/zeebo/errs v1.1.1/go.mod h1:Yj8dHrUQwls1bF3dr/vcSIu+qf4mI7idnTcHfoACc6I=
use-drpc: use protoc-gen-drpc to generate protobufs Change-Id: I5c23256068e30864022dba5137c499796ab9d6ad
2019-09-05 00:05:51 +01:00
github.com/zeebo/errs v1.2.2 h1:5NFypMTuSdoySVTqlNs1dEoU21QVamMQJxW/Fii5O7g=
github.com/zeebo/errs v1.2.2/go.mod h1:sgbWHsvVuTPHcqJJGQ1WhI5KbWlHYz+2+2C/LSEtCw4=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
github.com/zeebo/float16 v0.1.0 h1:kRqxv5og6z1emEyz5FpW0/BVHe5VfxEAw6b1ljCZlUc=
github.com/zeebo/float16 v0.1.0/go.mod h1:fssGvvXu+XS8MH57cKmyrLB/cqioYeYX/2mXCN3a5wo=
github.com/zeebo/incenc v0.0.0-20180505221441-0d92902eec54 h1:+cwNE5KJ3pika4HuzmDHkDlK5myo0G9Sv+eO7WWxnUQ=
github.com/zeebo/incenc v0.0.0-20180505221441-0d92902eec54/go.mod h1:EI8LcOBDlSL3POyqwC1eJhOYlMBMidES+613EtmmT5w=
lib/uplink: encryption context (#2349) * lib/uplink: encryption context Change-Id: I5c23dca3286a46b713b30c4997e9ae6e630b2280 * lib/uplink: bucket operation examples Change-Id: Ia0f6e69f365dcff0cf11c731f51b30842bce053b * lib/uplink: encryption key sharing test cases Change-Id: I3a172d565f33f4e591402cdcb9460664a7cc7fbe * fix encrypted path prefix restriction issue Change-Id: I8f3921f9d52aaf4b84039de608b8cbbc88769554 * implement panics in libuplink encryption code todo on cipher suite selection as well as an api concern Change-Id: Ifa39eb3cc4b3443f7d96f9304df9b2ac4ec4085d * implement GetProjectInfo api call to get salt Change-Id: Ic5f6b3be9ea35df48c1aa214ab5d355fb328e2cf * some fixes and accessors for encryption store Change-Id: I3bb61f6712a037900e2a96e72ad4029ec1d3f718 * general fixes to builds/tests/etc Change-Id: I9930fa96acb3b221d9a001f8e274af5729cc8a47 * java bindings changes Change-Id: Ia2bd4c9c69739c8d3154d79616cff1f36fb403b6 * get libuplink examples passing Change-Id: I828f09a144160e0a5dd932324f78491ae2ec8a07 * fix proto.lock file Change-Id: I2fbbf4d0976a7d0473c2645e6dcb21aaa3be7651 * fix proto.lock again Change-Id: I92702cf49e1a340eef6379c2be4f7c4a268112a9 * fix golint issues Change-Id: I631ff9f43307a58e3b25a58cbb4a4cc2495f5eb6 * more linting fixes Change-Id: I51f8f30b367b5bca14c94b15417b9a4c9e7aa0ce * bug fixed by structs bump Change-Id: Ibb03c691fce7606c35c08721b3ef0781ab48a38a * retrigger Change-Id: Ieee0470b6a2d07168a1578552e8e7f271ae93a13 * retrigger Change-Id: I753d63853171e6a436c104ce176048892eb974c5 * semantic merge conflict Change-Id: I9419448496de90340569047a6a16a1b858a7978a * update total to match prod defaults Change-Id: I693d55c1ebb28b5803ee1d26e9e198decf82308b * retrigger Change-Id: I28b74d5d6202f61aa3866fe407d423f6a0a14b9e * retrigger Change-Id: I6fd054885c715f602e2cef623fd464c42e88742c * retrigger Change-Id: I6a01bae88c72406d4ed5a8f13bf8a2b3c650bd2d
2019-06-27 18:36:51 +01:00
github.com/zeebo/structs v1.0.2 h1:kvcd7s2LqXuO9cdV5LqrGHCOAfCBXaZpKCA3jD9SJIc=
github.com/zeebo/structs v1.0.2/go.mod h1:LphfpprlqJQcbCq+eA3iIK/NsejMwk9mlfH/tM1XuKQ=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
github.com/zenazn/goji v0.9.0/go.mod h1:7S9M489iMyHBNxwZnk9/EHS098H4/F6TATF2mIxtB1Q=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
gitlab.com/nyarla/go-crypt v0.0.0-20160106005555-d9a5dc2b789b/go.mod h1:T3BPAOm2cqquPa0MKWeNkmOM5RQsRhkrwMWonFMN7fE=
update some packages so we don't depend on launchpad (#1644)
2019-04-02 19:43:24 +01:00
go.etcd.io/bbolt v1.3.2/go.mod h1:IbVyRI1SCnLcuJnV2u8VeU0CEYM7e686BmAb1XKL+uU=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
go.etcd.io/bbolt v1.3.5 h1:XAzx9gjCb0Rxj7EoqcClPD1d5ZBxZJk0jbuoPHenBt0=
go.etcd.io/bbolt v1.3.5/go.mod h1:G5EMThwa9y8QZGBClrRx5EY+Yw9kAhnjy3bSjsnlVTQ=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
go.mongodb.org/mongo-driver v1.1.0/go.mod h1:u7ryQJ+DOzQmeO7zB6MHyr8jkEQvC8vH7qLUO4lqsUM=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
go.opencensus.io v0.18.0/go.mod h1:vKdFvxhtzZ9onBp9VKHK8z/sRpBMnKAsufL7wlDrCOA=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
go.opencensus.io v0.20.1/go.mod h1:6WKK9ahsWS3RSO+PY9ZHZUfv2irvY6gN279GOPZjmmk=
go.opencensus.io v0.21.0/go.mod h1:mSImk1erAIZhrmZN+AvHh14ztQfjbGwt4TtuofqLduU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
go.opencensus.io v0.22.0/go.mod h1:+kGneAE2xo2IficOXnaByMWTGM9T73dGwxeWcUqIpI8=
go.opencensus.io v0.22.2 h1:75k/FF0Q2YM8QYo07VPddOLBslDt1MZOdEslOHvmzAs=
go.opencensus.io v0.22.2/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
go.uber.org/atomic v1.3.2/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
go.uber.org/atomic v1.4.0/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
go.uber.org/atomic v1.6.0 h1:Ezj3JGmsOnG1MoRWQkPBsKLe9DwWD9QeXzTRzzldNVk=
go.uber.org/atomic v1.6.0/go.mod h1:sABNBOSYdrvTF6hTgEIbc7YasKWGhgEQZyfxyTvoXHQ=
mod: bump dependencies Change-Id: I61beaf9793609f7614478cfa604b2721d9010b52
2020-10-30 14:17:55 +00:00
go.uber.org/atomic v1.7.0 h1:ADUqmZGgLDDfbSL9ZmPxKTybcoEYHgpYfELNoN+7hsw=
go.uber.org/atomic v1.7.0/go.mod h1:fEN4uk6kAWBTFdckzkM89CLk9XfWZrxpCo0nPH17wJc=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
go.uber.org/multierr v1.5.0 h1:KCa4XfM8CWFCpxXRGok+Q0SS/0XBhMDbHHGABQLvD2A=
go.uber.org/multierr v1.5.0/go.mod h1:FeouvMocqHpRaaGuG9EjoKcStLC43Zu/fmqdUMPcKYU=
mod: bump dependencies Change-Id: I61beaf9793609f7614478cfa604b2721d9010b52
2020-10-30 14:17:55 +00:00
go.uber.org/multierr v1.6.0 h1:y6IPFStTAIT5Ytl7/XYmHvzXQ7S3g/IeZW9hyZ5thw4=
go.uber.org/multierr v1.6.0/go.mod h1:cdWPpRnG4AhwMwsgIHip0KRBQjJy5kYEpYjJxpXp9iU=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
go.uber.org/tools v0.0.0-20190618225709-2cfd321de3ee h1:0mgffUl7nfd+FpvXMVz4IDEaUSmT1ysygQC7qYo7sG4=
go.uber.org/tools v0.0.0-20190618225709-2cfd321de3ee/go.mod h1:vJERXedbb3MVM5f9Ejo0C68/HhF8uaILCdgjnY+goOA=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
go.uber.org/zap v1.9.1/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
go.uber.org/zap v1.14.1/go.mod h1:Mb2vm2krFEG5DV0W9qcHBYFtp/Wku1cvYaqPsS/WYfc=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
go.uber.org/zap v1.16.0 h1:uFRZXykJGK9lLY4HtgSw44DnIcAM+kRBP7x5m+NpAOM=
go.uber.org/zap v1.16.0/go.mod h1:MA8QOfq0BHJwdXa996Y4dYkAqRKB8/1K1QMMZVaNZjQ=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
go4.org v0.0.0-20180809161055-417644f6feb5/go.mod h1:MkTOUMDaeVYJUOUsaDXIhWPZYa1yOyC1qaOBpL57BhE=
golang.org/x/build v0.0.0-20190111050920-041ab4dc3f9d/go.mod h1:OWs+y06UdEOHN4y+MfF/py+xQ/tYqIWW03b70/CG9Rw=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/crypto v0.0.0-20170930174604-9419663f5a44/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/crypto v0.0.0-20181029021203-45a5f77698d3/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/crypto v0.0.0-20181030102418-4d3f4d9ffa16/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
API endpoint checking object and segment health from the satellite (#1546) * Generate protobuf for checking object and segment health * Initial cmd client for health check * Register the health inspector on the satellite peer
2019-04-02 15:55:58 +01:00
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/crypto v0.0.0-20190313024323-a1f597ede03a/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/crypto v0.0.0-20190325154230-a5d413f7728c/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/crypto v0.0.0-20190411191339-88737f569e3a/go.mod h1:WFFai1msRO1wXaEeE5yQxYXgSfI8pQAWXbQop6sCtWE=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/crypto v0.0.0-20190426145343-a29dc8fdc734/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
golang.org/x/crypto v0.0.0-20190605123033-f99c8df09eb5/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
golang.org/x/crypto v0.0.0-20190911031432-227b76d455e7/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/crypto v0.0.0-20200115085410-6d4e4cb37c7d/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
go.mod: Update golang.org/x/crypto to fix vulnerability Update the golang.org/x/crypto package to fix the vulnerability CVE-2020-9283. See https://groups.google.com/forum/#!topic/golang-nuts/XDqhhjZViNk Change-Id: I7c841c0bae0f55dad0c7de19ac70c730d11733f0
2020-02-21 10:30:05 +00:00
golang.org/x/crypto v0.0.0-20200220183623-bac4c82f6975/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/crypto v0.0.0-20200221231518-2aa609cf4a9d/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/crypto v0.0.0-20200323165209-0ec3e9974c59/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
satellite/metainfo: Add RevokeAPIKey stub endpoint Change-Id: I07fb997dda48ea204aab11f656a1a37762684339
2020-06-16 14:03:02 +01:00
golang.org/x/crypto v0.0.0-20200604202706-70a84ac30bf9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
go.mod: update pgx to v4.9.0 Fix query to use TextArray instead of VarcharArray. Fix queries to use the correct type. Change-Id: Ibb7e55adba277d05778118d81ca697470e72c374
2020-09-29 10:53:15 +01:00
golang.org/x/crypto v0.0.0-20200820211705-5c72a883971a h1:vclmkQCjlDX5OydZ9wv8rBCcS0QyQY66Mpf/7BZbInM=
golang.org/x/crypto v0.0.0-20200820211705-5c72a883971a/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/exp v0.0.0-20190306152737-a1d7652674e8/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8=
golang.org/x/exp v0.0.0-20190829153037-c13cbed26979/go.mod h1:86+5VVa7VpoJ4kLfm080zCjGlMRFzhUhsZKEZO7MGek=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/exp v0.0.0-20191030013958-a1ab85dbe136/go.mod h1:JXzH8nQsPlswgeRAPE3MuO9GYsAcnJvJ4vnMwN/5qkY=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
golang.org/x/exp v0.0.0-20191227195350-da58074b4299 h1:zQpM52jfKHG6II1ISZY1ZcpygvuSFZpLwfluuF89XOg=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/exp v0.0.0-20191227195350-da58074b4299/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4=
golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js=
golang.org/x/image v0.0.0-20190802002840-cff245a6509b/go.mod h1:FeLwcggjj3mMvU+oOTbSwawSJRM1uh48EjtB4UJZlP0=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/lint v0.0.0-20180702182130-06c8688daad7/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/lint v0.0.0-20190301231843-5614ed5bae6f/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/lint v0.0.0-20190313153728-d0100b6bd8b3/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/lint v0.0.0-20190409202823-959b441ac422/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
golang.org/x/lint v0.0.0-20190909230951-414d861bb4ac/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
golang.org/x/lint v0.0.0-20190930215403-16217165b5de/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
golang.org/x/lint v0.0.0-20191125180803-fdd1cda4f05f h1:J5lckAjkw6qYlOZNj90mLYNTEKDvWeuc1yieZ8qUzUE=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/lint v0.0.0-20191125180803-fdd1cda4f05f/go.mod h1:5qLYkcX4OjUUV8bRuDixDT3tpyyb+LUpUlRWLxfhWrs=
golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6/go.mod h1:z+o9i4GpDbdi3rU15maQ/Ox0txvL9dWGYEHz965HBQE=
golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCcRqshq8CkpyQDoeVncDDYHnLhea+o=
golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc=
golang.org/x/mod v0.1.0/go.mod h1:0QHyrYULN0/3qlju5TqG8bIK38QM8yzMo5ekMj3DlcY=
golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/net v0.0.0-20180826012351-8a410e7b638d/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/net v0.0.0-20181023162649-9b4f9f5ad519/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/net v0.0.0-20181029044818-c44066c5c816/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
golang.org/x/net v0.0.0-20181106065722-10aee1819953/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/net v0.0.0-20181108082009-03003ca0c849/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/net v0.0.0-20181114220301-adae6a3d119a/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/net v0.0.0-20181201002055-351d144fa1fc/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
golang.org/x/net v0.0.0-20181220203305-927f97764cc3/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
golang.org/x/net v0.0.0-20190125091013-d26f9f9a57f3/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/net v0.0.0-20190213061140-3a22650c66bd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
API endpoint checking object and segment health from the satellite (#1546) * Generate protobuf for checking object and segment health * Initial cmd client for health check * Register the health inspector on the satellite peer
2019-04-02 15:55:58 +01:00
golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/net v0.0.0-20190313220215-9f648a60d977/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/net v0.0.0-20190424112056-4829fb13d2c6/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/net v0.0.0-20190501004415-9ce7a6920f09/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
golang.org/x/net v0.0.0-20190522155817-f3200d17e092/go.mod h1:HSz+uSET+XFnRR8LxR5pz3Of3rY3CfYBVs4xY44aLks=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/net v0.0.0-20190603091049-60506f45cf65/go.mod h1:HSz+uSET+XFnRR8LxR5pz3Of3rY3CfYBVs4xY44aLks=
golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
libuplink: adjust tests to changes in encryption store We move PathCipher to encryption.Store and we need to adjust storj/uplink for those changes. Uplink repo is also using libuplink to run tests so we need first adjust storj/storj libuplink and later storj/uplink. Change-Id: I84f23e6bad18ac139f72c19939dc526f9f46d88b
2020-01-30 14:35:14 +00:00
golang.org/x/net v0.0.0-20190923162816-aa69164e4478/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/net v0.0.0-20200114155413-6afb5195e5aa/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/net v0.0.0-20200520004742-59133d7f0dd7/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A=
golang.org/x/net v0.0.0-20200707034311-ab3426394381 h1:VXak5I6aEWmAXeQjA+QSZzlgNrpq9mjcfDemuexIKsU=
golang.org/x/net v0.0.0-20200707034311-ab3426394381/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/oauth2 v0.0.0-20181017192945-9dcd33a902f4/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/oauth2 v0.0.0-20181106182150-f42d05182288/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/oauth2 v0.0.0-20181203162652-d668ce993890/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
golang.org/x/oauth2 v0.0.0-20190402181905-9f3314589c9a/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d h1:TzXSXBo42m9gQenoE3b9BGiEpg5IG2JkU5FkPIawgtw=
golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/perf v0.0.0-20180704124530-6e6d33e29852/go.mod h1:JLpeXjPJfIyPr5TlbXLkXWLhP8nz10XfvxElABhCtcw=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
go.mod: update to grpc 1.23.1 and update golang.org/x (#3072)
2019-09-19 13:41:19 +01:00
golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
bump monkit, monkit-jaeger, and private to latest Also bump storj.io/common and sync repo Change-Id: If8e60db6bdf0af8077b7befcb1da304c3c4dcae4
2020-04-21 22:04:26 +01:00
golang.org/x/sync v0.0.0-20200317015054-43a5402ce75a/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
bump to uplink v1.2.0 Also fixup config and related tests for storj.io/common bee93690ab909580993f402b594ad5a14760c39f Change-Id: I6897d925cd28b139c1fc2b43e63b08c0cc3fb688
2020-08-03 17:36:39 +01:00
golang.org/x/sync v0.0.0-20200625203802-6e8e738ad208 h1:qwRHBd0NqMbJxfbotnDhm2ByMI1Shq4Y6oRJo21SGJA=
golang.org/x/sync v0.0.0-20200625203802-6e8e738ad208/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/sys v0.0.0-20180823144017-11551d06cbcc/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/sys v0.0.0-20181026203630-95b1ffbd15a5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/sys v0.0.0-20181029174526-d69651ed3497/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/sys v0.0.0-20181107165924-66b7b1311ac8/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/sys v0.0.0-20181122145206-62eef0e2fa9b/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190102155601-82a175fd1598/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
mod: upgrade miniredis to latest miniredis 2.5.0 had a bug with matching keys with newlines. Change-Id: I9bcf998459be6d7d4e03bca3589e989e5ed2304d
2020-02-06 12:56:23 +00:00
golang.org/x/sys v0.0.0-20190204203706-41f3e6584952/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
API endpoint checking object and segment health from the satellite (#1546) * Generate protobuf for checking object and segment health * Initial cmd client for health check * Register the health inspector on the satellite peer
2019-04-02 15:55:58 +01:00
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
cmd/uplink: fix progressbar data race (#2987)
2019-09-10 09:51:49 +01:00
golang.org/x/sys v0.0.0-20190222072716-a9d3bda3a223/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/sys v0.0.0-20190312061237-fead79001313/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/sys v0.0.0-20190316082340-a2f829d7f35f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/sys v0.0.0-20190403152447-81d4e9dc473e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
satellite/payments: move inspector commands to satellite cli This allows to seeing logs in the output of the invoice commands. Existing ensure-stripe-customer commands is moved from the 'reports' to the new 'billing' root command. Change-Id: I752c7ab6ca59bfac8e0f174a45d2ab45fc18e467
2020-05-18 13:21:35 +01:00
golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/sys v0.0.0-20190426135247-a129542de9ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/sys v0.0.0-20190502145724-3ef323f4f1fd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190606165138-5da285871e9c/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190624142023-c5567b49c5d0/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190826190057-c7b8b68b1456/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/sys v0.0.0-20190904154756-749cb33beabd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/sys v0.0.0-20191120155948-bd437916bb0e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/sys v0.0.0-20191204072324-ce4227a45e2e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
all: bump storj.io/common dependency Change-Id: I2e9ba0a76380d99d8650ae6921ed0a3ffe436536
2020-01-06 20:46:06 +00:00
golang.org/x/sys v0.0.0-20191210023423-ac6580df4449/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
mod: bump common and some other packages Change-Id: Icf73220f5182f5a2fd1431471825948c300c0bea
2020-01-07 16:09:54 +00:00
golang.org/x/sys v0.0.0-20200107144601-ef85f5a75ddf/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/sys v0.0.0-20200113162924-86b910548bc1/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/sys v0.0.0-20200116001909-b77594299b42/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
storage/boltdb: update to etcd/bbolt v1.3.4 bbolt v1.3.4 has pointer usage fixes. Change-Id: I5e0fc4782711d01c09ced579f25a4f8fbc8de85c
2020-03-24 10:33:34 +00:00
golang.org/x/sys v0.0.0-20200202164722-d101bd2416d5/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/sys v0.0.0-20200223170610-d5e6a3e2c0ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
satellite/payments: move inspector commands to satellite cli This allows to seeing logs in the output of the invoice commands. Existing ensure-stripe-customer commands is moved from the 'reports' to the new 'billing' root command. Change-Id: I752c7ab6ca59bfac8e0f174a45d2ab45fc18e467
2020-05-18 13:21:35 +01:00
golang.org/x/sys v0.0.0-20200323222414-85ca7c5b95cd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/sys v0.0.0-20200519105757-fe76b779f299/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
satellite/metainfo: Add RevokeAPIKey stub endpoint Change-Id: I07fb997dda48ea204aab11f656a1a37762684339
2020-06-16 14:03:02 +01:00
golang.org/x/sys v0.0.0-20200610111108-226ff32320da/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/sys v0.0.0-20200929083018-4d22bbb62b3c h1:/h0vtH0PyU0xAoZJVcRw1k0Ng+U0JAy3QDiFmppIlIE=
golang.org/x/sys v0.0.0-20200929083018-4d22bbb62b3c/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/text v0.3.3 h1:cokOdA+Jmi5PJGXLlLllQSgYigAEfHXJAERHVMaCc2k=
golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/time v0.0.0-20180412165947-fbb02b2291d2/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
update some packages so we don't depend on launchpad (#1644)
2019-04-02 19:43:24 +01:00
golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/time v0.0.0-20200630173020-3af7569d3a1e h1:EHBhcS0mlXEAVwNyO2dLfjToGsyY4j24pTs2ScHnX7s=
golang.org/x/time v0.0.0-20200630173020-3af7569d3a1e/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
golang.org/x/tools v0.0.0-20180221164845-07fd8470d635/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/tools v0.0.0-20180828015842-6cd1fcedba52/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
golang.org/x/tools v0.0.0-20181030000716-a0a13e073c7b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
bump to uplink v1.2.0 Also fixup config and related tests for storj.io/common bee93690ab909580993f402b594ad5a14760c39f Change-Id: I6897d925cd28b139c1fc2b43e63b08c0cc3fb688
2020-08-03 17:36:39 +01:00
golang.org/x/tools v0.0.0-20181030221726-6c7e314b6563/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/tools v0.0.0-20190114222345-bf090417da8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
golang.org/x/tools v0.0.0-20190226205152-f727befe758c/go.mod h1:9Yl7xja0Znq3iFh3HoIrodX9oNMXvdceNzlUR8zjMvY=
golang.org/x/tools v0.0.0-20190311212946-11955173bddd/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/tools v0.0.0-20190312170243-e65039ee4138/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/tools v0.0.0-20190328211700-ab21143f2384/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/tools v0.0.0-20190425150028-36563e24a262/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/tools v0.0.0-20190425163242-31fd60d6bfdc/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
golang.org/x/tools v0.0.0-20190425222832-ad9eeb80039a/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/tools v0.0.0-20190506145303-2d16b83fe98c/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
golang.org/x/tools v0.0.0-20190524140312-2c0ae7006135/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/tools v0.0.0-20190606124116-d0a3d012864b/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
golang.org/x/tools v0.0.0-20190621195816-6e04913cbbac/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
golang.org/x/tools v0.0.0-20190628153133-6cdbf07be9d0/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
golang.org/x/tools v0.0.0-20190816200558-6889da9d5479/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/tools v0.0.0-20190823170909-c4a336ef6a2f/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/tools v0.0.0-20190911174233-4f2ddba30aff/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
golang.org/x/tools v0.0.0-20191012152004-8de300cfc20a/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
golang.org/x/tools v0.0.0-20191029041327-9cc4af7d6b2c/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
golang.org/x/tools v0.0.0-20191029190741-b9c20aec41a5/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/tools v0.0.0-20191112195655-aa38f8e97acc/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/tools v0.0.0-20191125144606-a911d9008d1f/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
golang.org/x/tools v0.0.0-20200117161641-43d50277825c h1:2EA2K0k9bcvvEDlqD8xdlOhCOqq+O/p9Voqi4x9W1YU=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/tools v0.0.0-20200117161641-43d50277825c/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
golang.org/x/xerrors v0.0.0-20190410155217-1f06c39b4373/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20190513163551-3ee3066db522/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543 h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
google.golang.org/api v0.0.0-20180910000450-7ca32eb868bf/go.mod h1:4mhQ8q/RsB7i+udVvVy5NUi08OU8ZlA0gRVgrF7VFY0=
google.golang.org/api v0.0.0-20181030000543-1d582fd0359e/go.mod h1:4mhQ8q/RsB7i+udVvVy5NUi08OU8ZlA0gRVgrF7VFY0=
google.golang.org/api v0.1.0/go.mod h1:UGEZY7KEX120AnNLIHFMKIo4obdJhkp2tPbaPlQx13Y=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
google.golang.org/api v0.3.1/go.mod h1:6wY9I6uQWHQ8EM57III9mq/AjF+i8G65rmVagqKMtkk=
google.golang.org/api v0.3.2/go.mod h1:6wY9I6uQWHQ8EM57III9mq/AjF+i8G65rmVagqKMtkk=
google.golang.org/api v0.4.0/go.mod h1:8k5glujaEP+g9n7WNsDg8QP6cUVNI86fCNMcbazEtwE=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
google.golang.org/api v0.7.0/go.mod h1:WtwebWUNSVBH/HAw79HIFXZNqEvBhG+Ra+ax0hx3E3M=
google.golang.org/api v0.8.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg=
google.golang.org/api v0.9.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
google.golang.org/api v0.13.0/go.mod h1:iLdEw5Ide6rF15KTC1Kkl0iskquN2gFfn9o9XIsbkAI=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
google.golang.org/api v0.15.0/go.mod h1:iLdEw5Ide6rF15KTC1Kkl0iskquN2gFfn9o9XIsbkAI=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
google.golang.org/api v0.20.0 h1:jz2KixHX7EcCPiQrySzPdnYT7DbINAypCqKZ1Z7GM40=
google.golang.org/api v0.20.0/go.mod h1:BwFmGc8tA3vsd7r/7kR8DY7iEEGSU04BFxCo5jP/sfE=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
google.golang.org/appengine v1.1.0/go.mod h1:EbEs0AVv82hx2wNQdGPgUI5lhzA/G0D9YwlJXL52JkM=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
google.golang.org/appengine v1.2.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
google.golang.org/appengine v1.3.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
google.golang.org/appengine v1.4.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
google.golang.org/appengine v1.5.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
google.golang.org/appengine v1.6.1/go.mod h1:i06prIuMbXzDqacNJfV5OdTW448YApPu5ww/cMBSeb0=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
google.golang.org/appengine v1.6.5 h1:tycE03LOZYQNhDpS27tcQdAzLCVMaj7QT2SXxebnpCM=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
google.golang.org/appengine v1.6.5/go.mod h1:8WjMMxjGQR8xUklV/ARdw2HLXBOI7O7uCIDZVag1xfc=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
google.golang.org/genproto v0.0.0-20180817151627-c66870c02cf8/go.mod h1:JiN7NxoALGmiZfu7CAH4rXhgtRTLTxftemlI0sWmxmc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
google.golang.org/genproto v0.0.0-20180831171423-11092d34479b/go.mod h1:JiN7NxoALGmiZfu7CAH4rXhgtRTLTxftemlI0sWmxmc=
google.golang.org/genproto v0.0.0-20181029155118-b69ba1387ce2/go.mod h1:JiN7NxoALGmiZfu7CAH4rXhgtRTLTxftemlI0sWmxmc=
google.golang.org/genproto v0.0.0-20181202183823-bd91e49a0898/go.mod h1:7Ep/1NZk928CDR8SjdVbjWNpdIf6nzjE3BTgJDr2Atg=
google.golang.org/genproto v0.0.0-20190306203927-b5d61aea6440/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
google.golang.org/genproto v0.0.0-20190307195333-5fe7a883aa19/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
google.golang.org/genproto v0.0.0-20190404172233-64821d5d2107/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
google.golang.org/genproto v0.0.0-20190418145605-e7d98fc518a7/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
google.golang.org/genproto v0.0.0-20190425155659-357c62f0e4bb/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
google.golang.org/genproto v0.0.0-20190502173448-54afdca5d873/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc=
google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc=
google.golang.org/genproto v0.0.0-20190911173649-1774047e7e51/go.mod h1:IbNlFCBrqXvoKpeg0TB2l7cyZUmoaFKYIwrEpbDKLA8=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
google.golang.org/genproto v0.0.0-20191108220845-16a3f7862a1a/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
google.golang.org/genproto v0.0.0-20200115191322-ca5a22157cba h1:pRj9OXZbwNtbtZtOB4dLwfK4u+EVRMvP+e9zKkg2grM=
google.golang.org/genproto v0.0.0-20200115191322-ca5a22157cba/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
google.golang.org/grpc v1.14.0/go.mod h1:yo6s7OP7yaDglbqo1J04qKzAhqBH6lvTonzMVmEdcZw=
google.golang.org/grpc v1.16.0/go.mod h1:0JHn/cJsOMiMfNA9+DeHDlAU7KAAB5GDlYFpa9MZMio=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
google.golang.org/grpc v1.17.0/go.mod h1:6QZJwpn2B+Zp71q/5VxRsJ6NXXVCE5NRUHRo+f3cWCs=
google.golang.org/grpc v1.19.0/go.mod h1:mqu4LbDTu4XGKhr4mRzUsmM4RtVoemTSY81AxZiDr8c=
google.golang.org/grpc v1.20.1/go.mod h1:10oTOabMzJvdu6/UiuZezV6QK5dSlG84ov/aaiqXj38=
google.golang.org/grpc v1.21.0/go.mod h1:oYelfM1adQP15Ek0mdvEgi9Df8B9CZIaU1084ijfRaM=
google.golang.org/grpc v1.21.1/go.mod h1:oYelfM1adQP15Ek0mdvEgi9Df8B9CZIaU1084ijfRaM=
google.golang.org/grpc v1.23.0/go.mod h1:Y5yQAOtifL1yxbo5wqy6BxZv8vAUGQwXBOALyacEbxg=
google.golang.org/grpc v1.26.0/go.mod h1:qbnxyOmOxrQa7FizSgH+ReBfzJrCY1pSN7KXBS8abTk=
storj: remove from `storj/pkg` packages moved to `storj/private` repo * debug * traces * cfgstruct * process Package `storj/private/version` will be removed as a separate change. Change-Id: Iadc40faa782e6225513b28218952f02d9c240a9f
2020-03-23 19:18:20 +00:00
google.golang.org/grpc v1.27.0/go.mod h1:qbnxyOmOxrQa7FizSgH+ReBfzJrCY1pSN7KXBS8abTk=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
google.golang.org/grpc v1.27.1 h1:zvIju4sqAGvwKspUQOhwnpcqSbzi7/H6QomNNjTL4sk=
google.golang.org/grpc v1.27.1/go.mod h1:qbnxyOmOxrQa7FizSgH+ReBfzJrCY1pSN7KXBS8abTk=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
google.golang.org/protobuf v0.0.0-20200109180630-ec00e32a8dfd/go.mod h1:DFci5gLYBciE7Vtevhsrf46CRTquxDuWsQurQQe4oz8=
google.golang.org/protobuf v0.0.0-20200221191635-4d8936d0db64/go.mod h1:kwYJMbMJ01Woi6D6+Kah6886xMZcty6N08ah7+eCXa0=
google.golang.org/protobuf v0.0.0-20200228230310-ab0ca4ff8a60/go.mod h1:cfTl7dwQJ+fmap5saPgwCLgHXTUD7jkjRqWcaiX5VyM=
google.golang.org/protobuf v1.20.1-0.20200309200217-e05f789c0967/go.mod h1:A+miEFZTKqfCUM6K7xSMQL9OKL/b6hQv+e19PK+JZNE=
google.golang.org/protobuf v1.21.0/go.mod h1:47Nbq4nVaFHyn7ilMalzfO3qCViNmqZ2kzikPIcrTAo=
google.golang.org/protobuf v1.23.0 h1:4MY060fB1DLGMB/7MBTLnwQUY6+F09GEiz6SsrNqyzM=
google.golang.org/protobuf v1.23.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
update dependencies for bug fixes (#1993)
2019-05-19 15:58:30 +01:00
gopkg.in/alecthomas/kingpin.v2 v2.2.6/go.mod h1:FMv+mEhP44yOT+4EoQTLFTRgOQ1FBLkstjWtayDeSgw=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 h1:qIbj1fsPNlZgppZ+VLlY7N33q108Sa+fhmuc+sWQYwY=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
gopkg.in/errgo.v2 v2.1.0/go.mod h1:hNsd1EY+bozCKY1Ytp96fpM3vjJbqLJn88ws8XvfDNI=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
gopkg.in/fsnotify.v1 v1.4.7 h1:xOHLXZwVvI9hhs+cLKq5+I5onOuwQLhQwiu63xxlHs4=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
gopkg.in/fsnotify.v1 v1.4.7/go.mod h1:Tz8NjZHkW78fSQdbUxIjBTcgA1z1m8ZHf0WmKUhAMys=
all: use jackc/pgx in place of lib/pq What: Use the github.com/jackc/pgx postgresql driver in place of github.com/lib/pq. Why: github.com/lib/pq has some problems with error handling and context cancellations (i.e. it might even issue queries or DML statements more than once! see https://github.com/lib/pq/issues/939). The github.com/jackx/pgx library appears not to have these problems, and also appears to be better engineered and implemented (in particular, it doesn't use "exceptions by panic"). It should also give us some performance improvements in some cases, and even more so if we can use it directly instead of going through the database/sql layer. Change-Id: Ia696d220f340a097dee9550a312d37de14ed2044
2020-06-28 04:56:29 +01:00
gopkg.in/inconshreveable/log15.v2 v2.0.0-20180818164646-67afb5ed74ec/go.mod h1:aPpfJ7XW+gOuirDoZ8gHhLh3kZ1B08FtV2bbmy7Jv3s=
offer PostgreSQL storage for pointerdb (#440) ..although it ought to work for other storage.KeyValueStore needs as well. it's just optimized to work pretty well for a largish hierarchy of paths. This includes the addition of "long benchmarks" for KeyValueStore testing. These will only be run when -test-bench-long is added to the test flags. In these benchmarks, a large corpus of paths matching a natural ("real-life") hierarchy is read from paths.data.gz (which you can get from https://github.com/storj/path-test-corpus) and imported into a particular KeyValueStore. Recursive and non-recursive queries are run on it to detect performance problems that arise only at scale. This also includes alternate implementation of the postgreskv client, which works in a less-bizarre way for non-recursive queries, but suffers from poor performance in tests such as the long benchmarks. Once this alternate impl is committed to the tree, we can remove it again; I just want it to be available for future reference.
2018-10-25 18:11:28 +01:00
gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
gopkg.in/ini.v1 v1.51.0 h1:AQvPpx3LzTDM0AjnIRlVFwFFGC+npRopjZxLJj6gdno=
gopkg.in/ini.v1 v1.51.0/go.mod h1:pNLf8WUiyNEtQjuu5G5vTm06TEv9tsIgeAvK8hOrP4k=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
gopkg.in/resty.v1 v1.12.0/go.mod h1:mDo4pnntr5jdWRML875a/NmxYqAlA73dVijT2AXvQQo=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 h1:uRGJdciOHaEIrze2W8Q3AKkepLTh2hOroT7a+7czfdQ=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw=
cmd/uplink: use scopes to open (#2501) What: Change cmd/uplink to use scopes It moves the fields that will be subsumed by scopes into an explicit legacy section and hides their configuration flags. Why: So that it can read scopes in from files and stuff
2019-08-05 18:01:20 +01:00
gopkg.in/yaml.v2 v2.0.0-20170812160011-eb3733d160e7/go.mod h1:JAlM8MvJe8wmxCU4Bli9HhUf9+ttbYbLASfIpnQbh74=
Restore go.sum (#432)
2018-10-06 18:57:53 +01:00
gopkg.in/yaml.v2 v2.2.1/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
update golang.org/x packages and grpc (#1363)
2019-02-26 15:49:56 +00:00
gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
all: use monkit v3 this commit updates our monkit dependency to the v3 version where it outputs in an influx style. this makes discovery much easier as many tools are built to look at it this way. graphite and rothko will suffer some due to no longer being a tree based on dots. hopefully time will exist to update rothko to index based on the new metric format. it adds an influx output for the statreceiver so that we can write to influxdb v1 or v2 directly. Change-Id: Iae9f9494a6d29cfbd1f932a5e71a891b490415ff
2019-11-08 20:40:39 +00:00
gopkg.in/yaml.v2 v2.2.4 h1:/eiJrUcujPVeJ3xlSWaiNi3uSVmDGBK1pDHUHAnao1I=
gopkg.in/yaml.v2 v2.2.4/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
gopkg.in/yaml.v2 v2.3.0 h1:clyUAQHOM3G0M3f5vQj7LuJrETvjVot3Z5el9nffUtU=
gopkg.in/yaml.v2 v2.3.0/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
go.mod: bump dependencies Change-Id: I2b1bf014a60ef6ddc4b1b546f58393c34ffe22fc
2020-09-29 11:00:20 +01:00
gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c h1:dUUwHk2QECo/6vqA44rthZ8ie2QXMNeKRTHCNY2nXvo=
gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
gotest.tools v2.2.0+incompatible h1:VsBPFP1AI068pPrMxtb/S8Zkgf9xEmTLJjfM+P5UIEo=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
gotest.tools v2.2.0+incompatible/go.mod h1:DsYFclhRJ6vuDpmuTbkuFWG+y2sxOXAzmJt81HFBacw=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
grpc.go4.org v0.0.0-20170609214715-11d0a25b4919/go.mod h1:77eQGdRu53HpSqPFJFmuJdjuHRquDANNeA4x7B8WQ9o=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
honnef.co/go/tools v0.0.0-20180728063816-88497007e858/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
Take advantage of Is and IsFunc from zeebo/errs (#2310)
2019-06-26 08:38:07 +01:00
honnef.co/go/tools v0.0.0-20190102054323-c2f93a96b099/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
satellitedb: separate migration into subcommand (#3436) * separate sadb migration, add version check * update checkversion to do same validation as migration * changes per CR * add sa migration to storj-sim * add different debug port in storj-sim for migration * add wait for exit for storj-sim migration * update sa docker entrypoint to support migration * storj-sim satellite parts all wait for migration * upgrade golang-migrate/migrate to v4 because bug * fix go mod tidy
2019-11-02 20:09:07 +00:00
honnef.co/go/tools v0.0.0-20190106161140-3f1c8253044a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
honnef.co/go/tools v0.0.0-20190418001031-e561f6794a2a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
private/processgroup: moved to storj.io/common/processgroup Change-Id: I1ec0bb440dda757d8f9a6f564a0084dde2f9cc84
2020-03-03 09:31:51 +00:00
honnef.co/go/tools v0.0.0-20190523083050-ea95bdfd59fc/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
libuplink: return deleted bucket/object (step 4) Switch back to the original DeleteBucket and DeleteObject methods. Next step: remove the DeleteBucketReturnDeleted and DeleteObjectReturnDeleted from storj.io/uplink. Change-Id: I273a305326d411e51ce354ce72fcc6ecadf4dd5f
2020-03-19 11:18:34 +00:00
honnef.co/go/tools v0.0.1-2019.2.3 h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM=
pkg/process: Now that we are trying to identify the root cause of the satellite load limitations (i.e. currently the satellite has a max ability of 400 rps for uploads and we need this to be higher), we are using the golang diagnostic tools to collect insight into what the bottlenecks are. We currently have a debug endpoint to gather some cpu and mem data, but it could be useful to have continuous profiling. GCP stackdriver has support for continuous profiling so lets set that up and see if it is helpful to gather more data. This PR adds support for [GCP continuous profiler](https://cloud.google.com/profiler) which allows enabling continuous cpu/mem profiling and the stats are sent to stackdriver in google cloud console. To enable the continuous profiling for a storj component, do the following: - prereq: the workload must be running in GKE and have Stackdriver Profiling IAM role permissions - provide the config flag `debug.profilename` in the config.yaml file for the workload (i.e. satellite api process, etc). The profilename should be the workload name, for example "satellite-api". - once the above config flag is provided, the profiler will be initialized and profiling stats will automatically be sent to GCP project where the workload is running and viewable in the Stackdriver Profile page in the console The current implementation assumes the workload is running in GKE, however if we find if useful we can add support to enable this from anywhere. But for simplicity, its configured this way assuming the main goal is to enable in production systems. Change-Id: Ibf8ebe2df7bf06fdd4951ee6a1e48854dd36ad47
2020-02-25 16:46:12 +00:00
honnef.co/go/tools v0.0.1-2019.2.3/go.mod h1:a3bituU0lyd329TUQxRnasdCoJDkEUEAqEt0JzvZhAg=
rsc.io/binaryregexp v0.2.0/go.mod h1:qTv7/COck+e2FymRvadv62gMdZztPaShugOCi3I+8D8=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
rsc.io/quote/v3 v3.1.0/go.mod h1:yEA65RcK8LyAZtP9Kv3t0HmxON59tX3rD+tICJqUlj0=
rsc.io/sampler v1.3.0/go.mod h1:T1hPZKmBbMNahiBKFy5HrXp6adAjACjK9JXDnKaTXpA=
sourcegraph.com/sourcegraph/go-diff v0.5.0/go.mod h1:kuch7UrkMzY0X+p9CRK03kfuPQ2zzQcaEFbx8wA8rck=
sourcegraph.com/sqs/pbtypes v0.0.0-20180604144634-d3ebe8f20ae4/go.mod h1:ketZ/q3QxT9HOBeFhu6RdvsftgpsbFHBF5Cas6cDKZ0=
cmd/uplink: use tracing.enabled flag Previously we are using tracing.sampled to be the switch for turning on/off tracing. However we would like to separate sampling rate from being the switch, so we can set sampling rate to be 0 but still intialize tracing for satellite and storagenodes Change-Id: I27e6ba25ea6f6b612b4e1a57cf1301889ded41ec
2020-04-24 19:09:59 +01:00
storj.io/common v0.0.0-20200424175742-65ac59022f4f/go.mod h1:pZyXiIE7bGETIRXtfs0nICqMwp7PM8HqnDuyUeldNA0=
mod: bump dependencies Change-Id: I61beaf9793609f7614478cfa604b2721d9010b52
2020-10-30 14:17:55 +00:00
storj.io/common v0.0.0-20201026135900-1aaeec90670b/go.mod h1:GqdmNf3fLm2UZX/7Zr0BLFCJ4gFjgm6eHrk/fnmr5jQ=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
storj.io/common v0.0.0-20201106104920-372a344bdd45 h1:pv552R7MiRA8VLQC4qXczLjbl2Qb/MNyus2E9NBSXgI=
storj.io/common v0.0.0-20201106104920-372a344bdd45/go.mod h1:ZkQZup2jpFZvvTgz+yPc7K4Vr4bBHM8AA66P57MZkjk=
bump storj.io/common to latest and storj.io/drpc to v0.0.11 Change-Id: I7a6e823b441eeff4621dfdf2d6577be76c9761c8
2020-03-24 17:49:20 +00:00
storj.io/drpc v0.0.11/go.mod h1:TiFc2obNjL9/3isMW1Rpxjy8V9uE0B2HMeMFGiiI7Iw=
satellite: Check macaroon revocation When a request comes in on the satellite api and we validate the macaroon, we now also check if any of the macaroon's tails have been revoked. Change-Id: I80ce4312602baf431cfa1b1285f79bed88bb4497
2020-06-03 14:51:02 +01:00
storj.io/drpc v0.0.11/go.mod h1:TiFc2obNjL9/3isMW1Rpxjy8V9uE0B2HMeMFGiiI7Iw=
mod: bump drpc Change-Id: I584a2f55a391ce26e9fb1675e9f8a678febe649f
2020-07-28 15:47:51 +01:00
storj.io/drpc v0.0.14 h1:GCBdymTt1BRw4oHmmUZZlxYXLVRxxYj6x3Ivide2J+I=
storj.io/drpc v0.0.14/go.mod h1:82nfl+6YwRwF6UG31cEWWUqv/FaKvP5SGqUvoqTxCMA=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
storj.io/drpc v0.0.16 h1:9sxypc5lKi/0D69cR21BR0S21+IvXfON8L5nXMVNTwQ=
storj.io/drpc v0.0.16/go.mod h1:zdmQ93nx4Z35u11pQ+GAnBy4DGOK3HJCSOfeh2RryTo=
script/testdata: update tracing agent default address Change-Id: I730994f16f135c4b8643a52f4cf499487e4af326
2020-06-03 21:19:35 +01:00
storj.io/monkit-jaeger v0.0.0-20200518165323-80778fc3f91b h1:Bbg9JCtY6l3HrDxs3BXzT2UYnYCBLqNi6i84Y8QIPUs=
storj.io/monkit-jaeger v0.0.0-20200518165323-80778fc3f91b/go.mod h1:gj4vuCeyCRjRmH8LIrgoyU9Dc9uR6H+/GcDUXmTbf80=
mod: bump dependencies Change-Id: I61beaf9793609f7614478cfa604b2721d9010b52
2020-10-30 14:17:55 +00:00
storj.io/private v0.0.0-20201026143115-bc926bfa3bca h1:ekR7vtUYC5+cDyim0ZJaSZeXidyzQqDYsnFPYXgTozc=
storj.io/private v0.0.0-20201026143115-bc926bfa3bca/go.mod h1:EaLnIyNyqWQUJB+7+KWVez0In9czl0nHHlm2WobebuA=
mod: bump dependencies and reenable test We shouldn't have any EOF issues with recent drpc fix, let's reenable and see whether it's still flaky. Change-Id: I0de312bcb087c7f70ec9d3281d73d86f971845d5
2020-11-09 11:41:20 +00:00
storj.io/uplink v1.3.2-0.20201106105834-ec8e5cc29f7e h1:a58hzcYciTvBtWST+Byoj76NWuYdnPcz2GK8ynyEyfA=
storj.io/uplink v1.3.2-0.20201106105834-ec8e5cc29f7e/go.mod h1:mrdt4I4EhPRC7cnvCD5490IBm423pgKrVoUiC9a5Srg=
Reference in New Issue Copy Permalink