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

Improve error messages even more for OSS- or cloud-only commands #142

Closed
williamhbaker opened this issue Jun 23, 2021 · 0 comments · Fixed by #347
Closed

Improve error messages even more for OSS- or cloud-only commands #142

williamhbaker opened this issue Jun 23, 2021 · 0 comments · Fixed by #347
Assignees
Labels
enhancement New feature or request

Comments

@williamhbaker
Copy link
Contributor

williamhbaker commented Jun 23, 2021

#140 added some basic functionality for flagging specific service APIs as being "OSS only" (ex: health, backup, restore) or "Cloud only" (buckets-schemas). When applied, these designations will expand on error messages if errors are encountered when executing the commands to indicate that the commands are OSS only or Cloud only as appropriate.

During the course of this work, it was noted that there could be some additional improvements:

  • When 2.0 API missing X-version and X-Build Headers influxdb#20224 & the equivalent cloud issue are implemented, use the X-Influxdb-Version header to explicitly verify that the server is appropriate for the command. A very specific error could be displayed if the command is OSS only, but the server response is from a cloud server, for example. It might even be possible to do a pre-flight check of some kind for commands like these to verify the right server is in place before executing the command, although that might limit backwards compatibility.
  • feat: improved error messages for cloud- or oss-only commands #140 requires calling the "X-only" methods on individual services when they are created in the code. It might be better to have a separate list of of these special commands that could be maintained apart from the service creation logic. Although it wasn't immediately obvious at the time on how this could be done, it is an area for potential improvement in the future.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants