Apply Manifest
Changed onApply a YAML manifest to create resources.
Creates all resources defined in the manifest file in dependency order.
Modes:
- create_only (default) — fails if any resource already exists.
- create_missing — creates what is missing, leaves what exists alone, and resolves manifest references against the resources ALREADY in the namespace. This is what makes "here is a namespace with buckets, add these collections over them" work. Under create_only a reference to an undeclared-but-existing bucket is a validation error, because the manifest is treated as a closed world.
Plan first: before creating anything, apply runs the same checks as POST /v1/manifest/validate. Any error refuses the whole manifest with success: false, every resource skipped, and each error naming the resource, the field and the fix. Nothing is created. A namespace budget above the organization's bound is set to the bound and reported as a warning.
Features:
- Topological sorting ensures resources are created in correct dependency order
- Secret references (${{ secrets.NAME }}) are resolved from organization secrets
- Atomic operation: rolls back all created resources if any creation fails, and an apply whose process is stopped part way is rolled back when the API starts again
- Dry run returns the plan without making changes
Example:
curl -X POST /v1/manifest/apply \
-H "Authorization: Bearer $API_KEY" \
-H "X-Namespace: ns_xxx" \
-F "manifest_file=@mixpeek.yaml"
Example manifest:
version: "1.0"
metadata:
name: "my-environment"
namespaces:
- name: video_search
feature_extractors:
- name: multimodal_extractor
version: v1
buckets:
- name: raw_videos
namespace: video_search
schema:
properties:
video: { type: video }
Request
- Base URLhttps://api.mixpeek.com
- URLhttps://api.mixpeek.com/v1/manifest/apply
- AuthHTTP bearer
Query parameters
Run the plan only: the same checks as POST /v1/manifest/validate, returned as errors and warnings, with nothing created. Each resource reads would_create, or exists when it is already there. Under mode create_only an existing resource refuses the plan, as it would refuse the apply
Wait up to this many seconds after the resources are created for every Ray Serve app a declared collection needs to be RUNNING (the apps listed in readiness). Past the deadline the result has success false and an error naming the deadline and each app not RUNNING; the resources stay in place. Omit to return as soon as the resources exist.
After the resources exist, wait until every seed: batch has finished (COMPLETED, COMPLETED_WITH_ERRORS, FAILED or CANCELED), within deadline_seconds or 900 seconds when that is omitted. Each batch's status and documents_written are returned in seed_batches; one that failed or did not finish in time is also named in errors. success still reports resource creation only
Implies wait_for_seed and also waits for the Serve apps in readiness. Then runs the manifest's acceptance: steps in order and returns each in acceptance with passed, expected, observed and error. A step that could not run (deadline reached, seed batch failed, Serve apps not RUNNING) is passed false with the reason. The steps are normal executions in your organization and are billed like any query or inference call; acceptance.max_cost_usd is checked against the meter before each step and at the end. Re-apply with mode=create_missing to re-run the steps on a namespace that already exists without creating anything. A manifest with no acceptance: block is refused with 400
Mode for applying manifests.
create_only (default): fail if any resource already exists. create_missing: create what is missing and leave what exists alone, which is what lets a manifest be applied to an EXISTING namespace. create_missing does not UPDATE anything — a resource that exists but differs from the manifest is reported as exists and left untouched. upsert: create what is missing AND patch what exists but differs, so re-applying a manifest brings the running resources back to what it declares. Each resource is patched only through its own update surface, so a field that surface does not accept, or refuses the value of, is reported in refused with the resource and the field named, and the rest of the manifest still applies. Explicit on purpose: this is the only mode that CHANGES resources that already exist.
Request body multipart/form-data
Response
Successful Response
Example response
{
"created_count": 2,
"dry_run": false,
"errors": [],
"failed_count": 0,
"resources": [
{
"name": "video_search",
"resource_id": "ns_abc123",
"resource_type": "namespace",
"status": "created"
},
{
"name": "raw_videos",
"resource_id": "bkt_xyz789",
"resource_type": "bucket",
"status": "created"
}
],
"rollback_performed": false,
"skipped_count": 0,
"success": true
}Changes
- info
added the new optional
queryrequest parameterrun_acceptance - info
added the new optional
queryrequest parameterwait_for_seed - info
added the optional property
to the response with the status - info
added the optional property
//to the response with the status - info
added the optional property
to the response with the status
- info
- warning
added the new
pendingenum value to the//response property for the response status - info
added the optional property
//to the response with the status
- warning