* Bolt to kv/bolt
* Remove unused code
* Remove unused roles code
* Remove unused duplicate Makefile
* Clean up bolt implementation and start layering in an interface for another store
* Layer in kv interface
* Continue layering in kv interface
* Remove circuitbreaker things
* Move cell stuff out
* Convert cell logic to kv interface
* Start adding config logic to kv interface, likely will remain bolt only
* Get to compile with bolt kv before moving too far forward
* Start removing dead dashboard code
* Add generic kv implementation for dashboards
* Convert layouts to kv interface
* Migrate mappings to kv layer
* Migrate org_config to kv layer
* Migrate organizations to kv layer
* Migrate servers to kv layer
* Migrate sources to kv layer
* Migrate users to kv layer
* Start removing unused migration logic
Since there is a migration path for users via updating to 1.7.x line then to 1.8, there isn't any real reason to continue supporting migrating from a version ~2 years old.
* Cleaning up bolt dead codes
* Re-add disabled code
* Migrate tests over to kv layer
* Migrate config to kv layer
* Create default organization
* Remove etcd for now
* Improve new client and new service implementations
* Uncomment bolt build tests
* Add layouts test
* Add more dashboard tests to kv
This uses a purely random v4 UUID instead of a time-based v1 UUID for
the time series UUIDs (which were introduced in
dba9e28fa0 and
2fba2b9721).
As far as I can tell from
b6f6118b65/server/influx.go (L91-L94)
the server uses
b6f6118b65/id/uuid.go (L15)
to generate the `response.uuid` field where clearly a v4 UUID is being
generated. Mixing this with v1 UUIDs in the client code seems odd.
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated (although the implementation in
the npm uuid module uses generates a random fake MAC address). As such
they have much more complex semantics than v4 UUIDs which are simply
randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
This uses a purely random v4 UUID instead of a time-based v1 UUID for
the worker message IDs (which were introduced in
1a76a29ed2).
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated (although the implementation in
the npm uuid module uses generates a random fake MAC address). As such
they have much more complex semantics than v4 UUIDs which are simply
randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
greg linton
Greg
Timmy Luong
Bucky Schwarz
kelseiv
Michael Desa
Russ Savage
Andrew Watkins
Jacob Marble
Joshua Hoblitt
Alvaro [Andor]
Christoph Tavan