notes on this commit. This commit was grueling ;-(. The task API is not a friendly
API to consume. There are a lot of non obvious things going on and almost every
one of them tripped me up. Things of note:
* the http.TaskService does not satisfy the influxdb.TaskService,
making it impossible to use as a dependency if tasks service gets
split out
* the APIs for create and update do not share common types. For example:
creating a task takes every field as a string, but in the update it is
taken as a options.Duration type. A step further and you'll notice that
create does not need an option to be provided, but the update does. Its
jarring trying to understand the indirection here. I struggled mightily
trying to make sense of it all with the indirection and differing types.
Made for a very difficult task (no pun intended) when it should have been
trivial. Opportunity here to fix these up and make this API more uniform
and remove unneccesary complexity like the options type.
* Nested IDs that get marshaled, are no bueno when you want to marshal a task
that does not have an ID in it, for either user/org/or self IDs. Its a challenge
just to do that.
* Lots of logs in the kv.Task portion where we hit errors and log and others where
we return. It isn't clear what is happening. The kv implementation is also very
procedural, and I found myself bouncing around like a ping pong ball trying to
make heads or tails of it.
* There is auth buried deep inside the kv.Task implementation that kept throwing me
off b/c it kept throwing errors, instead of warns. I assume, not sure if I'm
correct on this, but that the stuff being logged is determined inconsequential
to the task working. I had lots of errors from the auth buried in there, and hadn't
a clue what to make of it....
leaving these notes here as a look back at why working with tasks is so
difficult. This API can improve dramatically. I spent 5x the time trying
to figure out how to use the task API, in procedural calls, than I did
writing the business logic to consume it.... that's a scary realization ;-(
references: #17434
this is applied to all the resoruces that have had the spec.name field applied.
all resources that have not will work in the same way before this commit.
feat(pkger): export dashboard and variable *ToResource methods
fix(pkger): add empty selected _measurement to builder config
feat(chronograf): add note & note visibility to dashboard cell
The 1.x DashboardCell struct had migrated since we brought the code into
the InfluxDB codebase. This allows us to migrate cells that were created
since then.
feat(cmd/chronograf-migrator): add 1.x chronograf migrator tool
feat(chronograf-migrator): add function to transpile queries
fix: update spelling of todo comment pkger/models.go
Co-Authored-By: Deniz Kusefoglu <deniz@influxdata.com>
fix(chronograf): add type to DashboardQuery
The type has evolved since this code was moved over from chronograf.
Previously, we did not have access to flux as a type of query.
feat(chonograf-migrator): transpile influxql query to flux if possible
fix(chronograf): omit fields when empty on old chronograf structs
fix: make linter not mad at me
feat(chronograf-migrator): lowercase variable names
fix(pkger): add empty selected measurement to builder config
chore(chronograf-migrator): add basic readme
chore(pkger): export Variable and Dashboard ToResource methods
fix(chronograf-migrator): move flags out of init call
also adds some extra user friendliness. it sorts the pkg created via an
export by resource kinds. It also titles the kinds to make them match the
documentation even though the kind is case insensitive. Easier to read this
way.
no associations included at this time. Also fixes http response to be just
the pkg without the envelope. Having that envelope makes the API icky to
work with from any shell script or just saving it to file. This feels more
organic to just drop that envelope.
Johnny Steenbergen
Jonathan A. Sternberg
Zoe Steinkamp
Michael Desa
Greg
Deary Hudson III