Satellites[0].GCBF is already started when testplanet boots up,
so calling Run separately ends up causing a data race.
Instead create a new instance, that should avoid this issue.
Fixes https://github.com/storj/storj/issues/6435
Change-Id: I6603ef63da7a6ab8bdb952cf5aaca17eb0392e2c
This condenses the precommit constraint into a single function, which
allows to cleanup a bunch of logic elsewhere. Also, avoid delete in the
first place when we are not allowed to remove the uncommited object.
This also fixes submitting the metrics and now it submits the correct
metrics.
Change-Id: If91dfa3b19bce5b24ff2a19d7c34b57a200db1dd
This change adds an endpoint to the admin API and UI to get a list of
users pending deletion and have no unpaid invoice.
Issue: #6410
Change-Id: I906dbf9eee9e7469e45f0c622a891867bf0cc201
This change migrates Vue components of the new satellite admin web app
from the options API to the composition API.
Change-Id: Ie8c9bcd468f1c0fe0abc9ef0a3724563db096ba9
We need to update metainfo GetObject endpoint to use ObjectVersion
([]byte) field instead of old Version field (int32).
Change-Id: I61663ec8d9f5c731f91346a285048477fb493730
This change introduces a new endpoint that allows adding credit cards
by payment method ID (pmID). The payment method would've already been
created by the frontend using the stripe payment element for example.
Issue: #6436
Change-Id: If9a3f4c98171e36623607968d1a12f29fa7627e9
Using a an empty stream id makes it more difficult to target a specific
delete marker. Similarly, we don't want to confuse actual stream id-s
with normal ones. So, we'll create stream id-s where the first few bytes
are 0xFF, but the rest is random.
Change-Id: Ia7fffb0da9a071be2935df99c0846027ee2e03c3
This change lints files for the new satellite admin web app. An
ESLint config has been added for it that is identical to the one used
for linting satellite web app files.
Change-Id: I66f72fb880d5cbc80b6c080294e4a830b3d28143
This changes metabase behavior such that the latest object
will be the committed object which may result in a new version
assigned to the objects.
Change-Id: I7a731d7db4696caba75fff65107a248569b6111f
This change speeds up the build of the new satellite admin web app
using the same method that 8b0d25c used to speed up the build of the
new satellite web app.
New build time: 23.394s
Old build time: 1m40.930s
Change-Id: Ic6fcfdfc73b78bc26bddc421c608076b23532967
Currently it's awkward to use any of the existing statuses for the
objects in non-recursive listing. Hence, let's add a new one.
Change-Id: I8485e0f858e69998b097e757091991538ca697fa
We never extended metainfo protocol to return committed object
detailed into and this change is doing it now. Main motivation to
do this now is need for providing object version after upload.
Change-Id: Ib59bdfd9485e4a0091ac02458cc63427cb7159de
This is fixing two small issues with logging:
* repair checker was logging empty last net values as clumped pieces
but in main logic we stopped classifying it this way
* repairer summary log was showing incorrect number of pieces removed
from segment because list contains duplicated entries
There was no real issue here.
Change-Id: Ifc6a83637d621d628598200cad00cce44fa4cbf9
Removed AllProjectDashboard feature flag.
Removed unused Vue components.
Fixed wrong redirect on reload if pricing packages are disabled.
Fixed wrong redirect on reload if billing features are enabled.
Issue:
https://github.com/storj/storj/issues/6434
Change-Id: I9081a6f737c45fb48da5b23c016a42e23021c4ce
Protobuf definition is ready to support deleting specific version of
object so we just need to wire requested version into metainfo
BeginDeleteObject endpoint.
Dependencies bumped to get latest metainfo protobuf definition.
https://github.com/storj/storj/issues/6221
Change-Id: Ifc3cc0b49d9acdf4f7e57e7184b0f2ae045f9113
A randomly generated UUID can hit something that starts with `00`.
Also fix a tiny mistake in the comment.
Change-Id: I25a8b21e0f9523bc486e5a38b0c3cc9c36515231
Use `(a, b, c) = ($1, $2, $3)` for the object stream location
arguments rather than combining multiple AND queries together.
Using a tuple comparison is shorter and also easier to see which
object is selected.
Change-Id: Iba84b89630d57255023c30e309eb6afaee9ab944
Add the DB schema changes and basic implementation methods to support
bucket level configuration of object versioning.
See bucket-level-versioning-configuration design doc for more details.
Change-Id: I4e920a20a403b3157970a34eb619d827a4007845
Today we got the following error address, even if: `mail.auth-type: nomail`
```
Error: SMTP server address '' couldn't be parsed: missing port in address
```
It's make more sense to print the error message only if the SMTP address (or from address) is expected.
Change-Id: Ie07620099b6aac27630fcfd1cda9921ef4b6060c
This change updates account freeze to set and use the days till
escalation column of the account freezes table.
Issue: #6382
Change-Id: I345798e3d53e5ab4a7653723433fb8affa258212
This change ensures that the user is never prompted to upgrade when
attempting to invite project members if billing features are configured
to be disabled.
Change-Id: I1c49351b00c0e378da24ad080fd1d3b078c97c71
This change adds a flag to the satellite config indicating whether
free tier users should be able to send project invitations.
Change-Id: I9c030c88dbef136ba4a9bf2d8f027a8dcd77fd33
This will allow further progress towards S3-compatible object
versioning.
Refs: https://github.com/storj/storj/issues/6352
Change-Id: I0b3aa93fcacd1f9d91a667d619d6cb41fba602a9
Since we no longer need the type column and hopefully,
there are no queries using it, we recreate all indices
that reference the nodes.type column.
Updates https://github.com/storj/storj/issues/5426
Change-Id: I610ccaf474a6f4031e166b79a6d649c4b138e338
This change fixes data races in tests for the account freeze chore
caused by the chore service being set while in use.
Change-Id: Ibcb94a947c405314deae0d77419e69b768feab40
Once this is merged and deployed, we can go ahead
and change the db schema.
Note that this will stop updating the `type` column in the nodes
table but it shouldn't be a problem because this column has a
default value set.
Updates https://github.com/storj/storj/issues/5426
Change-Id: I2470ebacbcb0e60cf894617eb69b593227357283
This change adds a new column to the account_freeze_events table,
days_till_escalation, which is the number of days till the freeze event
is escalated. E.g.: 30 days from billing warning event to billing
freeze event.
Issue: #6382
Change-Id: I15cfd6f1208e641d8c380bef61717031befdad73
To get better performance, we pre-load all nodealias/node information at the beginning of the segment loop.
It's possible that we receive a new node alias from the segment table what we are not fully aware of (yet).
The easiest solution is just ignoring. New risks/threats can be detected by a new execution cycle.
Change-Id: Ib54f7edc46eedbab6d13b4d651aaac1425994940
Added client side logic to disable billing features depending on config value.
Disabled billing endpoints if billing is disabled.
Issue:
https://github.com/storj/storj-private/issues/464
Change-Id: I6e70dc5e2372953b613ddab9f19cb94f008935ce
The overlay.NodeDossier struct only tracks information about a
storagenode, the field is deprecated and no longer needed.
This is a kademlia left-over.
Updates https://github.com/storj/storj/issues/5426
Change-Id: Ie278ffd88d1b9a9fde6c81eb5f0e287bab8c9ef0
`overlay.NodeDossier` contains information that satellite tracks
about a storagenode.
As part of the work to remove the type column from the nodes
table https://github.com/storj/storj/issues/5426, we would have
to remove the `Type` field in the `overlay.NodeDossier` since it
is only about the storagenode.
The `Local` method on the contact service is also removed because
it is unused. When needed we can create a seperate `SatelliteInfo`
struct which the `Local` method will return.
Change-Id: If0c1a25d9df397a9492bbf1d7f33ba5b6a918878
This change limits payment attempts to
1. Card updates when billing frozen/warned
2. Right before billing freezing a warned account.
Issue: https://github.com/storj/storj-private/issues/457
Change-Id: Ic6d5c649cdac38d5c3b7365e20a4ceb3b6199ee8
This change adds a flag to the satellite config indicating whether
unregistered email addresses should receive project invitation emails.
Change-Id: I0396f25574ddae3f9adaea32a6e7cd15b931bf12
This change prevents multiple project invitation records from being
created from a single API request.
Change-Id: I01268fcc0e2f7b5f24870b032cb53f03c7ad0800
While the index shouldn't be necessary as long as our implementation is
correct, it still provides some additional checks for mistakes in the
implementation.
Change-Id: I7ed71ac99a979e375d7f94c8898e6f83ac623cb6
By using a separate function for deleting the latest object and
fetching the latest version we can simplify some of the code.
However, there can be more performant approaches, such as using
ON CONFLICT for updating the existing object or using select and delete
in the same query in databases that support it.
Change-Id: I52bc3f9fa025f44d05ee010723ffb81f5bd2a2d7
Allow user to download detailed usage report from Billing -> Overview screen.
Report is a CSV file containing usage data for all the projects user owns.
Issue:
https://github.com/storj/storj/issues/6154
Change-Id: I3109002bf37b1313652a2be3447aaa7bc6204887
There are several different object types in a versioned table,
which will determine the exact behaviour.
The object type states are:
* Pending - the object is yet to be committed and is being uploaded.
* Committed - the object has been finished and can be read.
* DeleteMarker - indicates that the object should be treated as not
present when is at the top of the version stack.
There are also versioning states:
* Unversioned - only one unversioned object is allowed per object key.
* Versioned - multiple objects with the same key are allowed.
Change-Id: I65dfa781e8da253a4e5d572b799d53c351196eee
I believe that this change in semantics won't break anything, because
ListVerifySegments is only used by cmd/tools/segment-verify (which only
needs to operate on non-expired segments) and various tests, none of
which expect ListVerifySegments to include expired segments.
Change-Id: I037f43b16bc5750ed914bc32949418e001df1a8c
This change adds user ID rate limiting to the endpoint responsible for
sending project invitations.
Resolves storj-private#462
Change-Id: Icf0be7d7bb7f2765725ba3e152a2195bc02484e2
ClassifySegmentPieces uses custom set implementation instead map.
Side note, for custom set implementation I also checked int8 bit set but
it didn't give better performance so I used simpler implementation.
Benchmark results (compared against part 2 optimization change):
name old time/op new time/op delta
RemoteSegment/healthy_segment-8 21.7µs ± 8% 15.4µs ±16% -29.38% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
RemoteSegment/healthy_segment-8 7.41kB ± 0% 1.87kB ± 0% -74.83% (p=0.000 n=5+4)
name old allocs/op new allocs/op delta
RemoteSegment/healthy_segment-8 150 ± 0% 130 ± 0% -13.33% (p=0.008 n=5+5)
Change-Id: I21feca9ec6ac0a2558ac5ce8894451c54f69e52d
Given the placement.txt with the content:
```
9:exclude(placement(10))
10:country("DE")
```
Without patch:
```
placement-test --placement=/tmp/placement.txt countrycode=DE
Error: type mismatch: reflect: Call using zero Value argument
```
With the patch:
```
placement-test --placement=/tmp/placement.txt countrycode=DE
Error: Error in line 'exclude(placement(10))' when placement rule is parsed: Placement 10 is referenced before defined. Please define it first!
```
Change-Id: I9ad81016d4a57fdb32f3ff9031b5591f9a7cd2a6
It would appear that we have been making concurrent accesses to
statsCollector for a long, long time (we expect there to be multiple
calls to `Repair()` at the same time on the same instance of
`SegmentRepairer`, up to `config.MaxRepair`, and before this change
there was no sort of synchronization guarding accesses to the
`statsCollector.stats` map.
Refs: https://github.com/storj/storj/issues/6402
Change-Id: I5bcdd13c88913a8d66f6dd906c9037c588960cc9
This change incorporates the UI type (legacy or Vuetify) in the
properties attached to analytics events originating from the satellite
UI.
Resolves#6363
Change-Id: Ie3627bc24e4349407376e28460a5a830d211b47b
This change adds two new admin endpoints to freeze users for ToS
violation and to remove them from that state,
Issue: https://github.com/storj/storj-private/issues/386
Change-Id: I49c922377c9cdb315ce2777fcd35dcad432b0539
Optimizing collecting monkit metrics:
* initialize metrics once at the begining
* avoid using string in map for getting stats structs per redundancy
Benchmark results (compared against part 1 optimization change):
name old time/op new time/op delta
RemoteSegment/Cockroach/healthy_segment-8 31.4µs ± 6% 21.7µs ± 8% -30.73% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
RemoteSegment/healthy_segment-8 10.2kB ± 0% 7.4kB ± 0% -27.03% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
RemoteSegment/healthy_segment-8 250 ± 0% 150 ± 0% -40.00% (p=0.008 n=5+5)
Change-Id: Ie09476eb469a4d6c09e52550c8ba92b3b4b34271
This change extends the account freeze functionality account for
violation freezes as well.
Also, debug level logs in the freeze chore have been changed to info.
It adds an analytics event for when an invoice is found that belongs to
a user frozen for violation.
And finally adds whether a user is frozen for violation to the
/account/freezestatus response.
Issue: https://github.com/storj/storj-private/issues/386
Change-Id: Id8e40282dc8fd8f242da52791ab8ddbbef3da2bc
Account freeze excludes accounts who have invoices which are unpaid and
are above a configured value. This change updates that configured value
from $100 to $1000.
Change-Id: Iff381deeb73ef2d8fccaf7a1612a33e8aeb08698
Add billing commands to manually complete or fail storjscan invoice
payments that are stuck in a pending state.
Change-Id: Ia19f0a2597201d9d17aad0889eaedff095d706b9
The API generators rely on the Name and Prefix fields of the
EndpointGroup type to generate code.
Conventional naming code requires using upper or lower case for types,
functions, etc, however requiring the user to set this fields with the
correct casing seems cumbersome for them because they can be adjusted
depending where those values are used on the generated code.
This commit lifts the restriction for the user and adjust the casing of
them according to where they are used.
Change-Id: I700a879d13b4789b4d6ba0519b4d7508061eac73
the existing test was missing a case where deleting the geofencing
should set the placement back to default.
this also changes EveryCountry to DefaultPlacement, as the former is
deprecated.
Change-Id: I29f4f1c3ae1d05e8f5ecaa03a70ac4f17574a475
deleteGeofenceForProject wasn't able to work correctly, because
Console().Projects().Update() declines to update default_placement when
the input value is 0.
This introduces a Console().Projects().UpdateDefaultPlacement() method,
congruent to the method of the same name on Console().Users().
deleteGeofenceForProject now uses this new method, so that specifying a
new placement of 0 will work correctly.
Change-Id: I4589b36707f7e4f1cfdc66543520b0d4205c1a84
