From ccd80297bb8cddae1f1bf3700cc7efc3fc314870 Mon Sep 17 00:00:00 2001 From: Jason Stirnaman Date: Thu, 12 Mar 2026 13:04:32 -0500 Subject: [PATCH] fix(api-docs): enforce one-tag-per-operation, fix Enterprise v1 spec MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Remove dual tags from v2-compat operations in both v1 specs, add x-compatibility-version: v2 for Hugo-native badge rendering - Fix Enterprise v1 spec version 1.11.6 → 1.12.2 (spec, examples) - Add GET /shard-status endpoint to Enterprise v1 spec (was only in the legacy content page) - Document one-tag-per-operation convention in api-docs/README.md - Update api-docs.instructions.md for current file layout and pipeline - Add analyze-api-source agent for cross-product API docs analysis --- .claude/agents/analyze-api-source.md | 166 ++++++++++++++++++ .github/instructions/api-docs.instructions.md | 34 +++- api-docs/README.md | 163 +++++++++++++++-- .../v1/influxdb-enterprise-v1-openapi.yaml | 100 ++++++++++- .../influxdb/v1/influxdb-oss-v1-openapi.yaml | 10 +- 5 files changed, 441 insertions(+), 32 deletions(-) create mode 100644 .claude/agents/analyze-api-source.md diff --git a/.claude/agents/analyze-api-source.md b/.claude/agents/analyze-api-source.md new file mode 100644 index 000000000..fd80a00da --- /dev/null +++ b/.claude/agents/analyze-api-source.md @@ -0,0 +1,166 @@ +--- +name: analyze-api-source +description: | + Use this agent when you need to analyze, verify, or update API documentation across InfluxDB products, including comparing specs to content pages, finding gaps between related products, verifying endpoint documentation against OpenAPI specs, or updating tags.yml configurations. Examples: + + + Context: User reports that Enterprise v1 API docs are missing information that exists in OSS v1. + user: "The Enterprise v1 API reference is missing the /debug/pprof endpoints that are documented in the OSS v1 API page." + assistant: "I'll use the analyze-api-source agent to compare the OSS v1 and Enterprise v1 specs and content pages to identify gaps and draft the missing documentation." + + Cross-product API content gap -- the agent knows where both specs and content pages live and can diff them. + + + + + Context: User wants to verify API endpoint documentation is technically correct. + user: "Can you check if the /write endpoint parameters documented for Cloud Dedicated match what's in the spec?" + assistant: "I'll use the analyze-api-source agent to cross-reference the spec against the content page and tags.yml for Cloud Dedicated." + + Spec-to-content verification -- the agent knows the product-to-spec mapping and can check consistency. + + + + + Context: User needs to update tags.yml for a product. + user: "We added new endpoints to the Core spec. I need to update the tags and descriptions." + assistant: "I'll use the analyze-api-source agent to analyze the spec for new tags and draft tags.yml entries with descriptions and x-related links." + + Tags.yml authoring requires knowledge of the format, conventions, and existing patterns across products. + + + + + Context: User wants to audit API documentation coverage. + user: "Which endpoints in the OSS v1 spec don't have corresponding documentation in the content pages?" + assistant: "I'll use the analyze-api-source agent to compare the spec's operations against the documented endpoints." + + Coverage audit requires understanding both the spec structure and the content page structure. + + +model: inherit +color: cyan +tools: ["Read", "Grep", "Glob", "Bash", "Agent", "Edit", "Write"] +--- + +You are an API documentation analyst for the InfluxData docs-v2 repository. You understand the full API documentation infrastructure — OpenAPI specs, content overlays, tag configurations, and the build pipeline — across all InfluxDB products. + +## Product-to-Spec-to-Content Map + +Every product has three layers: an OpenAPI spec in `api-docs/`, a `tags.yml` config, and Hugo content pages in `content/`. + +| Product | Spec path | Tags config | Content pages | URL | +| ---------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------- | --------------------------------------------------- | -------------------------------------------- | +| InfluxDB 3 Core | `api-docs/influxdb3/core/influxdb3-core-openapi.yaml` | `api-docs/influxdb3/core/tags.yml` | `content/influxdb3/core/api/` | `/influxdb3/core/api/` | +| InfluxDB 3 Enterprise | `api-docs/influxdb3/enterprise/influxdb3-enterprise-openapi.yaml` | `api-docs/influxdb3/enterprise/tags.yml` | `content/influxdb3/enterprise/api/` | `/influxdb3/enterprise/api/` | +| Cloud Dedicated (data) | `api-docs/influxdb3/cloud-dedicated/influxdb3-cloud-dedicated-openapi.yaml` | `api-docs/influxdb3/cloud-dedicated/tags.yml` | `content/influxdb3/cloud-dedicated/api/` | `/influxdb3/cloud-dedicated/api/` | +| Cloud Dedicated (mgmt) | `api-docs/influxdb3/cloud-dedicated/management/openapi.yml` | `api-docs/influxdb3/cloud-dedicated/management/tags.yml` | `content/influxdb3/cloud-dedicated/api/management/` | `/influxdb3/cloud-dedicated/api/management/` | +| Cloud Serverless | `api-docs/influxdb3/cloud-serverless/influxdb3-cloud-serverless-openapi.yaml` | `api-docs/influxdb3/cloud-serverless/tags.yml` | `content/influxdb3/cloud-serverless/api/` | `/influxdb3/cloud-serverless/api/` | +| Clustered (data) | `api-docs/influxdb3/clustered/influxdb3-clustered-openapi.yaml` | `api-docs/influxdb3/clustered/tags.yml` | `content/influxdb3/clustered/api/` | `/influxdb3/clustered/api/` | +| Clustered (mgmt) | `api-docs/influxdb3/clustered/management/openapi.yml` | `api-docs/influxdb3/clustered/management/tags.yml` | `content/influxdb3/clustered/api/management/` | `/influxdb3/clustered/api/management/` | +| InfluxDB Cloud v2 | `api-docs/influxdb/cloud/influxdb-cloud-v2-openapi.yaml` | `api-docs/influxdb/cloud/tags.yml` | `content/influxdb/cloud/api/` | `/influxdb/cloud/api/` | +| InfluxDB OSS v2 | `api-docs/influxdb/v2/influxdb-oss-v2-openapi.yaml` | `api-docs/influxdb/v2/tags.yml` | `content/influxdb/v2/api/` | `/influxdb/v2/api/` | +| InfluxDB OSS v1 | `api-docs/influxdb/v1/influxdb-oss-v1-openapi.yaml` | `api-docs/influxdb/v1/tags.yml` | `content/influxdb/v1/api/` | `/influxdb/v1/api/` | +| InfluxDB Enterprise v1 | `api-docs/enterprise_influxdb/v1/influxdb-enterprise-v1-openapi.yaml` | `api-docs/enterprise_influxdb/v1/tags.yml` | `content/enterprise_influxdb/v1/api/` | `/enterprise_influxdb/v1/api/` | + +Products also have legacy hand-written API pages: + +- OSS v1: `content/influxdb/v1/tools/api.md` +- Enterprise v1: `content/enterprise_influxdb/v1/tools/api.md` + +Content overlays (`content/info.yml`, `content/servers.yml`) live in each product's `api-docs/` directory or in a `content/` subdirectory alongside the spec. + +## Related Product Pairs + +These products share most of their API surface and should stay consistent: + +- **OSS v1 ↔ Enterprise v1**: Enterprise adds `consistency` parameter on `/write`, cluster-specific endpoints, and `influxd-ctl` commands. Otherwise identical HTTP API. +- **Core ↔ Enterprise**: Same spec structure. Enterprise adds clustering features. +- **Cloud Dedicated ↔ Clustered**: Both have data + management APIs. Management APIs are nearly identical (different product names). Data APIs share the same v2-compatible surface. +- **Cloud v2 ↔ OSS v2**: Cloud omits Backup, Restore, Scraper Targets; adds Limits, Usage, Invokable Scripts, Bucket Schemas. + +## tags.yml Format + +Each `tags.yml` configures tag metadata applied by `post-process-specs.ts`: + +```yaml +tags: + Tag Name: + description: > # Folded scalar for prose + Description text. + x-traitTag: true # Supplementary docs (no operations) + x-related: + - title: Link text + href: /product/path/ + rename: New Tag Name # Rename from upstream spec +``` + +Key conventions: + +- Use `>` (folded) for prose descriptions, `|` (literal) for markdown with lists or HTML +- `x-traitTag: true` marks tags as documentation-only sections (Authentication, Quick start, Headers) +- Authentication tags use `|` and include `` +- Security scheme anchors differ: v3 uses `TokenAuthentication`; v1 uses `BasicAuth`/`QueryAuth`/`TokenAuth` + +## Operation Tagging Rules + +**One tag per operation.** Most API docs UIs don't render multi-tagged operations +well. Use `x-compatibility-version` instead of a second tag to mark compat endpoints. + +- `x-compatibility-version: v1` or `v2` — marks the API version an endpoint belongs to +- The build pipeline extracts this into `compatVersion` in article frontmatter for badge rendering +- For endpoints with a primary functional tag (Query, Write), use that tag and add + `x-compatibility-version` — don't also tag with "v2 Compatibility" +- For endpoints that are purely compatibility-layer (e.g., `/api/v2/buckets` in a v1 product), + use the compatibility tag as the single tag + +When reviewing specs, flag any operation with multiple tags as a violation. + +## Build Pipeline + +``` +getswagger.sh → fetch specs from upstream, bundle with Redocly +post-process-specs.ts → apply info/servers overlays + tags.yml configs +generate-openapi-articles.ts → generate Hugo pages + copy specs to static/openapi/ +``` + +Run with: `cd api-docs && sh generate-api-docs.sh` + +## Analysis Process + +When asked to analyze API documentation: + +1. **Identify the product(s)** from the user's request. Use the map above to locate all relevant files. +2. **Read the spec** to understand what endpoints, parameters, and schemas exist. +3. **Read the tags.yml** to understand how tags are configured and described. +4. **Read the content pages** (both generated `api/` pages and legacy hand-written pages like `tools/api.md`). +5. **Compare across related products** when relevant — check for content that exists in one product but not its pair. +6. **Report findings** with specific file paths, line numbers, and concrete recommendations. + +## Output Format + +Structure analysis results as: + +**Findings:** + +- List each gap, inconsistency, or issue with file paths +- Quote relevant spec or content sections + +**Recommendations:** + +- Specific changes with file paths and proposed content +- Flag which changes affect specs vs. tags.yml vs. content pages +- Note any cross-product implications + +**Verification steps:** + +- Commands or checks to validate the changes +- Related products that need parallel updates + +## Quality Standards + +- Never guess about endpoint behavior — verify against the spec +- When comparing products, read both specs before drawing conclusions +- Distinguish between spec-level issues (wrong in `api-docs/`) and content-level issues (wrong in `content/`) +- Note when issues should be fixed upstream in `influxdata/openapi` vs. locally in `docs-v2` +- Reference the README section on writing tag content: `api-docs/README.md#how-to-add-tag-content-or-describe-a-group-of-paths` diff --git a/.github/instructions/api-docs.instructions.md b/.github/instructions/api-docs.instructions.md index ba10069a1..ce2a44ad2 100644 --- a/.github/instructions/api-docs.instructions.md +++ b/.github/instructions/api-docs.instructions.md @@ -6,7 +6,7 @@ applyTo: "api-docs/**/*.md, api-docs/**/*.yml, api-docs/**/*.yaml" **Complete guide**: [api-docs/README.md](../../api-docs/README.md) -API documentation uses OpenAPI specifications and Redoc, not Hugo shortcodes. +API documentation uses OpenAPI specifications processed by a build pipeline, not Hugo shortcodes. ## Workflow @@ -19,15 +19,35 @@ API documentation uses OpenAPI specifications and Redoc, not Hugo shortcodes. 3. Test generated documentation 4. Commit YAML changes (HTML is gitignored) -## Files +## Key files per product -- `ref.yml`: Main API specification -- `content/*.yml`: Custom content overlays -- `.redocly.yaml`: Linter and bundler configuration +| File | Purpose | +| ----------------------------- | -------------------------------------------------------- | +| `{product-name}-openapi.yaml` | Main API spec (fetched and bundled by `getswagger.sh`) | +| `tags.yml` | Tag names, descriptions, `x-traitTag`, `x-related` links | +| `content/info.yml` | Info overlay (title, description, version) | +| `content/servers.yml` | Server URL overlay | +| `.config.yml` | Product config (API keys, spec paths, Hugo output dirs) | + +## Writing tag content + +Each product has a colocated `tags.yml` that configures tag descriptions and +related links. See [How to add tag content](../../api-docs/README.md#how-to-add-tag-content-or-describe-a-group-of-paths) +in the API docs README for the full format reference, field descriptions, +tag categories, and cross-product consistency guidelines. + +## Build pipeline + +``` +getswagger.sh → fetch and bundle specs with Redocly +post-process-specs.ts → apply info/servers overlays + tag configs +generate-openapi-articles.ts → generate Hugo pages + copy specs to static/openapi/ +``` ## Tools -- Redoc: Generates HTML from OpenAPI specs -- @redocly/cli: Lints and bundles specs +- **@redocly/cli**: Lints, bundles, and resolves `$ref`s in multi-file specs +- **post-process-specs.ts**: Applies content overlays and tag configs (replaces some Redocly decorators) +- **Redoc**: Generates HTML from processed OpenAPI specs For complete documentation workflow, see [api-docs/README.md](../../api-docs/README.md). diff --git a/api-docs/README.md b/api-docs/README.md index 3c35387d1..68d1701b7 100755 --- a/api-docs/README.md +++ b/api-docs/README.md @@ -289,24 +289,157 @@ that you can configure in `.redocly` without having to write JavaScript. ### How to add tag content or describe a group of paths -In API reference docs, we use OpenAPI `tags` elements for navigation, -the `x-traitTag` vendor extension for providing custom content, and the `x-tagGroups` vendor extension -for grouping tags in navigation. +Each product has a `tags.yml` file colocated with its spec that configures tag +names, descriptions, vendor extensions, and related links. +The `post-process-specs.ts` script applies these configs to the bundled spec +before article generation. -| Example | OpenAPI field | | -| :------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -| [Add supplementary documentation](https://docs.influxdata.com/influxdb/cloud/api/#tag/Quick-start) | `tags: [ { name: 'Quick start', x-traitTag: true } ]` | [Source](https://github.com/influxdata/openapi/master/src/cloud/tags.yml) | -| Group tags in navigation | `x-tagGroups: [ { name: 'All endpoints', tags: [...], ...} ]` | [Source](https://github.com/influxdata/docs-v2/blob/da6c2e467de7212fc2197dfe0b87f0f0296688ee/api-docs/cloud-iox/content/tag-groups.yml)) | +#### Tag config format (`tags.yml`) -#### Add and update x-tagGroups +```yaml +tags: + # Operation-backed tag — groups API endpoints + Write data: + description: > + Write time series data to InfluxDB 3 Core in line protocol format using + the v1, v2, or v3 write endpoints. + x-related: + - title: Write data using HTTP APIs + href: /influxdb3/core/write-data/http-api/ + - title: Line protocol reference + href: /influxdb3/core/reference/syntax/line-protocol/ -Custom `x-tagGroups` configured in -`PLATFORM/content/tag-groups.yml` override `x-tagGroups` defined in `influxdata/openapi`. -If you assign a list of tags to the `All endpoints` tag group, -the decorator applies your list and removes Operations that don't contain -those tags. -If you assign an empty array(`[]`) to the `All endpoints` x-tagGroup in `PLATFORM/content/tag-groups.yml`, -the decorator replaces the empty array with the list of tags from all Operations in the spec. + # Trait tag — supplementary documentation, no operations + Quick start: + x-traitTag: true + description: > + Get started authenticating, writing, and querying data with the + InfluxDB 3 Core API. + + # Rename a tag from the upstream spec + Cache data: + rename: Cache distinct values + description: > + Query cached distinct values. +``` + +#### Field reference + +| Field | Type | Description | +| ------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `description` | string | Tag description rendered in the API reference. Use `>` (folded scalar) for prose, `\|` (literal scalar) for multiline markdown with links or HTML. | +| `x-traitTag` | boolean | When `true`, marks the tag as supplementary documentation — it appears in the sidebar but has no associated operations. Use for tags like Authentication, Quick start, Headers, and API compatibility. | +| `x-related` | list | Related documentation links rendered below the tag description. Each item has `title` (link text) and `href` (URL path or full URL). | +| `rename` | string | Renames the tag in both `tags[]` and all `operation.tags[]` references. Use when the upstream tag name is too generic or doesn't match docs conventions. | + +#### Tag categories + +**Operation-backed tags** group API endpoints. Every operation in the spec +has a `tags[]` array; each unique tag name becomes a navigation section. +These tags need a `description` and usually `x-related` links. + +**Trait tags** (`x-traitTag: true`) are supplementary documentation sections +with no operations. They appear in the sidebar as standalone content pages. +Common trait tags: Authentication, Quick start, Headers, API compatibility, +Common parameters, Response codes, Pagination. + +#### One tag per operation + +Assign exactly **one tag** per operation. Most API documentation UIs don't +handle multi-tagged operations well — the operation appears in multiple +navigation sections, which is confusing. + +Use `x-compatibility-version` instead of a second tag to mark compatibility +endpoints. The build pipeline extracts this vendor extension and renders +version badges in the UI. + +```yaml +# Correct — single tag + compatibility marker +/api/v2/write: + post: + summary: Write data (v2 compatible) + x-compatibility-version: v2 + tags: + - Write + +# Wrong — dual-tagged, appears under both Write and v2 Compatibility +/api/v2/write: + post: + summary: Write data (v2 compatible) + tags: + - v2 Compatibility + - Write +``` + +For operations that belong purely to a compatibility layer (e.g., +`/api/v2/buckets` in a v1 product — no equivalent in the native API), +use the compatibility tag as the single tag: + +```yaml +/api/v2/buckets: + get: + summary: List buckets (v2 compatible) + x-compatibility-version: v2 + tags: + - v2 Compatibility +``` + +**`x-compatibility-version` values:** `v1`, `v2`, or `v3`. The build pipeline +(`openapi-paths-to-hugo-data/index.ts`) extracts this into `compatVersion` +in the article frontmatter, which templates use to render version badges. + +**Authentication tags** are a special case — they use `|` (literal scalar) +for the description because they contain a markdown list and +``, which renders the API's +security scheme definitions inline. Security scheme anchor names vary by +product: + +| Product family | Scheme anchors | +| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | +| v3 (Core, Enterprise, Dedicated, Serverless, Clustered) | `TokenAuthentication`, `BearerAuthentication`, `BasicAuthentication`, `QuerystringAuthentication` | +| v2 (Cloud, OSS v2) | `TokenAuthentication`, `BasicAuthentication`, `QuerystringAuthentication` | +| v1 (OSS v1, Enterprise v1) | `BasicAuth`, `QueryAuth`, `TokenAuth` | + +#### Writing tag descriptions + +- Start with a verb phrase describing what the endpoints do + (e.g., "Create and manage...", "Write time series data...", "Query data...") +- Include the full product name on first reference + (e.g., "InfluxDB 3 Core", "InfluxDB Cloud", "InfluxDB Enterprise v1") +- Keep descriptions to 2-3 lines (folded scalar `>` handles wrapping) +- Don't include documentation links in descriptions — use `x-related` instead +- For management API tags, don't repeat links that are in the main product's + data API tags + +#### Content overlay discovery + +The post-processor looks for content files in two locations, in order: + +1. **Spec directory**: `{specDir}/content/{file}` (e.g., `influxdb3/core/content/info.yml`) +2. **Product directory fallback**: `{productDir}/content/{file}` (e.g., `influxdb3/core/content/info.yml`) + +For products with multiple APIs (e.g., Cloud Dedicated has both data and +management APIs), the spec-specific directory takes precedence. + +| Overlay | Behavior | +| ------------- | ---------------------------------------------------------------------------------------- | +| `info.yml` | Merges each field into `spec.info`, preserving fields not in the overlay | +| `servers.yml` | Replaces `spec.servers` entirely | +| `tags.yml` | Colocated with spec (not in `content/`). Renames tags, sets descriptions and `x-related` | + +#### Reviewing tags across products + +When editing tags, check consistency across related products: + +- **Core and Enterprise** share the same spec structure — their tags should + use parallel descriptions (swap product name only) +- **Cloud Dedicated and Clustered** share management API tags — keep + descriptions and `x-related` links parallel +- **Cloud v2 and OSS v2** share most tags — Cloud omits a few OSS-only tags + (Backup, Restore, Scraper Targets) and adds Cloud-only tags (Limits, Usage, + Invokable Scripts) +- **OSS v1 and Enterprise v1** are similar — Enterprise adds the `consistency` + parameter note in Write and cluster-specific language ## Documentation links in OpenAPI specs diff --git a/api-docs/enterprise_influxdb/v1/influxdb-enterprise-v1-openapi.yaml b/api-docs/enterprise_influxdb/v1/influxdb-enterprise-v1-openapi.yaml index a632913e5..b1ceb7d07 100644 --- a/api-docs/enterprise_influxdb/v1/influxdb-enterprise-v1-openapi.yaml +++ b/api-docs/enterprise_influxdb/v1/influxdb-enterprise-v1-openapi.yaml @@ -1,7 +1,7 @@ openapi: 3.0.0 info: title: InfluxDB Enterprise v1 HTTP API - version: 1.11.6 + version: 1.12.2 description: | The InfluxDB Enterprise v1 HTTP API provides a simple way to interact with the database. It uses HTTP response codes, authentication with username and password credentials @@ -132,9 +132,9 @@ paths: description: | Check the health of your InfluxDB Enterprise instance. Returns health status as JSON with a `pass` or `fail` status. + x-compatibility-version: v2 tags: - System Information - - v2 Compatibility responses: '200': description: Server is healthy @@ -146,7 +146,7 @@ paths: name: influxdb message: ready for queries and writes status: pass - version: 1.11.6 + version: 1.12.2 '503': description: Server is unhealthy content: @@ -157,7 +157,7 @@ paths: name: influxdb message: service unavailable status: fail - version: 1.11.6 + version: 1.12.2 /query: get: operationId: GetQuery @@ -595,8 +595,8 @@ paths: - `Accept: application/csv` - `Content-type: application/vnd.flux` - `Authorization: Token username:password` (if authentication is enabled) + x-compatibility-version: v2 tags: - - v2 Compatibility - Query security: - TokenAuth: [] @@ -637,8 +637,8 @@ paths: - `database/` or `database` - default retention policy The `org` parameter is ignored in InfluxDB Enterprise 1.x. + x-compatibility-version: v2 tags: - - v2 Compatibility - Write security: - TokenAuth: [] @@ -697,6 +697,7 @@ paths: description: | List all databases as buckets. Provides forward compatibility with InfluxDB 2.x client libraries. + x-compatibility-version: v2 tags: - v2 Compatibility security: @@ -720,6 +721,7 @@ paths: description: | Create a new database as a bucket. Provides forward compatibility with InfluxDB 2.x client libraries. + x-compatibility-version: v2 tags: - v2 Compatibility security: @@ -750,6 +752,7 @@ paths: description: | Delete a database/retention policy combination. The bucketID format is `database/retention-policy`. + x-compatibility-version: v2 tags: - v2 Compatibility security: @@ -792,6 +795,7 @@ paths: See [delete predicate syntax](/influxdb/v2/reference/syntax/delete-predicate/) for detailed syntax and [limitations](/influxdb/v2/reference/syntax/delete-predicate/#limitations). + x-compatibility-version: v2 tags: - v2 Compatibility security: @@ -847,6 +851,88 @@ paths: application/json: schema: $ref: '#/components/schemas/Error' + /shard-status: + get: + operationId: GetShardStatus + summary: Get shard status + description: | + **Enterprise only.** Retrieve information about all shards on the data + node, including shard ID, size, hot status, and anti-entropy state. + tags: + - System Information + responses: + '200': + description: Shard status for all databases + content: + application/json: + schema: + type: object + properties: + databases: + type: array + items: + type: object + properties: + name: + type: string + description: Database name + retention_policies: + type: array + items: + type: object + properties: + name: + type: string + description: Retention policy name + replication_factor: + type: integer + description: Replication factor + shards: + type: array + items: + type: object + properties: + id: + type: integer + description: Shard ID + size: + type: integer + description: Size on disk in bytes + is_hot: + type: boolean + description: Whether the shard's time range includes `now` + state: + type: string + description: Anti-entropy status + enum: + - healthy + - restore pending + - restoring + - repairing + - error processing + example: + databases: + - name: _internal + retention_policies: + - name: monitor + replication_factor: 1 + shards: + - id: 2 + size: 594491 + is_hot: true + - name: mydb + retention_policies: + - name: autogen + replication_factor: 1 + shards: + - id: 3 + is_hot: false + - id: 6 + size: 1921 + is_hot: false + - id: 11 + is_hot: true + state: healthy components: securitySchemes: BasicAuth: @@ -972,7 +1058,7 @@ components: - fail version: type: string - example: 1.11.6 + example: 1.12.2 QueryResponse: type: object properties: diff --git a/api-docs/influxdb/v1/influxdb-oss-v1-openapi.yaml b/api-docs/influxdb/v1/influxdb-oss-v1-openapi.yaml index 1cf5746cd..19cce86fc 100644 --- a/api-docs/influxdb/v1/influxdb-oss-v1-openapi.yaml +++ b/api-docs/influxdb/v1/influxdb-oss-v1-openapi.yaml @@ -136,9 +136,9 @@ paths: description: | Check the health of your InfluxDB instance. Returns health status as JSON with a `pass` or `fail` status. + x-compatibility-version: v2 tags: - System Information - - v2 Compatibility responses: '200': description: Server is healthy @@ -583,8 +583,8 @@ paths: - `Accept: application/csv` - `Content-type: application/vnd.flux` - `Authorization: Token username:password` (if authentication is enabled) + x-compatibility-version: v2 tags: - - v2 Compatibility - Query security: - TokenAuth: [] @@ -625,8 +625,8 @@ paths: - `database/` or `database` - default retention policy The `org` parameter is ignored in InfluxDB 1.x. + x-compatibility-version: v2 tags: - - v2 Compatibility - Write security: - TokenAuth: [] @@ -685,6 +685,7 @@ paths: description: | List all databases as buckets. Provides forward compatibility with InfluxDB 2.x client libraries. + x-compatibility-version: v2 tags: - v2 Compatibility security: @@ -708,6 +709,7 @@ paths: description: | Create a new database as a bucket. Provides forward compatibility with InfluxDB 2.x client libraries. + x-compatibility-version: v2 tags: - v2 Compatibility security: @@ -738,6 +740,7 @@ paths: description: | Delete a database/retention policy combination. The bucketID format is `database/retention-policy`. + x-compatibility-version: v2 tags: - v2 Compatibility security: @@ -780,6 +783,7 @@ paths: See [delete predicate syntax](/influxdb/v2/reference/syntax/delete-predicate/) for detailed syntax and [limitations](/influxdb/v2/reference/syntax/delete-predicate/#limitations). + x-compatibility-version: v2 tags: - v2 Compatibility security: