Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup CLI flags and options for InfluxDB 3 #25646

Open
mgattozzi opened this issue Dec 12, 2024 · 5 comments
Open

Cleanup CLI flags and options for InfluxDB 3 #25646

mgattozzi opened this issue Dec 12, 2024 · 5 comments
Assignees
Labels

Comments

@mgattozzi
Copy link
Contributor

Use case:
A better user experience tailored towards InfluxDB 3 OSS version

Proposal:
Roll our own clap_blocks crate for OSS

Current behaviour:
Currently we have clap options set by reusing clap_blocks from IOx and it reflects so in the comments which can be confusing and it includes many options we do not need for OSS that can make it hard for users to discover what options are available to them.

Desired behaviour:

  • CLI options with help text specific to the OSS version
  • CLI options that contain only the necessary flags for OSS
  • Removal of clap_block dependency from core

Alternatives considered:
We can also just do them inline in influxdb3 or not at all. With internal feedback however this is considered confusing and verbose and not doing it all is not as viable an option as other users are likely to experience the same confusion.

@mgattozzi mgattozzi added the v3 label Dec 12, 2024
@hiltontj
Copy link
Contributor

We could also use Arg::hide to not display blocks from IOx, i.e.,

#[clap(hide = true)]

but then, I am not sure if there is a way for users to see those blocks at all, unless they refer to some external provided documentation.

This would help maintain compatibility in the short term, e.g., with the perf team's test harness, which is using several of the clap blocks from IOx like object store, tracing, and logging (perhaps others).

@pauldix
Copy link
Member

pauldix commented Dec 12, 2024

The object store, tracing and log blocks should be relevant to Monolith, shouldn't they? Meaning we don't want to hide them.

@hiltontj
Copy link
Contributor

The object store, tracing and log blocks should be relevant to Monolith, shouldn't they? Meaning we don't want to hide them.

I think all the blocks we are using are relevant. But there is a lot of IOx verbiage in them and the associated environment variables all use the IOX_ prefix. So, hide'ing them is really just a quick and dirty solution. Ultimately, we need to go through the chore of porting over each block and only including what is relevant.

@pauldix
Copy link
Member

pauldix commented Dec 12, 2024

We should do the cleanup in advance of the alpha.

@mgattozzi
Copy link
Contributor Author

mgattozzi commented Dec 12, 2024

I think we can just copy the relevant parts that we need from clap_blocks and rewrite them or pare the options down a bit. If we hide them in core then we can't sync easily with IOx. In many ways it's a read only copy of parts of IOx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants