Port the delete command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Steps to reproduce:

1. Initialize an influxdb OSS instance locally (I use OS X), create an organization and a bucket. For my case, I did the initialization using the http://localhost:9999 UI.
2. While the OSS is running, try to access the database using influx repl command:

➜  influxdb git:(master) influx repl -o "my-org"
Error: Unable to find organization: organization not found.

3. Go to the web UI, find the organization Id for "my-org", try again access the database by using the organization id:

➜  influxdb git:(master) influx repl --org-id 047e8606a2268000
>

This works.

Expected behavior:
The -o flag with the organization name should work the same as the organization id.

Actual behavior:
Only organization id works.

Environment info:

• System info: Run uname -srm and copy the output here
  Darwin 19.0.0 x86_64
• InfluxDB version: Run influxd version and copy the output here
  2.0.0 (cde064b)
  Note: influxd version does not work:

➜  influxdb git:(master) influxd version
Error: unknown command "version" for "influxd"
Run 'influxd --help' for usage.

After creating a new user for an organization influx user create -o influxdata -u new_russ -p something and then listing the members of the org, i see a <nil> displayed in the username, even though it is returned when i print as json.

➜  influxdb git:(master) ✗ ./bin/darwin/influx org members list -n influxdata
ID			Name	User Type	Status
0673b0f2e540a000	<nil>	member		active
➜  influxdb git:(master) ✗
➜  influxdb git:(master) ✗ ./bin/darwin/influx org members list -n influxdata --json
[
	{
		"id": "0673b0f2e540a000",
		"name": "new_russ",
		"status": "active"
	}
]

might be related to something here: https://github.com/influxdata/influxdb/blob/master/cmd/influx/organization.go#L606

Proposal:
Like to add the ability to use an existing profile to pull remote data for autocompletion in the shell.

Example:

influx bucket ls --id=
foo_bucket      FOO_BUCKET_ID       Description of foo bucket
bar_bucket      BAR_BUCKET_ID       Description of bar bucket

and user can tab complete to select the bucket they are interested in and the id/name/field is filled in by the autocompletions

Current behavior:
manually have to copy pasta data into the shell

Desired behavior:
I want choices provided for me

Alternatives considered:
leave it be

Use case:
Dramatically improves the usability of the influx cli tool

Port the bucket command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Port the completion command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Port the template command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

$ influx config create 
--active        -a  -- Set it to be the active config
--help          -h  -- Help for the create command
--hide-headers      -- Hide the table headers; defaults false; Maps to env var $INFLUX_HIDE_HEADERS
--host              -- HTTP address of Influx; Maps to env var $INFLUX_HOST
--json              -- Output data as json; defaults false; Maps to env var $INFLUX_OUTPUT_JSON
--local             -- Run commands locally against the filesystem
--name          -n  -- The config name (required)
--org           -o  -- The optional organization name
--skip-verify       -- SkipVerify controls whether a client verifies the server's certificate chain and host name.
--token         -t  -- API token to be used throughout client calls; Maps to env var $INFLUX_TOKEN
--url           -u  -- The config url (required)

$ influx config create 
--active        -a  -- Set it to be the active config
--help          -h  -- Help for the create command
--hide-headers      -- Hide the table headers; defaults false; Maps to env var $INFLUX_HIDE_HEADERS
--json              -- Output data as json; defaults false; Maps to env var $INFLUX_OUTPUT_JSON
--config-name          -n  -- The config name (required)
--config-org           -o  -- The optional organization name
--config-token          -- API token to be used throughout client calls; Maps to env var $INFLUX_TOKEN
--config-host-address          -u  -- The config url (required)

AC

• flag names and descriptions updated to match details above

Port the dashboards command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Port the secret command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Proposal:
Using the influx command line tool, the output format should be in csv or json as well as the default.

This exists with older version of ./influx and should be in the new version. When using curl, the data comes back as csv, but not from the CLI.

Current behavior:

