bolt/organization_users_store contains a boltdb implementation of a
chronograf.UsersStore that filters the results based on the organization
that is set on the context.
Signed-off-by: Jared Scheib <jared.scheib@gmail.com>
We would like to add additional user-configurable options to the display
of axes on Dashboards. This adds three fields to expand settings that
the frontend can persist through the API.
One field of interest here is the "Base" field which controls when and
how axes transition the display of values such as bytes, kilobytes,
megabytes, etc. By default, it's returned from the API as "10" to
indicate decimal, but can be set to anything the frontend wishes--the
immediate differing value will be "2" for the aforementioned use case.
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.
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
Previously, if bounds were not set, the default value that would be
returned was ["0", "0"], which is incorrect. This now returns [] when
there was nothing set for a particular axis.
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.
There were previously no tests around Dashboard serialization to
protobuf, so this patch adds coverage for that. Also, the `go-cmp`
package has been introduced to replace our usage of `reflect.DeepEqual`
going forward because it has better comparison features that make it
more stable across Go versions and produces nice diffs in tests when
they fail, reducing the need for debug lines and manual inspection.
"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.
There were previously no tests around Dashboard serialization to
protobuf, so this patch adds coverage for that. Also, the `go-cmp`
package has been introduced to replace our usage of `reflect.DeepEqual`
going forward because it has better comparison features that make it
more stable across Go versions and produces nice diffs in tests when
they fail, reducing the need for debug lines and manual inspection.
"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.
Luke Morris
Jared Scheib
Michael Desa
Chris Goller
Andrew Watkins
Tim Raymond