* 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
* feat(task): add limit function for task concurrency
The new task executor handles limit's differently then the old executor
instead of front loading limits by creating a runner for every task that might run
the new executor has a large worker pool and queue. This allow's us to have a unlimited
concurrency per task and helps us avoid a back log of task's execution based on a
arbitrary execution limit. This add's the ability to add an optional task execution limit
so a user can still have the advantages of limiting concurrency.
Closes https://github.com/influxdata/influxdb/issues/15154
Previously, we niavely incremented the unit associated with the leading
duration. Now, if the unit is `s` we double it. For every other unit, we
increase the magnitude by 1.
fix(notification/rule): change panic to t.Fatal
chore(notification/rule): add support for durations less than s
* 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
* test(storage): ensure multiple engines can run concurrently
* feat(storage): expose control over retention run
Fixes#15134.
This commit adds the ability to inject a functional option into a
storage.Engine for controlling when the retention enforcer can run.
Previously, retention enforcers ran on an interval; if you ran multiple
storage engines (as we do in some environments) then it was not possible
to coordinate when engines ran retention. Often they would synchronise
because they started at the same time.
This change will let you specify a blocking function to control when the
retention enforcer can run.
A simple function for serialising retention enforcement across multiple
storage engines could look like:
```go
var mu sync.Mutex
func f() (done func()) {
mu.Lock()
return func() { mu.Unlock() }
}
```
* refactor(ui): add vector graphic logos for each client library
* refactor(ui): replace mock content with real content
* refactor(ui): display client library content in overlays with routes
* refactor(ui): cleanup factored out components
* refactor(ui): increase size of client library overlays
* refactor(ui): make client library overlays wider
* refactor(ui): add link to docs for each client library
* refactor(ui): cleanup commented code
We needed the coordinator to be able to execute manual runs and resume runs.
These two functions have been added, but we also needed to allow for the executor to be
mocked out. To do that we needed to return a Promise interface instead of an actual
struct. Both these changes are to facilitate coordinator work and testing.
I chose to add a execute function that allow's the task executor to match expectation from
the scheduler but I left in the existing executor method that return's promises. This is
because I like to be able to have the accountablilty and visiblity inside what's happening
with each execution even though the promise isn't required for the scheduler. This function signature
will be used by the coordinator and potentially other's that want to ensure a 'execution' is completed.
Mustafa
Jakub Bednář
kelwang
Lyon Hill
Michael Desa
Deniz Kusefoglu
Johnny Steenbergen
Johnny Steenbergen
elbehery
Brandon Farmer
Kelvin Wang
Jonathan A. Sternberg
alexpaxton
Edd Robinson
Scott Anderson
Christopher Wolff
Lorenzo Affetti