* feat(task): Record the latest success/failure of a Task.
* chore(task): Fix typo.
* chore(kv): Test the updating of latest success/failure fields.
* fix(kv/task): Copy the latest success/failure fields when unmarshalling.
* chore(changelog): Add 19390 to changelog.
This commit temporarily pulls in code from the flux/ast/edit
package ensure builds continue. Once Flux is upgraded to the
latest, the pkg/flux package will be removed.
* 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.
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.
The tasks subsystem will now use the flux language service to parse and
evaluate flux instead of directly interacting with the parser or
runtime. This helps break the dependency on the libflux parser for the
base influxdb package.
This includes the task notification packages which were changed at the
same time.
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.
* 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
UpdateFlux is called during updates within the K/V store, and may
panic when parsing unexpected Flux scripts, which is undesirable.
We will look for an opportunity to log the panic, so they can be
tracked down and fixed.
* 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.