The pattern of using a select with a list of options and a default that
returns an error isn't bad for a one-off validation:
select myProp {
case "validOption1", "validOption2":
// no-op
default:
panic("invalid!")
}
However, we're doing this multiple times in this method, so it makes
sense to pull this out into a new method to make it clearer what's
happening.
This adds a `oneOf` function that takes some property and a variadic
list of valid options and reports whether or not that property is among
that list.
The Base and Scale options on axes can only be one of two parameters. We
weren't validating that this was the case. This patch ensures that Base
can only ever be "10" or "2", and Scale must be either "linear" or
"log".
Associated test coverage was also added.
New options were introduced to control things like scale, base, etc. on
axes and these were previously not documented. This adds documentation
of the newly supported parameters by the API.
This logic was originally left in place to help future test writers, but
its presence was vexing because it was not exercised in existing test
cases. It has been commented out should future tests need to leverage
it.
Kapacitor responses are paginated, and sometimes users have more than
the default 100 tasks that are returned from Kapacitor. This replaces
the previous Kapa client with one that automatically follows paginated
responses from Kapacitor's ListTasks endpoint and returns the full
response.
Tests for the KapacitorRulesGet endpoint had to be updated because they
did not account for "limit" and "offset", and so led to an infinite
loop with the paginated client. A correct kapacitor backend will not
have this behavior
The kapacitor client used in the kapacitor endpoints is limited to
fetching whatever limit you provide it. If you provide no limit, it
defaults to a limit of 100. We use this default behavior currently.
Some users have more than 100 tasks, so we need a client that's capable
of continually fetching tasks from Kapacitor until there are none left,
and returning the full response to the frontend.
This introduces a PaginatingKapacitorClient which does exactly that.
Also, test coverage was added around the KapacitorRulesGet endpoint,
since it was previously untested.
Because we are now creating new instances of dashboards when we create a
response, it's critical to copy every element of Dashboards from the
previous to the new instance.
We were not previously copying the Type field of cells, so this was
defaulting to the empty string zero value. This patch adds "Type" to the
tests and ensures that it's properly copied
In anticipation of adding Axes to cells, I wanted some test coverage to
be in place before I made the change.
This covers the happy path case as well as focusing on individual
applications. To come are focusing on a measurement and a test for when
the store is unavailable.
Also removed LegacyBounds marshaling since it was no longer necessary
Conflicts resolved:
bolt/internal/internal.go
bolt/internal/internal.pb.go
bolt/internal/internal.proto
bolt/internal/internal_test.go
chronograf.go
server/cells_test.go
server/dashboards_test.go
server/swagger.json
When creating new dashboards to set defaults, not all properties of the
dashboard were being copied. This ensures that they are so that zero
values are not used for things like the ID and Name.
Dashboard responses had data races because multiple goroutines were
reading and modifying dashboards before sending them out on the wire.
This patch introduces immutability in the construction of the response,
so that each goroutine is working with its own set of dashboardResponse
structs.
The contract with the frontend states that bounds should come back as an
empty array instead of null when there are no bounds present. We must
explicitly specify []string{} for this to happen.
Certain aspects of the frontend requires the presence of these three
axes, so part of the contract established is that the backend will
always provide them. Since we centralize creation of
dashboardCellResponses, this is where these axes are added to all cell
responses.
Additionally, because there was previously no coverage over the
dashboard cells endpoints, a test has been added to cover the
DashboardCells method of Service.
Due to various limitations with the previous implementation of Bounds as
a [2]int64{}, we've decided to change this to a []string{}. This will
allow clients to store arbitrary data specifying a bound and interpret
it as they wish.
For the forseeable future, we will only be using the "x", "y", and "y2"
axes, even though the underlying serialization can support arbitrary
axes (for the future).
This ensures that only "x", "y", and "y2" axes are present and updates
the Swagger docs to reflect that fact
Cells now have axes which represent their visualization's viewport. This
updates the Swagger documentation to reflect this.
Things to be aware of
=====================
The form of "axes" is that of a map<string,object>, which is represented
in Swagger by an "additionalProperties" key (search for "string to model
mapping" here: https://swagger.io/specification/).
For the forseeable future, we will only be using the "x", "y", and "y2"
axes, even though the underlying serialization can support arbitrary
axes (for the future).
This ensures that only "x", "y", and "y2" axes are present and updates
the Swagger docs to reflect that fact
Cells now have axes which represent their visualization's viewport. This
updates the Swagger documentation to reflect this.
Things to be aware of
=====================
The form of "axes" is that of a map<string,object>, which is represented
in Swagger by an "additionalProperties" key (search for "string to model
mapping" here: https://swagger.io/specification/).
Tim Raymond
Nathan Haugo
Timothy J. Raymond
Jared Scheib
Chris Goller
Jared Scheib
Hunter Trujillo