using this from the command line:
MBP15-KCURTIS:influx kcurtis$ ./influx query 'from(bucket:"scrap")|>range(start:-5s)|>yield()' -o kmc
Result: _result
Table: keys: [_start, _stop, _field, _measurement, tag1]
_start:time _stop:time _field:string _measurement:string tag1:string _time:time _value:float

2019-12-17T22:29:28.169521000Z 2019-12-17T22:29:33.169521000Z f1 kr

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^------needs to be in csv
Use case:
Why is this important (helps with prioritizing requests)?
As an Analyst, I need the data to be easily opened in standard analysis tools (excel, google sheets, etc) so that I can work with the data in standard tools

Port the task command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

When running influx apply -f $FILENAME --force true --json, the output to stdout is not parseable as JSON

Steps to reproduce:
List the minimal actions needed to reproduce the behavior.

1. Create a minimal template, eg. example.yaml:

apiVersion: influxdata.com/v2alpha1
kind: Label
metadata:
    name: foo-bar-ab9001
spec:
    color: '#066fc5'
    name: some_label

2. Run influx apply -f example.yaml --force true --json
3. Observe that the output is not, strictly speaking, valid JSON

Specifically, the output is the concatenation of two bits of text that are each individually valid JSON documents, but, you cannot simply concatenate JSON documents and still have valid JSON; for example, {} is a valid JSON document, but {}{} is not.

Expected behavior:
Using the --json flag results in output that can be parsed by a JSON parsing library

Actual behavior:
You get output that isn't valid JSON such as the following:

{
        "buckets": [],
        "checks": [],
        "dashboards": [],
        "labels": [
                {
                        "id": 0,
                        "stateStatus": "new",
                        "templateMetaName": "foo-bar-ab9001",
                        "kind": "Label",
                        "new": {
                                "name": "some_label",
                                "color": "#066fc5",
                                "description": ""
                        },
                        "old": null
                }
        ],
        "labelMappings": [],
        "notificationEndpoints": [],
        "notificationRules": [],
        "tasks": [],
        "telegrafConfigs": [],
        "variables": []
}
{
        "stackID": "06c65a42a111b000",
        "Summary": {
                "buckets": [],
                "checks": [],
                "dashboards": [],
                "notificationEndpoints": [],
                "notificationRules": [],
                "labels": [
                        {
                                "kind": "Label",
                                "templateMetaName": "foo-bar-ab9001",
                                "envReferences": [],
                                "id": 488176851853881344,
                                "orgID": 346504372515078680,
                                "name": "some_label",
                                "properties": {
                                        "color": "#066fc5",
                                        "description": ""
                                }
                        }
                ],
                "labelMappings": [],
                "missingEnvRefs": [],
                "missingSecrets": [],
                "summaryTask": [],
                "telegrafConfigs": [],
                "variables": []
        }
}

Environment info:
InfluxDB Cloud 2.0
CLI tools version: Influx CLI 2.0.3 (git: fe04d346df) build_date: 2020-12-15T01:00:16Z

Make it possible to develop in this repo using our usual flow.

• Set up go modules
• Pick a CLI library to use for now, and make the program entry-point with it
• Add enough build/test harness for CI to run

Port the config command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

influx setup isn't idempotent: if it fails after the CLI sends an onboarding request to the server, subsequent runs will fail with an "instance has already been set up" error.

The only thing the CLI does after the onboarding request is write a config file. We could potentially log/print the config contents on error (though it includes an auth token, so that could be a security risk).

Port the write command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

We want to codegen our HTTP clients from OpenAPI in the new CLI.

• Review existing OpenAPI codegen solutions for Go
• Use the most promising option to codegen a client for the /ping endpoint
• Wire up the generated client to a new ping CLI command

Steps to reproduce:

1. Run "influx template"

Expected behavior:
See 'influx template -h' for help

Actual behavior:
Nothing is returned

Environment info:
Influx CLI 2.0.1 (git: 37cc047133) build_date: 2020-11-11T03:53:31Z

