* chore(flux): update Flux function docs with experimental and 0.50 functions
* removed unnecessary newlines from fluxFunctions.ts
* fix(fluxFunctions): add space before param
The controller now supports setting an initial memory limit and setting
a maximum amount of memory that the controller may use separately from
the memory quota per query and the concurrency quota.
This allows the controller to increase the concurrency quota to a larger
number while setting the maximum amount of memory to a lower amount than
would be required for all queries to use 100% of their allowable memory.
Functionally, this means that a query will have a soft limit for an
initial memory byte quota that a query is guaranteed to have, a shared
pool that it is allowed access to in the case it uses more, and a hard
limit that no query may exceed to prevent runaway queries from taking
over the entire pool.
This change is completely backwards compatible with older configurations
as the new options will default to values that mimic the old behavior
where a query is allocated the full amount of its memory quota and the
maximum amount of memory is based on the concurrency quota and this
maximum memory quota.
In addition to the above, this also fixes a bug in the controller that
allowed it to run more than its concurrency as executing queries. This
happened when the results had finished being sent by the executor, but
the query had not yet been read and/or serialized. The executor would be
freed up and would take the next query even though the previous query
hadn't yet been finalized with `Done()`.
1. Removing dashboard changes from earlier commit
2. Changing inital state variable name to just be endpoint
3. moving dispatch in check actions
4. Adding notification to endpoints
These are the final tests and rule fix for this issue.
The checks is special in how it was fixed.
But endpoints and rules have the exact same fix on them
All the tests are running smoothly
EsLint was run so this branch should no longer fail from that as well.
1. We fixed the endpoints so it no longer routes to 404 page, instead now routes to the alerting index. When endpoint id does not exist.
2.Added Cypress test to confirm the routing works on checks. Routing the user to the index page when the checks id does not exist.
this fix allows the DI of the vault service configuration. There are place
where we'd like to adminster this with flags, but are locked into
the default env var setup we had previously. One other note is that
calling api.DefaultConfig() calls the ReadEnvironment() method already,
so that was dropped.
hopefully this commit doesnt do anything, but it opens up the ability to
change the static folder of the project through the environment variable
STATIC_FOLDER so that we can cache static files and not cache the index
file (allowing more passive deployment strategies), and allows the user
to change the base path of the project with the BASE_PATH variable,
opening up the ability to run an instance behind an nginx proxy,
though that change is pending an update to the @influxdata/oats package
before we can turn it on
* 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