@grepr/cli 1.2.0 → 1.3.0-4e666db

package/build/dist/docs-index/04c60541-1fbe-4efe-941d-d7776306a66f.txt

@@ -1,44 +0,0 @@
-# ReadNewRelic
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-  description: Name of the integration.
-
-- name: version (required)
-  type: integer
-  description: Version of the integration. Should be increased by one for every new update in order for the write to succeed. Otherwise, a '409 Conflict' will be returned.
-
-- name: payload (required)
-  type: `NewRelic`
-
-- name: teamIds (optional)
-  type: array of string
-  description: The team IDs that this integration is associated with.
-
-- name: id (required)
-  type: string
-  description: The integration id
-
-- name: organizationId (required)
-  type: string
-  description: Organization ID of the integration.
-
-- name: jobIds (required)
-  type: array of string
-  description: List of job IDs associated with the integration.
-
-- name: createdAt (required)
-  type: string
-  description: Timestamp when the integration was created.
-
-- name: updatedAt (required)
-  type: string
-  description: Timestamp when the integration was last updated.
-
-- name: type (required)
-  type: enum: `newrelic`
-  description: The type of the integration. This is used to determine the payload type.

package/build/dist/docs-index/0511dbf1-5421-49ef-9880-138e8758e663.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/0511dbf1-5421-49ef-9880-138e8758e663.txt

@@ -1,8 +0,0 @@
-# ItemsCollectionTemplate
-
-**Type**: `object`
-
-## Properties
-
-- name: items (optional)
-  type: array of `Template`

package/build/dist/docs-index/0588031b-e2d4-4214-a67d-8f56c49205c0.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/0588031b-e2d4-4214-a67d-8f56c49205c0.txt

@@ -1,18 +0,0 @@
-# Create a Grepr API Key
-
-**POST** `/v1/apikey`
-
-**Operation ID**: `createGreprApiKey`
-**Summary**: Create a Grepr API Key
-## Tags
-- Grepr API Key
-## Responses
-
-### 201
-
-API key created successfully
-
-- **Content-Type**: `application/json` / `GreprApiKey`
-### 401
-
-API key is invalid

package/build/dist/docs-index/07e3ec1d-db6e-4763-a251-0080b7380c80.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/07e3ec1d-db6e-4763-a251-0080b7380c80.txt

@@ -1,24 +0,0 @@
-# Get Organization
-
-**GET** `/v1/organization`
-
-**Operation ID**: `getOrganization`
-**Summary**: Get Organization
-Get the organization to which the authenticated user belongs.
-
-## Tags
-- Organizations
-## Responses
-
-### 200
-
-The organization for the authenticated user.
-
-- **Content-Type**: `application/json` / `Read`
-### 401
-
-Unauthorized
-
-### 404
-
-Not Found

package/build/dist/docs-index/07ea377a-43f3-4eed-8e05-ac5247733983.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/07ea377a-43f3-4eed-8e05-ac5247733983.txt

@@ -1,18 +0,0 @@
-# EventRecord
-
-A streaming event record. Records are newline-separated as per the chunked output standard. Each record will contain a 'state' field and potentially a 'data' field. When the state is 'RUNNING', the 'data' field will be valid. In all other states, the 'data' field will be null.
-
-**Type**: `object`
-
-## Properties
-
-- name: jobState (required)
-  type: enum: `HEARTBEAT`, `RUNNING`, `FAILED`, `FINISHED`, `CANCELLED`, `TIMED_OUT`, `UNKNOWN`, `SCANNED_MAX`
-  description: The state of the job at the time of the record. Also indicates validity of the data field.
-
-- name: data (optional)
-  type: `ReadableData`
-
-- name: heartbeatToken (optional)
-  type: string
-  description: The token that should be used by the client to send a heartbeat back to the server. This will usually only be set for the 'HEARTBEAT' state. Heartbeats back from the client are only required when heartbeatToken is not null.