The CLI communicates to influx over the HTTP API, which by default has a limit of 100 for all resources and offers pagination to get more results.

This isn't properly being taken into account in the CLI, and therefore it's impossible to show results past the first 100.

AC: As a user, I should see all results when entering a command like influx buckets list.

As a user, i would expect to see the list of tokens in my cloud2 account.

➜  influxdb git:(master) ✗ influx bucket list
ID			Name		Retention	Organization ID
c687a55297399f56	demo		0s		03921cbebef90000
8e0cc79097d0afb5	integral	0s		03921cbebef90000
d5c18759d2df7021	seattle		0s		03921cbebef90000
05e5d14466ae5000	smiley		0s		03921cbebef90000
33b8e2b88bbe557c	telegraf	0s		03921cbebef90000
4b64018436a7cdf1	test		0s		03921cbebef90000
05e35c6cb8250000	time_bucket	720h0m0s	03921cbebef90000
000000000000000a	_tasks		72h0m0s
000000000000000b	_monitoring	168h0m0s
➜  influxdb git:(master) ✗ influx config
Active	Name	URL						Org
*	uswest	https://us-west-2-1.aws.cloud2.influxdata.com	russ+cloud2's organization
➜  influxdb git:(master) ✗ influx bucket list
ID			Name		Retention	Organization ID
c687a55297399f56	demo		0s		03921cbebef90000
8e0cc79097d0afb5	integral	0s		03921cbebef90000
d5c18759d2df7021	seattle		0s		03921cbebef90000
05e5d14466ae5000	smiley		0s		03921cbebef90000
33b8e2b88bbe557c	telegraf	0s		03921cbebef90000
4b64018436a7cdf1	test		0s		03921cbebef90000
05e35c6cb8250000	time_bucket	720h0m0s	03921cbebef90000
000000000000000a	_tasks		72h0m0s
000000000000000b	_monitoring	168h0m0s
➜  influxdb git:(master) ✗ influx auth list
ID	Description	Token	User Name	User ID	Permissions
							[]

Proposal:
Add a message to "influx template validate" confirming that validation succeeded.

Current behavior:
❯ influx template validate -f https://raw.githubusercontent.com/influxdata/community-templates/master/linux_system/linux_system.yml
❯

Desired behavior:
A message like "Template is valid" when validation succeeded.

Alternatives considered:
❯ echo $?
0

Use case:
It's difficult to understand if the command failed or not without any message.

Current behavior is that a user can only be made member of an org

Port the restore command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

NOTE: Use the new API design from influxdata/openapi#97

Port the apply command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Port the setup command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Port the export command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Sometimes, there are apis that work in OSS but not in cloud. the CLI seems to do a poor job in detecting response codes and providing a good error message. This issue is to improve that parsing and error messaging.

Here's an example:

[techops@t410 influxdb2-client-2.0.4-linux-amd64]$ ./influx v1 auth list --host https://us-west-2-1.aws.cloud2.influxdata.com --org-id xxxxxxxxxx --token (all access token)
Error: Invalid character '<' looking for beginning of value.
See 'influx v1 auth list -h' for help

Port the auth command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Proposal:
Make the influx config create command interactive for parameters not passed as flags

Current behavior:
You must pass all config parameters as command line arguments, which requires knowing what arguments you need

Desired behavior:
A user should be able to run influx config create alone and be promoted to input each config parameter.

Alternatives considered:
You could allow a mix of command line arguments and interactivity, only prompting for what wasn't passed on the CLI.

You could also check for environment variables to use as default options in the interactive mode.

Use case:
Using configurations is the new recommended way to use the influxdb CLI, but the process for creating them is not clear or intuitive, which will leave new users feeling confused by InfluxDB and having an undesirably high "time to awesome"

Port the v1 auth command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Port the backup command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

NOTE: Use the new API design from influxdata/openapi#96

Port the telegrafs command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Port the v1 dbrp command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

in 1.x, importing large files via the CLI would print out a status message to let you know how it is progressing. https://docs.influxdata.com/influxdb/v1.6/tools/shell/#influx-arguments

