Skip to content

[Ingest Manager]Split OpenAPI spec file into multiple files #77290

@jfsiii

Description

@jfsiii

The current one is 4000+ lines of JSON. That makes it intimidating/challenging to edit, review, etc.

I think the strawman is a layout like

├── components
│   ├── parameters
│   ├── responses
│   ├── schemas
│   └── securitySchemes
├── paths
├── spec_refs.json
└── spec_bundled.json

and we use $refs to link between them. e.g. The paths section of the spec file would paths/* look like

"paths": {
    ...snip
    "/package_policies": {
      "$ref": "paths/package_policies.json"
    },
    "/package_policies/{packagePolicyId}": {
      "$ref": "paths/package_policies/{packagePolicyId}.json"
    },
    "/fleet/setup": {
      "$ref": "paths/fleet/setup.json"
    },
    "/epm/packages/{pkgkey}": {
      "$ref": "paths/epm/packages/{pkgkey}.json"
    },
    ...snip
  },
And a file at `paths/package_policies/{packagePolicyId}/post.json` like
{
  "operationId": "post-agent-policy",
  "summary": "Agent policy - Create",
  "parameters": [
    {
      "$ref": "../components/parameters/xsrfHeader.json"
    }
  ],
  "requestBody": {
    "content": {
      "application/json": {
        "schema": {
          "$ref": "../components/schemas/NewAgentPolicy.json"
        }
      }
    }
  },
  "responses": {
    "200": {
      "description": "OK",
      "content": {
        "application/json": {
          "schema": {
            "type": "object",
            "properties": {
              "item": {
                "$ref": "../components/schemas/AgentPolicy.json"
              }
            }
          }
        }
      }
    }
  }
}

Everything will remain OpenAPI & JSON for now. There will be a separate ticket & pass for switching some parts to JSON schema so we can use them in more places (e.g. the route validators like #76546)

We'll also retain single bundled one e.g. spec_bundled.json above (and hopefully a simple yarn or npx command to create it) any tools which don't deal with the multi-file setup

Metadata

Metadata

Assignees

Labels

Team:FleetTeam label for Observability Data Collection Fleet team

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions