NexoQuerySizeLimit
:::danger Installed but not an effective production contract
The installed CRD schema exposes no limit fields; reconciliation can validate only an empty spec and cannot establish an enforceable limit.
:::
This page documents the current development contract. Schema acceptance, Operator reconciliation, and runtime enforcement are separate claims; the status above is authoritative.
API identity
| Property | Value |
|---|---|
| Kind | NexoQuerySizeLimit |
| API group | nexo.io |
| Version | v1alpha1 |
| Resource | nexoquerysizelimits |
| Short name | nqsl |
| Scope | Namespaced |
| Operator support | Installed but not an effective production contract |
Purpose and relationships
Declares query and message size limits.
It has runtime effect only when a NexoPipeline referenced by a NexoProxy includes this object in a compatible phase and the selected Operator/runtime bundle supports the contract.
Spec field reference
The table is derived from the installed Nexo Edge CRD OpenAPI schema. “Not declared” means the schema publishes no default. A missing schema description is reported explicitly rather than inferred from implementation.
The CRD schema declares an object but no configurable fields.
Status fields and conditions
| Field | Type | Required | Default | Schema description |
|---|---|---|---|---|
status.ready | boolean | No | Not declared | No description is declared in the CRD schema. |
status.configHash | string | No | Not declared | No description is declared in the CRD schema. |
A Ready or configHash value proves that the Operator accepted/hashed the object; it does not by itself prove runtime execution or policy enforcement.
Reconciliation and watch behavior
The registered controller validates the resource and records status. Data-path changes are applied only when the relevant NexoProxy controller rebuilds or reloads the owning graph.
At startup, the current NexoProxy controller installs a typed watch when the CRD is discoverable. A CRD installed after Operator startup requires an Operator restart before that reference watch is added.
Runtime execution effect
The installed CRD schema exposes no limit fields; reconciliation can validate only an empty spec and cannot establish an enforceable limit.
Example
Use placeholders and validate in a non-production namespace first. For schema-only or ineffective kinds, this example is for schema inspection only and must not be used as evidence of enforcement.
apiVersion: nexo.io/v1alpha1
kind: NexoQuerySizeLimit
metadata:
name: <size-limit-name>
namespace: <namespace>
spec: {}
Update and reconciliation caveats
- Apply component and pipeline changes before expecting the owning NexoProxy graph to change.
- Check metadata.generation, status.observedGeneration when present, and the owning Proxy graphRevision/appliedRevision after every update.
- A successful kubectl apply proves only schema admission; inspect Operator conditions, generated configuration, rollout state, and runtime behavior separately.
Release-specific limitations
- The API is v1alpha1 and has no conversion webhook or second served version.
- The CRD schema is retained by Helm and can outlive the Operator release that installed it.
- Current documentation can describe unreleased development behavior; verify the exact deployed bundle and image digests.
- The schema exposes no spec fields, so an accepted empty object does not configure useful policy.
Inspect with kubectl
kubectl get nexoquerysizelimits --namespace <namespace>
kubectl describe nexoquerysizelimits <name> --namespace <namespace>
kubectl get nexoquerysizelimits <name> --namespace <namespace> -o yaml
kubectl get crd nexoquerysizelimits.nexo.io -o yaml
For resources participating in a Proxy graph, also inspect:
kubectl get nexoproxy <proxy-name> --namespace <namespace> \
-o jsonpath='{.status.phase}{" graph="}{.status.graphRevision}{" applied="}{.status.appliedRevision}{"\n"}'
kubectl get nexopipeline <pipeline-name> --namespace <namespace> -o yaml