Note: For large datasets, influx writes out a status message every 100,000 points.

for example:
> 2015/08/21 14:48:01 Processed 3100000 lines. Time elapsed: 56.740578415s. Points per second (PPS): 54634

Port the query command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

This can be reproduced with:

 for ((i=1;i<=200;i++));                         
do
   ./influx bucket create -n"bucket$i"
done
./influx bucket list --hide-headers|wc

This will produce 20 buckets.

Port the stacks command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

Hello
I am trying to create a configuration to connect to Kapacitor using "influx v1 auth create" but I am getting an error:

ts=2021-03-16T10:38:53.617340Z lvl=error msg="api error encountered" log_id=0SveeFdW000 error="authorization not found"

The script which adds a docker container (located in the docker-entrypoint-initdb.d folder) during creation:

influx v1 auth create \
 --username ${DOCKER_INFLUXDB_INIT_USERNAME} \
 --read-bucket ${DOCKER_INFLUXDB_INIT_BUCKET_ID} \
 --write-bucket ${DOCKER_INFLUXDB_INIT_BUCKET_ID} \
 --password ${DOCKER_INFLUXDB_INIT_PASSWORD} \
 --token ${DOCKER_INFLUXDB_INIT_ADMIN_TOKEN} \
 --org ${DOCKER_INFLUXDB_INIT_ORG} 

Proposal:
Add the ability to create All Access tokens from the influx CLI.

