This allows a creator of a layout to specify the visible extents of
graphs for individual cells. For example, a cell displaying a
percentage could be limited to values between 0 and 100.
Existing canned layouts need to updated as a separate step. However,
this adds support for Axes to appear in them as well.
Previously, users of the :interval: macro were restricted to using a
relative time range in their queries, or the :dashboardTime: macro. This
permits users to also supply an absolute time range in the form of:
time > '2017-01-01T00:00:00Z' and time < '2017-06-01T00:00:00Z'
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
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
"Axis" is a more consistent and appropriate name. Also, the formatting
the protobufs was all over the place, so this has been made consistent
using a first-column \t. Furthermore, a vim modeline was added to the
bottom to make it easier for editors to autoconfigure themselves to the
right format, since protobufs are not something that we edit everyday.
Also, 32-bit values have been substituted for 64-bit values in Protobuf
definitions.
The frontend would like to store viewport information for each cell so
that visualizations are zoomed to the proper extents upon rendering.
This adds a property to cells called "axes" which takes the following
shape:
```
{
"axes" : {
"y" : {
"bounds" : [
0,
2
]
},
"y2" : {
"bounds" : [
1,
3
]
}
}
}
```
Bounds specify the visible range for the axis, and are a 2-tuple of the
form [lower, upper]. Bounds are not implicitly inclusive or
exclusive--that determination is left for clients to make. Also, there
are no restrictions on the naming of axes.
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
"Axis" is a more consistent and appropriate name. Also, the formatting
the protobufs was all over the place, so this has been made consistent
using a first-column \t. Furthermore, a vim modeline was added to the
bottom to make it easier for editors to autoconfigure themselves to the
right format, since protobufs are not something that we edit everyday.
Also, 32-bit values have been substituted for 64-bit values in Protobuf
definitions.
The frontend would like to store viewport information for each cell so
that visualizations are zoomed to the proper extents upon rendering.
This adds a property to cells called "axes" which takes the following
shape:
```
{
"axes" : {
"y" : {
"bounds" : [
0,
2
]
},
"y2" : {
"bounds" : [
1,
3
]
}
}
}
```
Bounds specify the visible range for the axis, and are a 2-tuple of the
form [lower, upper]. Bounds are not implicitly inclusive or
exclusive--that determination is left for clients to make. Also, there
are no restrictions on the naming of axes.
Clean up conditionals by refactoring to use loop label.
Incidentally this also fixed a bug that would not allow
a Kapacitor server to be added by the same name as one
that already existed, allowing the check to be removed
as well.
In order for :autoGroupBy: and :dashboardTime: to co-exist in a query,
it's necessary to introduce template variable precedence to the backend.
This is done by adding a `Precedence()` method to the TemplateVariable
interface that returns an ordinal indicating the precedence level of the
template variable. Precedence starts from 0 (highest) proceeding to the
maximum that a `uint` can represent.
A template variable at a given precedence level can expect that all
template variables with higher precedence will have already been
replaced in the query that is passed to its `Exec` call.
For example, :autoGroupBy: has lower precedence than :dashboardTime:
because it needs to know the selected time range for the query. When the
`Exec` method of `GroupByVar` is invoked, it will see the query after
:dashboardTime: has already been replaced, allowing it to extract the
duration successfully.
In order for automatic group by to be remotely useful, we need to parse
out the selected duration of time from the query itself. The problem
with doing this is that using the existing machinery for parsing
InfluxQL requires having valid InfluxQL, which InfluxQL+Template
Variables is not. To break this chicken-and-egg problem, the duration is
directly extracted from the query using regular string processing.
Timothy J. Raymond
Tim Raymond
Chris Goller
Hunter Trujillo
Jared Scheib
Luke Morris
Andrew Watkins
Jade McGough