idyl apply - IDYL Docs

Apply resource manifests from a YAML file. The command creates each resource if it does not exist, updates it if the manifest describes something different from what the platform holds, and leaves it alone when the two already agree. Supported kinds are Namespace, Deployment, ReplicaSet, DaemonSet, HostPodSet, Pod, Job, Sandbox, CronJob, Service, WebApp, Gateway, HTTPRoute, TLSRoute, ReferenceGrant, RegistryCredential, Secret, TLSCertificate, Fleet, FleetLease, CloudAccount, Node, and Supervisor. A file can contain multiple YAML documents separated by ---, and they are applied in file order. Pass ”-” as the filename to read the manifest from standard input. A manifest is the complete desired state of the resource it names, not a patch. A field the manifest leaves out is written as empty: omitting a fleet’s spec.provisioning removes its capacity, and omitting a node’s spec.suspended returns it to service. A fleet’s spec.subnet and a node’s spec.fleet are required: a fleet serves the subnet it was created in for its whole life, and a node is always in one fleet. Fields the platform assigns rather than you — a resource’s ID, a cloud connection’s external ID — are carried through from what the platform holds and are never emptied this way. When an apply empties something, it says what. Fleet, FleetLease, and CloudAccount manifests are matched to what the account already holds by metadata.name; a Node manifest is matched by metadata.id. Nodes are never created from a manifest, so a Node manifest naming a node the account does not have is an error. A Supervisor has no name: a Supervisor manifest addresses the Supervisor of its metadata.namespace in its metadata.subnet, or of the selected Namespace and subnet when it states neither. Its spec.placement is fixed at creation, so a manifest stating a different one is refused, and —fleet and —node do not apply to it. Container specs may include imagePullCredentialRef.name for private image pulls. The retired imagePullSecret field is rejected. RegistryCredential manifests must include spec.passwordData with the base64 encoded registry password. Secret and TLSCertificate manifests accept write-only base64 fields. Base64 is not encryption; do not commit manifests containing customer secret material.

Usage

idyl apply -f FILENAME [flags]

Flags

Flag	Description
`-f <string>, --filename <string>`	Required. Path to the manifest file containing the resources to apply, or ”-” for standard input.
`--fleet <string>`	Constrain scheduling to eligible members of this fleet within the workload’s subnet, by fleet ID.
`--node <string>`	Constrain scheduling to this single node within the workload’s subnet, by node ID.
`-o <string>, --output <string>`	Output format: table, json, yaml. Default: `table`.

Inherited flags

Flag	Description
`-a <string>, --account-id <string>`	Account ID to use, overriding the current context.
`-c <string>, --context <string>`	Use the named context for this command.
`--homedir <string>`	Override the configuration directory. Defaults to ~/.config/idyl.
`-n <string>, --namespace <string>`	Namespace to address, overriding the entered context.
`--network <string>`	Override the Network for this command.
`-p <string>, --profile <string>`	Override the access profile for this command.
`-s <string>, --subnet <string>`	Subnet to use for this command, overriding the current context.

Examples

# Apply a Namespace manifest
idyl apply -f namespace.yaml

# Apply a Sandbox manifest
idyl apply -f sandbox.yaml

# Apply multiple resource manifests from one file
idyl apply -f resources.yaml

# Apply a manifest piped in, reporting the result as JSON
cat fleet.yaml | idyl apply -f - -o json

​Usage

​Flags

​Inherited flags

​Examples

Usage

Flags

Inherited flags

Examples