* chore: Remove several instances of WithLogger
* chore: unexport Logger fields
* chore: unexport some more Logger fields
* chore: go fmt
chore: fix test
chore: s/logger/log
chore: fix test
chore: revert http.Handler.Handler constructor initialization
* refactor: integrate review feedback, fix all test nop loggers
* refactor: capitalize all log messages
* refactor: rename two logger to log
* feat(tracing): dont trace spans with full URL path names in ExtractFromHTTPRequest
* chore(multiple): replace all occurrences of julienschmidt/httprouter with influxdata/httprouter
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.
* feat(task): Remove token's from task structures
We had previously removed token's from the task api but left the token in place in several locations in the stack.
Now we can cleanly remove the extra tokens.
* feat(task): impersonate user on task execution
Passing tokens to tasks is cumbersome and we needed a way to more easily create tasks. With this change we no longer need a token on task create. We take the user that created the task and pass that in as the "owner". As far as the task is concerned the owner is the source of permissions.
This is done by adding an additional field on task create that is OwnerID. We will no longer respect the token passed in and it will be deprecated soon.
Things to do still:
Task updates need to allow for owners to be set.
The query system specifically expects an Authorization. When a request
comes in using a Session, use the target task's Authorization, if we are
allowed to read it, when executing a query against the system bucket.
Also set the generated token's description while we're here.
This enables us to use task's Authorization when we need to query the
system bucket to get run logs, etc. but we only have a Session.
Task ID is now a required value on run and log filters. It was
effectively required by all implementations before anyway, so now those
types reflect that requirement.
Organization ID was removed from those same fields. The TaskService
looks up the organization ID via the task in cases where we need it at a
lower layer.
Accept token when creating or updating a task, but only report back the
authorization ID.
This means the executor and the platform adapter are now both aware of
an Authorization Service.
With the ongoing authorization work, creation arguments will differ from
what's returned on reads. More specifically, creation will accept a
token, but reads will report back a token ID.
This refactor facilitates that authorization work, and also brings the
code closer to the swagger definition, for the TaskCreateRequest type in
particular.
For an operation that looks up a task or a run, when that operation
fails, only set the status to 404 if that operation explicitly returns
ErrTaskNotFound or ErrRunNotFound.
It's possible that the operation could fail for a reason other than the
ID being invalid: for example, if there was an IO error preventing the
lookup from succeeding.
Harden that behavior with tests for the task handler.
Closes#11589.
I did this with a dumb editor macro, so some comments changed too.
Also rename root package from platform to influxdb.
In interest of minimizing risk, anyone importing the root package has
now aliased it to "platform" so that no changes beyond imports were
necessary in those files.
Lastly, replace the old platform module to local path /dev/null so that
nobody can accidentally reintroduce a platform dependency while
migrating platform code to influxdb.
* add labels to task links
* add labels to task responses
* add failing test
* fix label POST
* make fmt
* fix dashboard tests
* update swagger
* fix task service test labels
* add labels test for dashboards http service
* pull params out of newTaskResponse
* pull params out of newDashboardResponse
* make fmt
* add labels to dashboard response in swagger
* make context first argument
* fix test formatting
Johnny Steenbergen
Jacob Marble
George
Alirie Gray
Jonathan A. Sternberg
Lyon Hill
Jorge Landivar
Kelvin Wang
Jade McGough
Todd Persen
kelwang
zhulongcheng
Mark Rushakoff
Michael Desa
Leonardo Di Donato
Mark Rushakoff