package/build/dist/docs-index/07f47336-864f-40bf-81d4-219fecefb0a1.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/07f47336-864f-40bf-81d4-219fecefb0a1.txt

@@ -1,27 +0,0 @@
-# getAsyncBatchJobsForJob-hidden
-
-**GET** `/v1/jobs/{id}/jobs`
-
-**Operation ID**: `getAsyncBatchJobsForJob-hidden`
-**Summary**: No summary provided.
-## Tags
-- Jobs
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-- **ruleEngineName** (optional) - query
-  - Type: string
-- **triggerIds** (optional) - query
-  - Type: array of string
-
-## Responses
-
-### 200
-
-Successfully retrieved backfill jobs for org.
-
-- **Content-Type**: `application/json` / array of `ReadJob`
-### 401
-
-Unauthorized

package/build/dist/docs-index/08140ea3-a4e2-4afe-aca9-4e05b45a7f8a.json

@@ -1 +0,0 @@
-{"docType":"doc"}

package/build/dist/docs-index/08140ea3-a4e2-4afe-aca9-4e05b45a7f8a.txt

@@ -1,259 +0,0 @@
----
-description: Learn how to use the Grepr Splunk integration to ingest logs to a Grepr pipeline for processing and send the processed logs to your Splunk instance.
----
-
-import { Callout } from 'nextra/components'
-import AddTeamAccess from '@/app/shared/add-team-access-to-resource.mdx'
-import IngestUrlConfig from '@/app/shared/configure-ingest-url.mdx'
-import IntegrationsInterchangeability from '@/app/shared/integrations-interchangeability.mdx'
-import { Tabs } from 'nextra/components'
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Configure Splunk connections for integration with Grepr
-
-The Grepr Splunk integration enables you to ingest logs into Grepr using a Grepr source, process the logs with a Grepr pipeline, and then send the processed logs to Splunk using a Grepr sink.
-
-The Grepr Splunk integration supports forwarding data through the following interfaces:
-
-- **Splunk's HTTP Event Collector (HEC)**: You can use any collector that supports HEC, including Fluent Bit, Fluentd, and the Splunk OpenTelemetry Collector.
-- **S2S over HTTP**: You can forward data from Splunk Universal Forwarders or Splunk Heavy Forwarders using S2S over HTTP. S2S over TCP is not supported.
-
-To send logs to a Grepr pipeline before forwarding them to your Splunk instance, change your collector configuration to send the logs to a Grepr endpoint URL rather than a Splunk HEC or S2S endpoint.
-
-In addition to using a Splunk integration to ingest log data with a Grepr source and send processed logs to Splunk with a Grepr sink, you can also use a Splunk HTTP source to ingest data from a Splunk instance into Grepr for processing. See [Ingest log data from Splunk using the Splunk HTTP source](#splunk-http-source).
-
-You can use the Grepr UI or REST API to add a Splunk integration. To learn how to create a Splunk integration in the Grepr UI and configure collectors to send logs to Grepr, see [Use a Splunk integration in a Grepr pipeline](#use-splunk-integration).
-
-To use the REST API, see the [Splunk Integration specification](/apis/api-spec#tag/Splunk-Integration).
-
-<Callout>
-  <IntegrationsInterchangeability />
-</Callout>
-
-## Requirements
-
-The Grepr integration for Splunk requires the following:
-
-- An HTTP Event Collector (HEC) token is required for both HEC and S2S. You can create an HEC token in the Splunk platform settings. See [Set up and use the HTTP Event Collector in Splunk Web](https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector).
-- A Bearer token for authentication to the Splunk REST API is required for these Grepr features:
-  - Enabling Grepr to run Splunk queries and use the results of those queries to generate input to the Log Reducer. See [Enable selective reduction with a Splunk integration](#splunk-log-reduction).
-  - Using a Splunk HTTP source to ingest data from a Splunk instance into Grepr. The user associated with the token must have the `search` and `rest_access_server_endpoints` capabilities. See [Ingest log data from Splunk using the Splunk HTTP source](#splunk-http-source).
-
-For details on creating tokens for the Splunk API, see [Create authentication tokens](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/9.4/authenticate-into-the-splunk-platform-with-tokens/create-authentication-tokens).
-
-## Enable selective reduction with a Splunk integration [#splunk-log-reduction]
-
-When your integration configuration includes a bearer token for authenticating to the Splunk REST API, Grepr can submit searches to the Splunk API and use the results of those searches to store exceptions. These exceptions are then made available to the Grepr Log Reducer and used to determine which messages should not be processed by the reducer.
-
-To see a full list of exceptions from the parsed alerts, in the **Observability vendors** section of the **Integrations** page in the Grepr UI, click on the cloud sync icon under **Actions**.
-
-To learn more about the Log Reducer, see [Optimizing logs with Grepr's intelligent aggregation](/grepr-platform/reduction).
-
-## Use a Splunk integration in a Grepr pipeline [#use-splunk-integration]
-
-Use the following steps to create a Splunk integration in the Grepr UI and use it in a pipeline to source and sink data.
-
-### Step 1: Create a Splunk integration [#create-splunk-integration]
-
-To create a Splunk integration in the Grepr UI:
-
-1. Go to the **Integrations** page in the Grepr UI and click **Add new** next to **Observability Vendors**.
-
-   ![The Integrations page in the Grepr UI.](/images/tutorials/first-pipeline/integrations-page.png)
-
-1. In the **Add Observability Vendor** dialog:
-   - In the **Type** menu, select **Splunk** .
-   - In the **Name** field, enter a name for the integration.
-   - In the **Ingest Auth token** field, enter your Splunk HEC token.
-   - In the **Splunk Host** field, enter the hostname for your Splunk instance.
-   - (Optional) In the **REST API Search Bearer token** field, enter a Bearer token to authenticate against the Splunk API. Configuring this token allows Grepr to query your Splunk instance. The Grepr platform uses the results of these queries to store exceptions for input to the log reduction step of your pipeline. See [Enable selective reduction with a Splunk integration](#splunk-log-reduction).
-   - (Optional) Use the **Validate SSL certificate** checkbox to turn validation of SSL certificates on or off when Grepr connects to your Splunk instance.
-1. Click **Create**.
-
-   ![Add a Splunk integration in the Grepr UI.](/images/tutorials/first-pipeline/integrations-new-splunk.png)
-
-    #### (Optional) Grant team access to the integration
-
-    <AddTeamAccess resource_type='integration' />
-
-### Step 2: Add a source to your pipeline [#add-splunk-source]
-
-To add a source to your pipeline that uses the Splunk integration:
-
-1. In the Grepr UI, go to the overview page for an existing pipeline or create a new pipeline from the homepage.
-1. In the left-hand navigation menu on the pipeline overview page, click **Sources**.
-1. In the **Add source** dialog, select the Splunk integration in the **Source** menu.
-1. Click **Submit**.
-
-### Step 3: Forward logs to Grepr using HEC
-
-<IngestUrlConfig image_url='/images/integrations/ingestion-url-splunk.png' url='https://<integration-id>-<org-id>.ingest.grepr.ai/services/collector/event' />
-
-To see more information and configuration examples, select the tab for your preferred collector:
-
-<Tabs items={['Fluent Bit', 'Fluentd', 'OpenTelemetry Collector']}>
-  <Tabs.Tab>
-
-    Fluent Bit can forward logs using the Splunk output plugin. To configure the plugin, set the `Host` value to the hostname of the ingestion URL from the integration and the `Splunk_Token` value to your Splunk HEC token. The following is an example `OUTPUT` section from a Fluent Bit configuration file (`fluent-bit.conf`):
-
-    ```fluent
-    [OUTPUT]
-       Name              splunk
-       Match             *
-       Host              <ingestion-host>
-       Port              443
-       TLS               On
-       TLS.Verify        On
-       Splunk_Token      <hec-token>
-    ```
-
-    Replace:
-    - - `<ingestion-host>` with the hostname from your ingestion URL. Do not include the `https://` prefix or the path value. For example, if the ingestion URL is `https://0abc1defghij2-<org-id>.ingest.grepr.ai/services/collector/event`, set the value to `0abc1defghij2-<org-id>.ingest.grepr.ai`.
-    - `<hec-token>` with your Splunk HEC token.
-
-    To learn more about configuration settings for Fluent Bit, see the documentation for the [Fluent Bit Splunk output plugin](https://docs.fluentbit.io/manual/pipeline/outputs/splunk).
-
-  </Tabs.Tab>
-
-  <Tabs.Tab>
-
-    Fluentd can send logs to Grepr using the `splunk_hec` output plugin. When you configure Fluentd, split the ingestion URL into the `hec_host`, `hec_port`, and `hec_endpoint` settings. The following is an example `match` directive from a Fluentd configuration file (`fluentd.conf`):
-
-    ```fluent
-    <match your_tag.**> # Adjust your match pattern as needed
-      @type                     splunk_hec
-      protocol                  https
-      hec_host                  <ingestion-host>
-      hec_endpoint              services/collector/event
-      hec_port                  443
-      hec_token                 <hec-token>
-
-      <buffer> # Buffer configuration is recommended for production
-        @type memory # Or file for persistence
-        flush_interval 5s # Adjust as needed
-        chunk_limit_size 1m # Adjust as needed
-      </buffer>
-    </match>
-    ```
-
-    Replace:
-    - `your_tag.**` with the tag of the logs you want to forward to Grepr or use `**` to match all tags.
-    - `<ingestion-host>` with the hostname from your ingestion URL. Do not include the `https://` prefix or the path value. For example, if the ingestion URL is `https://0abc1defghij2-<org-id>.ingest.grepr.ai/services/collector/event`, set the value to `0abc1defghij2-<org-id>.ingest.grepr.ai`.
-    - `<hec-token>` with your Splunk HEC token.
-
-    To learn more about the Splunk output plugin for Fluentd, including configuration settings, see the [fluent-plugin-splunk-hec documentation](https://github.com/splunk/fluent-plugin-splunk-hec#readme).
-
-  </Tabs.Tab>
-
-  <Tabs.Tab>
-
-    The OpenTelemetry Collector can forward logs to Grepr using the `splunk_hec` exporter. In the OpenTelemetry collector configuration (`collector.yaml`), set the `endpoint` value to the ingestion URL:
-
-    ```yaml
-    exporters:
-      splunk_hec:
-        token: <hec-token>
-        endpoint: <ingestion-url>
-
-    service:
-      pipelines:
-        logs:
-          receivers: [otlp] # Replace with your actual receiver(s)
-          processors: [batch] # Replace/add your actual processor(s)
-          exporters: [splunk_hec]
-    ```
-
-    Replace:
-    - `<hec-token>` with your Splunk HEC token.
-    - `<ingestion-url>` with the ingestion URL from your Splunk integration.
-
-    To learn more about the OpenTelemetry Collector and configuration settings, see the [Splunk HEC Exporter documentation](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/splunkhecexporter#readme).
-
-  </Tabs.Tab>
-</Tabs>
-
-### Forward logs to Grepr using the Splunk Universal Forwarder or Heavy Forwarder
-
-To forward logs to Grepr using the Splunk Universal Forwarder or Heavy Forwarder:
-
-1. Add an `[httpout]` section to your Splunk Heavy Forwarder or Universal Forwarder outputs configuration (`outputs.conf`) with the following settings:
-   - Set `httpEventCollectorToken` with an HEC token from your Splunk settings.
-   - Set `uri` to the hostname of the ingestion URL from your Grepr source. Omit the path from the ingestion URL and append port `443` to the URL. The following is an example of a properly formatted value for the `uri` setting: `https://q0yf61xl3k2b1-orgid.app.grepr.ai:443`.
-1. To load the new configuration, restart your forwarders.
-
-### Step 4: Add a sink to your pipeline
-
-To add a sink to your pipeline that uses the Splunk integration to send processed logs to your Splunk instance:
-
-1. In the Grepr UI, go to the overview page for your pipeline.
-1. In the left-hand navigation menu, click **Sinks**.
-1. In the **Add sink** dialog:
-   - Select the Splunk integration in the **Sink** menu.
-   - In the **Name** field, enter a name for the integration.
-   - In the **Additional tags** field, specify comma-separated tags to add to all log messages sent through this sink. These tags can be used for filtering and organizing logs in Splunk. For example: `processor:grepr,pipeline:my_pipeline,environment:production`.
-1. The **Index Configuration** section allows you to configure how logs are routed to Splunk indexes. Grepr follows a specific index routing logic to determine the destination index for each log:
-   - **Index override takes priority**: If an **Index override** value is provided, all logs flowing to this sink will use this index, regardless of any other index information.
-   - **Log-level index field**: If no **Index override** value is provided and an `index` field exists on the log (from an agent or transformations), that index will be used.
-   - **Sink default index**: If no **Index override** value is provided and no `index` field exists on the log, the **Default index** field specified in this sink configuration will be used.
-   - **HEC token default**: If none of the above conditions are met, the log is routed to the default index configured on the HEC token in your Splunk instance.
-1. Click **Submit**.
-
-   ![Configure a Splunk sink in the Grepr UI.](/images/integrations/splunk-sink.png)
-
-## Ingest log data from Splunk using the Splunk HTTP source [#splunk-http-source]
-
-You can use the Splunk HTTP source to read log data from a Splunk instance into Grepr. You can use this feature for tasks such as moving logs from Splunk to another platform or to test Splunk log processing in Grepr without modifying forwarders.
-
-To configure and use a Splunk HTTP source in a pipeline:
-
-1. Create a Splunk integration that includes an authorization token for the Splunk REST API. See [Step 1: Create a Splunk integration](#create-splunk-integration).
-1. In your pipeline, add a server source that uses the Splunk integration. See [Step 2: Add a source to your pipeline](#add-splunk-source).
-
-## Limitations
-
-- The Splunk integration supports only Splunk HEC and S2S over HTTP. TCP connections, including S2S over TCP, are not supported.
-
-<HiddenFAQ
-  faqs={[
-    {
-      q: "How do I send logs from Splunk to Grepr for processing?",
-      a: "To send logs from Splunk to Grepr, change your collector configuration to send logs to the Grepr ingestion URL instead of your Splunk HEC endpoint. The ingestion URL format is https://<integration-id>-<org-id>.ingest.grepr.ai/services/collector/event. You can configure Fluent Bit, Fluentd, OpenTelemetry Collector, or Splunk Universal/Heavy Forwarders to use this endpoint."
-    },
-    {
-      q: "What is the difference between HEC and S2S for Splunk integration with Grepr?",
-      a: "HEC (HTTP Event Collector) is Splunk's standard HTTP-based log ingestion method supported by multiple collectors like Fluent Bit, Fluentd, and OpenTelemetry Collector. S2S (Source-to-Source) is Splunk's forwarding protocol for Universal Forwarders and Heavy Forwarders. Both are supported by Grepr over HTTP, but TCP connections including S2S over TCP are not supported."
-    },
-    {
-      q: "How do I configure Fluent Bit to forward logs to Grepr with a Splunk integration?",
-      a: "In your Fluent Bit configuration file, create an OUTPUT section with Name set to 'splunk', Host set to your Grepr ingestion hostname, Port set to 443, TLS enabled, and Splunk_Token set to your Splunk HEC token. The Host value should be the hostname portion of your ingestion URL without the https:// prefix or path."
-    },
-    {
-      q: "What is the Splunk Log Reducer feature in Grepr?",
-      a: "When you configure a Splunk integration with a Bearer token for the Splunk REST API, Grepr can submit searches to Splunk and use the results to store exceptions. The Log Reducer uses these exceptions to determine which log messages should not be processed, helping optimize log aggregation and reduce storage costs."
-    },
-    {
-      q: "How do I enable automatic exception parsing from Splunk alerts and dashboards?",
-      a: "To enable exception parsing, include a Bearer token for the Splunk REST API when creating your Splunk integration. The associated user must have 'search' and 'rest_access_server_endpoints' capabilities. Grepr will automatically parse queries from your Splunk alerts and dashboards and make them available to the Log Reducer."
-    },
-    {
-      q: "How can I configure index routing when sending processed logs back to Splunk?",
-      a: "When adding a Splunk sink, Grepr follows a priority order for index routing: first, any Index override value; second, the index field on the log itself; third, the Default index specified in the sink configuration; finally, the default index configured on your HEC token. You can set an Index override to route all logs to a specific index regardless of other settings."
-    },
-    {
-      q: "Can I use Splunk Universal Forwarder or Heavy Forwarder to send logs to Grepr?",
-      a: "Yes, you can use S2S over HTTP with Splunk Universal Forwarder or Heavy Forwarder. Add an httpout section to your outputs.conf with the Grepr ingestion URL, an HEC token, and port 443. TCP connections are not supported, so ensure you use HTTP/HTTPS endpoints only."
-    },
-    {
-      q: "What authentication is required for the Splunk integration with Grepr?",
-      a: "You need an HEC (HTTP Event Collector) token from Splunk for both HEC and S2S connections. Additionally, for log reduction and exception parsing features, you need a Bearer token for the Splunk REST API with search and rest_access_server_endpoints capabilities."
-    },
-    {
-      q: "How do I reduce storage costs with Grepr's Splunk integration?",
-      a: "Use the Log Reducer feature by configuring a Bearer token in your Splunk integration. Grepr queries your Splunk instance for alerts and dashboards, then uses those insights to identify and exclude redundant log messages from processing. This can significantly reduce the volume of logs stored and processed."
-    },
-    {
-      q: "Can I send logs to both Grepr and Splunk directly from my collectors?",
-      a: "Yes, you can dual-ship logs using multiple OUTPUT sections in Fluent Bit or multiple exporters in Fluentd and OpenTelemetry Collector. This allows you to send unprocessed logs directly to Splunk while simultaneously sending logs to Grepr for processing and transformation."
-    }
-  ]}
-/>

package/build/dist/docs-index/08319098-e760-4698-bf6c-a4b0ccf6b931.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/08319098-e760-4698-bf6c-a4b0ccf6b931.txt

@@ -1,51 +0,0 @@
-# GreprReducerLogSource
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: start (required)
-  type: string
-  description: Start of time interval to query data for.
-
-- name: end (required)
-  type: string
-  description: End of time interval to query data for.
-
-- name: query (required)
-  type: `query`
-
-- name: variables (optional)
-  type: object
-  description: Variables that can be used to modify the query while parsed
-
-- name: offset (optional)
-  type: integer
-  description: Offset on the number of rows to process
-
-- name: limit (optional)
-  type: integer
-  description: The maximum number of rows to process
-
-- name: sortOrder (optional)
-  type: enum: `ASCENDING`, `DESCENDING`, `UNSORTED`
-  description: The order in which the rows should be sorted by
-
-- name: datasetId (required)
-  type: string
-  description: The ID of the dataset to read data from.
-
-- name: processedLogsTableName (optional)
-  type: string
-  description: The name of the table containing processed logs.
-
-- name: reductionInterval (required)
-  type: string
-  description: The interval used by the Log Reducer for the query. Uses ISO 8601 format for intervals.
-
-- name: type (required)
-  type: enum: `grepr-reducer-log-source`
-  description: Reads events using Grepr's internal query system out of an Iceberg Table for processing.

package/build/dist/docs-index/08588224-3f9b-438f-9ce0-e732ee3abacd.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/08588224-3f9b-438f-9ce0-e732ee3abacd.txt

@@ -1,23 +0,0 @@
-# S3DataWarehouse
-
-The payload containing integration data.
-
-**Type**: `object`
-
-## Properties
-
-- name: bucketName (required)
-  type: string
-  description: The name of the S3 bucket to use for the data warehouse
-
-- name: assumeRoleArn (optional)
-  type: string
-  description: The ARN of the role to assume when accessing the S3 bucket
-
-- name: region (optional)
-  type: string
-  description: The region of the S3 bucket
-
-- name: prefix (optional)
-  type: string
-  description: The prefix (folder) within the S3 bucket where data warehouse files will be stored

package/build/dist/docs-index/08ffc9d2-cf9e-47fb-b2e1-eb062c642a0e.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/08ffc9d2-cf9e-47fb-b2e1-eb062c642a0e.txt

@@ -1,8 +0,0 @@
-# QueryParsingError
-
-**Type**: `object`
-
-## Properties
-
-- name: message (required)
-  type: string

package/build/dist/docs-index/0947927f-d039-40ab-88a3-fc7b5bbbda49.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/0947927f-d039-40ab-88a3-fc7b5bbbda49.txt

@@ -1,47 +0,0 @@
-# Update an Asynchronous Streaming Job
-
-**PUT** `/v1/jobs/{id}`
-
-**Operation ID**: `updateJob`
-**Summary**: Update an Asynchronous Streaming Job
-Updates an asynchronous streaming job. This is an asynchronous operation which returns an identifier (field: id) for the job to be created, in the response. The id can be used to query the status of the job using the GET jobs endpoint. If a change in the job graph is detected, a new version of the job will be created and sent back in the response object. Job update lifecycle is represented by the state field in the GET response. Following states can be expected in the response:
- - PENDING:        Job is in the process of being updated.
- - RUNNING:        Job is running.
- - STOPPED:        Job is stopped.
- - FAILED:         Job update failed.
- - INFRA_UPDATE:   Job is undergoing an infra change.
-
-## Tags
-- Jobs
-## Parameters
-
-- **id** (required) - path
-  - Id of the job to update
-  - Type: string
-- **rollbackEnabled** (optional) - query
-  - If set to true, the rollback path will be enabled if this job update fails.
-  - Type: boolean
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `UpdateJob`
-
-## Responses
-
-### 202
-
-Job updated successfully
-
-### 401
-
-Unauthorized
-
-### 404
-
-Job not found.
-
-### 409
-
-Job update failed due a conflicting update request.

package/build/dist/docs-index/094dec7d-ab3f-42ce-bc9b-8a1eed3647ac.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/094dec7d-ab3f-42ce-bc9b-8a1eed3647ac.txt

@@ -1,36 +0,0 @@
-# Submit an Asynchronous Job
-
-**POST** `/v1/jobs/async`
-
-**Operation ID**: `submitAsyncJob`
-**Summary**: Submit an Asynchronous Job
-Submit an async job (`streaming` or `batch`). This is an asynchronous operation which returns an identifier (field: `id`) for the job to be created, in the response. The id can be used to query the status of the job using the `GET` jobs endpoint. Job creation lifecycle is represented by the state field in the `GET` response. States represent the following:
- - `PENDING`: Job has been successfully accepted for submission
- - `WAITING`: Job is waiting on other jobs to finish to be submitted.
- - `STARTING`: Job is being transitioned to the `RUNNING` state.
- - `RUNNING`: Job is running.
- - `FAILED` : Job creation failed.
-
-
-## Tags
-- Jobs
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: `CreateJob`
-
-## Responses
-
-### 201
-
-Async job submitted successfully
-
-- **Content-Type**: `application/json` / `ReadJob`
-### 400
-
-Bad Request
-
-### 401
-
-Unauthorized

package/build/dist/docs-index/0974afe1-8b2d-4647-8a8d-b5891201e8e9.json

@@ -1 +0,0 @@
-{"docType":"schema"}