* feat(task): Allow tasks to run more isolated from other task systems
To allow the task internal system to be used for user created tasks as well
as checks, notification and other future additions we needed to take 2 actions:
1 - We need to use type as a first class citizen, meaning that task's have a type
and each system that will be creating tasks will set the task type through the api.
This is a change to the previous assumption that any user could set task types. This change
will allow us to have other service's white label the task service for their own purposes and not
have to worry about colissions between the types.
2 - We needed to allow other systems to add data specific to the problem they are trying to solve.
For this purpose adding a `metadata` field to the internal task system which should allow other systems to
use the task service.
These changes will allow us in the future to allow for the current check's and notifications implementations
to create a task with meta data instead of creating a check object and a task object in the database.
By allowing this new behavior checks, notifications, and user task's can all follow the same pattern:
Field an api request in a system specific http endpoint, use a small translation to the `TaskService` function call,
translate the results to what the api expects for this system, and return results.
* fix(task): undo additional check for ownerID because check is not ready
* NotificationRuleBase: the endpointID should be required and editable, there is missing a links property
* NotificationRule: add discriminator
* add a missing TraceSpan parameter into a GetNotificationRules and GetChecks
* Add TraceSpan parameter to GetNotificationEndpoints operation
* Fixed handler path for a list of all labels for a notification endpoint
* Fixed filter NotificationEndpoints by limit and offset
The http error schema has been changed to simplify the outward facing
API. The `op` and `error` attributes have been dropped because they
confused people. The `error` attribute will likely be readded in some
form in the future, but only as additional context and will not be
required or even suggested for the UI to use.
Errors are now output differently both when they are serialized to JSON
and when they are output as strings. The `op` is no longer used if it is
present. It will only appear as an optional attribute if at all. The
`message` attribute for an error is always output and it will be the
prefix for any nested error. When this is serialized to JSON, the
message is automatically flattened so a nested error such as:
influxdb.Error{
Msg: errors.New("something bad happened"),
Err: io.EOF,
}
This would be written to the message as:
something bad happened: EOF
This matches a developers expectations much more easily as most
programmers assume that wrapping an error will act as a prefix for the
inner error.
This is flattened when written out to HTTP in order to make this logic
immaterial to a frontend developer.
The code is still present and plays an important role in categorizing
the error type. On the other hand, the code will not be output as part
of the message as it commonly plays a redundant and confusing role when
humans read it. The human readable message usually gives more context
and a message like with the code acting as a prefix is generally not
desired. But, the code plays a very important role in helping to
identify categories of errors and so it is very important as part of the
return response.
The `/query` swagger endpoint now specifies that error messages are
returned as the standard JSON schema. The standard JSON schema has also
been changed slightly so that only `code` and `message` are documented
and the intention is that we will flatten the message from an
`influxdb.Error` before we encode the JSON.
We have been tracking down odd error messages when writing data and
found the problem to be internal server errors when writing empty
bodies.
I added fairly comprehensive test coverage for /api/v2/write as well
as simplify and clarify the error messages.
It was possible to create checks with invalid data causing
odd internal errors to return from the layers far down below.
Likely, we need to add more checks to the validation, but, I have
not thoroughly checked.
Closes https://github.com/influxdata/influxdb/issues/15042
Previously, there was an optional URL provided for the pagerduty
endpoint. However, the pagerduty API url does not change and as a result
it should not have been a parameter. The Pagerduty API does require a
`clientURL` that is presented in the pagerduty UI when an alert is
triggered. Currently that value will default to the alerts history page
for the organization.
At times snowflake id generation would create org and bucket IDs with
characters that had special meaning for the storage engine.
The storage engine concats the org and bucket bytes together into a
single 128 bit value. That value is used in the old measurement
section. Measurement was transformed into the tag, _measurement.
However, certain properties of the older measurement data location
are still required for the org/bucket bytes. We cannot have
commas, spaces, nor backslashes.
This PR puts a specific ID generator in place during the creation of
orgs and buckets. The IDs are just random numbers but with each
of the restricted chars incremented by one. While this changes the
entropy distribution somewhat, it does not matter too much for our
purposes.
... because now org and bucket ids are checked for previous existence
transactionally in the key-value stores. If the ID does already exist
then we try to generate a new key up to 100 times.
* WIP
* Fix UI linter errors from swagger changes to Level Rule
* Prevent same level selection on changes from
* Remove unused get
* Fix prettier error
* chore(notification/rule): change level rule to check level for rules
kelwang
Lyon Hill
Kelvin Wang
Johnny Steenbergen
Johnny Steenbergen
Jakub Bednář
George
Michael Desa
Brandon Farmer
Scott Anderson
Jonathan A. Sternberg
Chris Goller
Jade McGough
Russ Savage
Deniz Kusefoglu