I introduced some subtle linter issues when I added the APIError class
and added the TypeScript mock generator.
This commit addresses them, so the linter doesn't yell about the
TypeScript generated sources.
Change-Id: Icc7dfa4169a228b1a5144d4a292f4350ee5ef9f0
We introduced some changes in 882c9d64e4
and one reviewer spot an issue which was fixed, but I forgot to
regenerate the files and the generated Typescript client got stale.
This commit regenerate the example code, so the generated code is align
with the current generator version.
Change-Id: Idc023adc9c6e230578f9e77e492126355b006203
Currently Windows seems to dislike creating udp servers in a very
fast fashion. Add an environment flag that allows to disable quic,
which is the main culprit.
Individual tests can still override that setting.
Change-Id: I3b30c4aa7fcb148b2894335394fdfae6eaa372bb
Implement a TypeScript client mock generator to generate mocks with
static data specified in the API definition.
Change-Id: I11419f4bbf72576fcd829f9d4acd8471034ca571
Create a class that inherits the Javascript Error class to use it when
throwing errors on the TypeScript client when the ok property of the
Fetch API Response object is false, which means that the server
responded with a status code less than 200 or greater than 299.
The APIError class contains apart of the message, the response status
code which may be useful for the caller to decide what to do, for
example, it may decide to retry the call on certain response status
errors.
Change-Id: Ic48466b40cbf134a27d5c92a4af9f93232e84fca
This change fixes an issue where the TypeScript API code generator
would silently fail to generate class definitions for named structs
used as the element type of array or slice struct fields.
This issue caused invalid TypeScript code to be generated from the
frontend config struct because it contained a slice of partnered
satellite structs. The TypeScript class definition of the frontend
config referenced the nonexistent partnered satellite class.
The satellite frontend config uses, so this issue caused the
Change-Id: Idfcb6ec1bbc603a43033ee4afb5b421b7454855c
The Go generator only supports certain types as query and path
parameters and it panics on any an unsupported type.
The Document and TypeScript generator don't have any validation for
them. TypeScript generator generates code that compiles, however, it
won't work properly with all the types not supported by the Go
generator.
Because it doesn't make sense that some types may work on the TypeScript
generator, while the Go generator doesn't, doing the validation in the
Param constructor is better because it reports the issue without having
to run the Go generator and it gives a more understanding panic message.
TypeScript generator generates code that works properly with all the
types supported by the Go generator, hence, there isn't any change int
he TypeScript generator in this commit.
Change-Id: I03085283942a98341726a1560f511a46540df9f5
The TypeScript generator create types of anonymous structs. When those
anonymous structs are in endpoints with the same name, but in different
endpoint groups, the generator panic because it create different types
with the same names.
This commit fixes that problem through using the endpoint group prefix
to create the types with different names.
Change-Id: Ibe87532609ce824b80951326f9777ed5b0cc2f7a
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
Fix the TypeScript generator to generate code using the common
TypeScript conventions.
Closes https://github.com/storj/storj/issues/6360
Change-Id: I244896feea389670eca0df95d3ac58e25d600e14
We cannot map certain types to TypeScript, hence we verify them in the
Endpoint.Validate method.
Even some types could be somehow mapped, we don't want to add more
complexity or allow types that don't make sense to be for a request or
response.
Change-Id: I51ecee286e637b1160e967d77f9ce6c7403ddfdc
Rename the Endpoint fields MethodName and RequestName because they were
confusing for what they are used.
This commit also adds some validations for these fields values and other
validations for Endpoint and EndpointGroup to avoid generating invalid
code.
It also include some tests for these new validations.
Closes https://github.com/storj/storj/issues/6333
Change-Id: Iaabfc33935517889e3729c8b37be51a55eea366c
The TypesScript generator generates classes and checks for Go struct
field if the struct type is of a nullable type, however, it should check
if the field types is nullable because it doesn't make sense to check
that struct field for each field nor to assign to the field if it's
nullable or not depending on it.
Change-Id: Ia22a609a17752f520233c006cba17685fe142b32
Fix the API generator to generate valid TypeScript code when using
slices an arrays of any type (base types, struct types, anonymous struct
types, etc.).
Closes https://github.com/storj/storj/issues/6323
Change-Id: I580ae5305c58f65c2e4f4a35d14ca4ee509a9250
The API generator was generating invalid code when types were defined in
a main package because the generated Go code was defining in import from
it.
This commit update the Go generator to panic with a explicit error
message if that situation happens.
The commit also add a new endpoint to the example with a named types
(i.e. no anonymous) to show that the Generator works fine with them.
Change-Id: Ieddd89c67048de50516f7ac7787d602660dc4a54
The API generator didn't generate valid TypeScript code when using
Go anonymous types.
This commit fixes that issue creating names for anonymous types.
Change-Id: Ice0748d8650686e3d3979523b8f218dc20eade5a
Add a few validations to panic with a nicer message or abort rather than
generating invalid code.
Also improve the panic message wrapping a standard error with errs2 at
the time that it's returned.
Change-Id: I1393933eb5f0bc3f86646bf4d0acfc64626efbe0
Add a test for Types.All method because we may need to adjust the logic
in future commits and we want to detect what has changed for good or
bad.
Change-Id: I1db4bf67db3c87513cb9aeb7b942c6c132fc4dd1
Detects whether or not TCP fastopen is supported by running sysctl to
grab the current value of net.inet.tcp.fastopen.server_enable.
If not enabled, directs the operator to use sysctl to set it temporarily
and /etc/sysctl.conf to set it on-boot.
Setting the socket option always works whether it is enabled or not.
Verified that fastopen works on FreeBSD 13. Did not attempt on earlier
versions but support has been there since FreeBSD 10.
Change-Id: I2e0c457558a6fa7b7a1b18bc3c6684aff50b81a2
Implements tryEnableFastOpen by creating a localhost socket and enabling
the TCP_FASTOPEN socket option. On builds where TCP_FASTOPEN isn't
available, setting the socket option fails and tryEnableFastOpen returns
false.
This was verified on a supporting build (latest Windows 10) and an
unsupporting build (Windows 8.1, couldn't find an ISO for an older
Windows 10 build).
Change-Id: I497117dc2f04acdd2b0cc836e20d12d69076b939
as GetParticipatingNodes and GetNodes, respectively.
We now want these functions to include offline and suspended nodes as
well, so that we can force immediate repair when pieces are out of
placement or in excluded countries. With that change, the old names no
longer made sense.
Change-Id: Icbcbad43dbde0ca8cbc80a4d17a896bb89b078b7
The old way did not properly handle escaping, e.g. if the value of a
query param contained `&` or `=` inside it. By using
url.searchParams.set, we can safely add these types of arguments to the
path.
Change-Id: I62d3883b14f9d5a517e4a3d58f019014b46fd1b4
Previously the base path for the API was hardcoded to `/api` and the
specified version.
This was not obvious that the generated code was setting that base path
and it was not flexible for serving the API under a different path than
`/api`.
We will likely need to set a different base path if we pretend to serve
the new back office API that we are going to implement alongside the
current admin API until the new back office is fully implemented and
verified that works properly.
This commit also fix add the base path of the endpoints to the
documentation because it was even more confusing for somebody that wants
to use the API having to find out them through looking to the generated
code.
Change-Id: I6efab6b6f3d295129d6f42f7fbba8c2dc19725f4
Generate the documentation and the typescript code for the example of
that we have to generate an API through the API generator.
The JSON Go struct field tags are needed because the typescript
generator require them, otherwise it panics.
The test had to be adjusted according to match the tags so Go consider
the structs the same type, otherwise, it doesn't compile.
Change-Id: I3e4ebff9174885c50ca2058b86b7ec60e025945c
Make the link more human-friendly - to contain the text of the group and
endpoint names.
Also link back to list of endpoints from each endpoint.
Change-Id: Ia3e2ebe20b58b5f60ecefe9d35fb8fd90dd4b4d7
This change makes it easier for someone reading the documentation to see
a full list of supported endpoints, and have direct links to the
details.
Change-Id: I46e2f809cfa2760845898eaa3d99db9066d435ef
This change adds an endpoint to get a user's projects, similar to
the OwnedProjects GraphQL query.
The console.ProjectInfo struct has been renamed to UpsertProjectInfo
to more accurately reflect its use.
Issue: https://github.com/storj/storj/issues/6135
Change-Id: I802fe4694a5cc75a9df2b565476f6e6f473431d4
This change adds request IDs to requests, logs them as part of audit
logs and sends to the client on error. This is to improve debugging
of customer issues.
Issue: https://github.com/storj/storj/issues/5898
Change-Id: I801514b547d28d810552d91aa7c8502051e552bf
This change creates the ability to run a server separate from the
console web server to serve the front end app. You can run it with
`satellite run ui`. Since there are now potentially two servers instead
of one, the UI server has the option to act as a reverse proxy to the
api server for local development by setting `--console.address` to the
console backend address and `--console.backend-reverse-proxy` to the
console backend's http url. Also, a feature flag has been implemented
on the api server to retain the ability to serve the front end app. It
is toggled with `--console.frontend-enable`.
github issue: https://github.com/storj/storj/issues/5843
Change-Id: I0d30451a20636e3184110dbe28c8a2a8a9505804
Having separate process/pod only for sending bloom filters once a week
is a bit waste. After reconfiguring production settings to use sender in
core we can remove also GC sender peer code.
https://github.com/storj/storj/issues/5979
Change-Id: I6efe3ec073f96545e1f70ad13843f8ccdf923ee8
placement.AllowedCountry is the old way to specify placement, with the new approach we can use a more generic (dynamic method), which can check full node information instead of just the country code.
The 90% of this patch is just search and replace:
* we need to use NodeFilters instead of placement.AllowedCountry
* which means, we need an initialized PlacementRules available everywhere
* which means we need to configure the placement rules
The remaining 10% is the placement.go, where we introduced a new type of configuration (lightweight expression language) to define any kind of placement without code change.
Change-Id: Ie644b0b1840871b0e6bbcf80c6b50a947503d7df
There are many case where the keywords `free` and `available`
are confused in their usage.
For most cases, `free` space is the amount of free space left
on the whole disk, and not just in allocation while
`available` space is the amount of free space left in the
allocated disk space.
What the user/sno wants to see is not the free space but the
available space. To the SNO, free space is the free space
left in the allocated disk space.
Because of this confusion, the multinode dashboard displays
the `free` disk space instead of the free space in the
allocated disk space https://github.com/storj/storj/issues/5248
While the storagenode dashboard shows the correct free space
in the allocation.
This change fixes the wrong free disk space. I also added a
few comments to make a distinction between the `free`
and `available` fields in the `DiskSpace*` structs.
Change-Id: I11b372ca53a5ac05dc3f79834c18f85ebec11855
Currently we are using Reliable to get missing pieces for repair
checker. The issue is that now checker is looking at more things than
just missing pieces (clumped/off, placement pieces) and using only node
ID is not enough. We have issue where we are skipping offline nodes from
clumped and off placement pieces check.
Reliable was refactored to get data (e.g. country, lastNet) about all
reliable nodes. List is split into online and offline. This data will be
cached for quick use by repair checker. It will be also possible to
check nodes metadata like country code or lastNet.
We are also slowly moving `RepairExcludedCountryCodes` config from
overlay to repair which makes more sens for it.
This this first part of changes.
https://github.com/storj/storj/issues/5998
Change-Id: If534342488c0e440affc2894a8fbda6507b8959d
Add some code to generate a basic markdown file documenting a generated
API. Generate this document for the API in
satellite/console/consoleweb/consoleapi/gen.
The documentation is not completely correct, as it may include some
values in the request body that are not actually usable by the
requester. This can be fixed by making sure all types used within the
generated API are properly annotated with `json` tags.
Issue: https://github.com/storj/storj-private/issues/244
Change-Id: I57b259967fb0db8f548b6598a10c825da15ba723