Current behavior:
Currently to grant all permissions on a token, you have to pass all the permission flags when creating the token. But even still, these tokens appear to behave differently than an All Access token created through the InfluxDB UI (you can't export a template using one of these CLI-generated tokens).

Desired behavior:
A single flag on influx auth create that generates an All Access token:

influx auth create --all-access

Alternatives considered:

• Passing all permissions when creating a token through the CLI.

Use case:
Ease of use when managing tokens from the command line.

Proposal:
influx write should support recording more than just CSV->LP conversion errors.

Current behavior:
Only CSV->LP conversion errors are written to the location pointed to by --errors-file. Other errors are printed to console, but not persisted to file.

Desired behavior:
All errors encountered during writes are written to the errors-file, along with the source line that caused the problem.

Use case:
Help support efficiently debug & fix up bad lines during bulk data migrations

To reproduce this issue:

use a large file
https://drive.google.com/open?id=1ZO022BAJFAkLeqGT54-g_WdK2cdb8Nm_

run

influx write -b building @./all_building_permit_data.lp

took a while, got err
Error: Failed to write data: Post http://localhost:9999/api/v2/write?bucket=6f0bb579d933657f&org=49b3257a403b5b1d&precision=ns: dial tcp: lookup localhost: no such host.

expected
no error

tried to load a 5GB file into my influxdb instance and it keeps failing:

➜  influxdb git:(master) ✗ ls -lh ~/influxdb-data
-rw-r--r--  1 rsavage  staff   5.1G May 11 13:14 ./influxdb-data
➜  influxdb git:(master) ✗ time ./bin/darwin/influx write -b benchmark -f ~/influxdb-data
Error: Failed to write data: Post "http://localhost:9999/api/v2/write?bucket=c68f4b658e3087c6&org=05ad7794c3047000&precision=ns": dial tcp: lookup localhost: no such host.
See 'influx write -h' for help
./bin/darwin/influx write -b benchmark -f   5.02s user 1.61s system 9% cpu 1:12.25 total

Proposal:
To support large data imports, influx write should have the following improvements:

• Error handling - failing lines are written out to a log file with the error message, for easy correction and re-importation
• Error threshold - an import will halt when it reaches a given error-threshold
• Restart-ability - record its progress through each file and record when it failed or was halted
• Progress reporting - report on the status of import periodically, with lines imported, lines failed, est. percentage completion, etc.
• Handles compressed files - compressed line protocol or CSV files should be able to be read
• Respond to standard HTTP errors to throttle uploads dynamically

Use case:
These features will make importing very large data sets into Influx much simpler and more robust, helping new customers on-board with less pain.

Port the user command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this

We want to ensure the new influx CLI works on linux/arm64 hosts. Add build/test jobs for ARM64 to our Circle workflow. Circle offers support for ARM machine executors that might be useful here.

➜  influxdb git:(add-docker) ✗ ./bin/darwin/influx auth create --write-bucket node_metrics_v1
Error: Id must have a length of 16 bytes.
See 'influx auth create -h' for help

Looks like this only happens if use the wrong command line flag. the following works fine (write-bucketS):

./bin/darwin/influx auth create --write-buckets node_metrics_v1

$ influx get buckets
$ influx export
$ influx apply pkg
$ influx config ...

instead of having the rest hierarchy we have now, we orient it around the action users want to take. I think it supports what you are after more so than cobbling it together in its current shape.

@jsteenb2 can add additional details here.

additional details from @jsteenb2:

Influx CLI proposal

This proposal is advocating for action/verb oriented commands.
At the time of writing this, the CLI is more or less a mirror of the resource heirarchy of the REST API.
I am submitting that we can change up this workflow in the CLI, to minimize command bloat, standardize inputs/outputs, and make it simpler to extend the CLI to support additional features.
In addition, we can support the existing CLI while we transition, but while we are in beta, we can deprecate these and sunset them early in the v2 GA release cycle, if not before.

New Commands

influx list|ls [resource command] [--name --id]

influx list buckets

influx list labels

influx list organizations|orgs

influx list secrets

influx list tasks

influx list telegrafs

influx list authorizations|auth

influx list buckets --name=Name1 --name=Name2 --id=ID1 --id=ID2

influx list buckets Name1 Name2 ID1 ID2

influx list buckets

influx apply [resource command] [pkg flags]

influx apply --file PATH_TO_PKG --url URL_TO_PKG ... other flags

influx apply bucket

influx apply label

influx apply organization|org

influx apply pkg

influx apply secret

influx apply task

influx apply telegraf

influx apply authorization|auth

# apply and create a bucket from pkg via piped input
cat pkg.yml | influx apply bucket

# apply and create a bucket via file input
influx apply bucket --file PATH_TO_PKG

# apply and create a new bucket via flags
influx apply bucket --name BUCKET_NAME --retention-period 24h

# apply and update existing bucket via flags
influx apply bucket --id BUCKET_ID --name BUCKET_NAME --retention-period 24h  

influx remove|rm [resource command] [--force]

influx remove authorization|auth

influx remove bucket

influx remove label

influx remove organization|org

influx remove secret

influx remove stack

influx remove task

influx remove telegraf

# remove by --id flag
influx remove bucket --id $BUCKET_ID

# remove by --name flag
influx remove bucket --name $BUCKET_NAME

# remove by input arg being ID
influx remove bucket $BUCKET_ID 

# remove by input arg of bucket name
influx remove bucket $BUCKET_NAME

# mix of names, ids, flags
# this sample removes up to 4 buckets if names and ids are all unique
influx remove bucket \
    --id $BUCKET_ID_1 \
    --name $BUCKET_NAME_1 \
    $BUCKET_ID_2 $BUCKET_NAME_2

influx export [command] [existing flags]

influx export all [existing flags]

# potential sub commands by resource (if desired)
influx export buckets

influx export checks

influx export dashboards

influx export endpoints

influx export labels

influx export tasks

influx export telegraf-configs|telegrafs

influx export variables

Existing commands which are all action/verb based which will remain unchanged

influx CLI specific commands

influx completion

influx config

influxd ping

influx ping

query commands

influx query

influx repl

influx transpile

setup command

influx setup

write commands

influx backup

influx delete

influx write

Port the org command (and any subcommands) from the influxdb repo.

• Replace the use of any hand-rolled HTTP clients with code-generated clients
• Interesting business logic should "live" outside of the cmd/ module
• Tests should also be ported / extended as part of this