* chore: remove dead code
* refactor: move FluxLanguageService interface to fluxlang
* chore: run fmt
* refactor: move task.go from top level to task/taskmodel
* chore: run formatter
* chore: fix up import ordering with gci
* feat(task): Extract options using AST-based method.
* feat(task): Use AST-based option APIs for updating task option.
* chore(task): Use the old way of parsing durations.
* fix(task): Ordering changed on us. Fixing tests to reflect the new order.
* fix(task): There's no way for us to know if there are multiples with the current APIs.
* chore(task): Guard against duplicate options. Minor cleanup.
* fix(kit/feature): Break cyclical dependency between influxdb and pkgs that use feature.
* chore(task): Feature flag updating Flux options.
* chore(task): Ensure we are testing both paths of feature flag.
* chore: Remove dead code.
* chore(task/options): Remove unnecessary conditional.
* chore(task/options): Unexport some error helpers.
* chore: update task tests to use the tenant service
After the introduction of the tenant system we need to switch the testing frameworks
to use it instead of the old kv system
* chore: update onboarding to allow injected middleware
This moves a few types and constants to the global package so it can be
used without importing the `task/backend` package. These constants are
referenced in non tasks-specific code.
This is needed to break a dependency chain where the task backend will
call into the flux runtime to perform parsing or evaluation of a script
and to prevent the http package from inheriting that dependency.
This change ensures the following behavior:
* task LatestScheduled is always set when a task is updated and
transitions from a status of inactive to active
* task LatestScheduled is non-zero when created, to set the initial
schedule time as some point after it was created
In addition, the kv.Service introduces clock.Clock that is used for
task create and task updates only. This change permits testing
in a deterministic fashion.
Previously we overwrote the tasks existing latestCompleted to be used for latestCompleted as well as latestScheduled.
For obvious reasons this is confusing and missleading. I believe by seperating the two fields we can have a clear seperation
of concerns.
Implementations of the `kv.Bucket#Cursor` API may use
the hints to instruct the access or read behavior to
the underlying key/value store.
The `findAllTasks` function was also fixed to ensure
that paging works as expected when using a name filter.
Tests were added to verify this behavior.
Redundant error checks were also removed.
* 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
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): 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.
Current behavior is that the first execution of a task happens based on the create time
of the task when using a 'every' schedule. If you create a task at 12:02 and want
the task to run every 15m. The first execution would happen at 12:17, and the 2nd would happen
at 12:30.
To fix this behavior I refactored the kv task to give a single source of knowledge.
We now have one function for finding exactly what the last scheduled task was.
We also now have a single method that calculates when the next schedule is due.
By unifying the logic it should always work the same way weather your asking when to run
or when creating a task.
* Update task servicetest to move dependency to the new TaskControlService
closes#12724
We will now have the capability to write new task services that dont have to implement the backend.Store or LogReader or LogWriters
Sam Arnold
Daniel Moran
Arnav Aggarwal
Lyon Hill
Brett Buddin
Jonathan A. Sternberg
George
Alirie Gray
Stuart Carnie
Gavin Cabbage
Nathaniel Cook
Chris Goller
Todd Persen
kelwang
zhulongcheng
docmerlin (j. Emrys Landivar)