* docs/testplan: Testplan for Automatic Account Freeze-Unfreeze
This testplan is going to cover the new account Freeze/Unfreeze. It will go over the automatic-account-freeze design doc found under docs/blueprints.
* Update automatic-account-freeze-unfreeze.md
Co-authored-by: Antonio Franco (He/Him) <antonio@storj.io>
Add document outlining the design and implementation steps for the paid
tier TLS feature.
https: //github.com/storj/storj/issues/5296
Change-Id: I51f68fc7890f816cef7bf2a319762ad701bac445
This change updates the automatic account freezing/unfreezing blueprint
to account for new feedback and changes in the implementation process.
Change-Id: If1a478d961b67aa4a946793168a7f525e06bb9e7
This testplan is going to cover the changes to storage-node email notifications. It will go over the storage-node email notification design doc.
Co-authored-by: Antonio Franco (He/Him) <antonio@storj.io>
This blueprint describes a way to allow user accounts to be
automatically restricted after failing to pay and unrestricted after
payment has been collected.
Change-Id: I4b64eb8ef6bf83603be7ad7d7bcb78f2d885c2a4
and clarify some related implementation details.
Most notably, this change clarifies that the verification audit workers
and reverification audit workers are meant to live in a process or
processes separate from the satellite core, and outlines an extra queue
that will be used for communication with the core.
It's not entirely clear to me that this is the right approach; we would
save some fairly significant implementation time by leaving both types
of worker in the core. That would make it necessary to reconfigure and
restart the core when we wanted to change the number of verification
and/or reverification workers, and scaling would be limited to the
computational capacity of the core vm, but maybe those are acceptable
conditions.
Another option would be to leave the Verifier workers in the core, and
having a separate process for Reverifiers. That would be sort of a
middle way between the two above.
Change-Id: Ida12e423b94ef6088733b13d5cc58bdb78f2e93f
* docs/testplan: Adding a testplan for Token Payment Processor
This testplan is going to cover the token payment processor, it will go over must haves and additional features that we can add on later.
* docs/testplan: Adding a testplan for Token Payment Processor
Updated final testplan for review
* docs/testplan: Adding a testplan for Token Payment Processor
Removed unnecessary tests related to mempool scanning
* Update token-payment-processor-testplan.md
Co-authored-by: littleskunk <jens.heimbuerge@googlemail.com>
New blueprint describes a design which provides the satellite greater
control over sessions authorized to use the web app.
Change-Id: I5af227aef6d6b096167e2e8a60f1e8214c2cd71f
* This commit stubs out the test plan for fuzz testing.
* pushing small change before rebasing.
* This commit implements a rough draft of our security tests, most importantly fuzz tests.
* Moving testplan up a directory and renaming to indicate executive summary.
* Cleaning out fuzzing tests from cmd/uplink,
* updates to tools list
This change adds a blueprint outlining the renovation of the
current API system including guidelines for API code generation.
Change-Id: I5560cc8642eee44842829ecddf205886cd5b13f2
Added a testplan folder in docs, with a README and TEMPLATE for testplan
We want community involvement with testplans, since we believe that testplans written as early as possible before implementation starts work like a checklist and as soon as we finish the implementation we can compare it to the test plan to check for any bugs. Also even before implementation is finished, if a developer can read a test plan beforehand they can prevent most bugs, hence why we believe that the earlier we write a test plan the more bugs we can prevent.
Co-authored-by: Igor <38665104+ihaid@users.noreply.github.com>
Instead of having a guide for only the sno development, we need a main contributing guide which will show up when a contributor visits https://github.com/storj/storj/contribute.
Change-Id: I4477c3c124ad0d15b17b4733304333179f3d4084
* docs: update graceful exit refactoring doc
Co-authored-by: paul cannon <thepaul@storj.io>
Co-authored-by: Jennifer Li Johnson <jennifer@storj.io>
Co-authored-by: Maximillian von Briesen <mobyvb@gmail.com>
Trusted Delegated Repair is performing repair on trusted servers outside
the network boundary of the satellite.
Change-Id: I13b0e6f53100cefcb89c0c77bd1421c549551ab7
This change adds two new tables to process orders as fast as we used
to but in an asynchronous manner and with hopefully less storage
usage. This should help scale on cockroach, but limits us to one
worker. It lays the groundwork for the order processing pipeline to
be queue rather than database driven.
For more details, see the added fast billing changes blueprint.
It also fixes the orders db so that all the timestamps that are
passed to columns that do not contain a time zone are converted to
UTC at the last possible opportunity, making it less likely to use
the APIs incorrectly. We really should migrate to include timezones
on all of our timestamp columns.
Change-Id: Ibfda8e7a3d5972b7798fb61b31ff56419c64ea35
