Upgrading Hawk¶
This page is for existing deployments. For a new deployment, use the current configuration reference.
Review CPU worker disk sizes¶
hawk:karpenterNodeDataVolumeSize applies to both ordinary and enabled gVisor workers. A string and a one-item list produce the same resources. An existing "2000Gi" setting therefore changes the gVisor root-disk template from 200 to 2,000 GiB. The default "200Gi" keeps both disk sizes unchanged. Disk-template changes can trigger worker replacement; review the preview and finish or drain affected jobs before applying.
hawk:karpenterNodeDataVolumeThroughput and hawk:karpenterNodeDataVolumeIops also apply to gVisor root disks. Existing settings change those templates from gp3 defaults to the configured values and can trigger worker replacement. Unset performance settings keep their defaults.
All values must be positive whole-GiB capacities. A scalar or the first array entry retains its configured spelling, so "1Ti" remains "1Ti" in that disk template. Later entries are normalized to GiB. Review any custom pool preferences and existing quantities. See worker disk pools for multi-size configuration and naming.
Migrating from armImagesEnabled¶
hawk:armImagesEnabled has been removed and superseded by hawk:cpuArchitecture which chooses arm64 by default. If hawk:armImagesEnabled was previously set to false, then set hawk:cpuArchitecture to amd64. Set the new key before removing the old one: a stack with neither key silently defaults to arm64, whereas a lingering armImagesEnabled fails the deploy loudly.
# Keep amd64 if armImagesEnabled was false.
# If it was true, skip this command; arm64 is already the default.
pulumi config set hawk:cpuArchitecture amd64
pulumi config rm hawk:armImagesEnabled
The new hawk:evalTaskArchitecture setting defaults to amd64, so no action is required unless you intentionally move eval task sandboxes to arm64. Make that switch only after every image in each sandbox supports arm64.
Removing multiArchImagesEnabled¶
hawk:multiArchImagesEnabled has also been removed: the runner and janitor images are now built only for hawk:cpuArchitecture instead of an amd64+arm64 manifest list. Deploys fail until the key is gone:
On a dev stack the error can also come from the key lingering in the staging stack's config, which dev stacks inherit when they set no architecture keys of their own — remove it there; pulumi config rm on the dev stack has no effect on an inherited value.
hawk:karpenterNodePoolCpuLimit applies to production stacks¶
Stacks whose hawk:env is prd or production used to ignore this key and leave every NodePool uncapped. It now applies everywhere, and hawk:karpenterNodePoolCpuLimitOverrides sets caps for individual NodePools.
- Key set: its cap applies on the next deploy.
- Key unset: nothing changes, but Pulumi warns that this default is deprecated.
To stay uncapped either way, run this before upgrading:
Review the NodePool CPU limit¶
If a stack sets hawk:karpenterNodePoolCpuLimit, review it before upgrading. The limit applies independently to every NodePool, and this release adds an ARM counterpart to each standard-instance CPU pool. There are two such pools normally (default and default-arm64), or four when gVisor is enabled. Their combined Karpenter ceiling is the sum of their effective caps after applying hawk:karpenterNodePoolCpuLimitOverrides, before the managed Karpenter controller nodes are counted. If any standard-instance CPU pool is unlimited, there is no finite combined ceiling.
If the old value matched the account-wide EC2 On-Demand Standard vCPU quota, lower it so the combined ceiling plus the controller nodes fits that quota:
Choose the cap deliberately rather than blindly dividing: it must still fit at least one eligible node (currently 2 vCPUs). Raise the AWS quota or disable gVisor if the available per-pool budget would be smaller. Pulumi warns with the combined ceiling whenever this key or an override sets these caps.
If you use a custom runner image¶
Most deployments use Hawk's built-in runner and need no action. This applies only to eval sets that specify runner.image or use hawk eval-set --image. A custom runner image must support the deployment's hawk:cpuArchitecture. See Custom Runner Images for configuration details.
CrowdStrike sensor image¶
If hawk:enableCrowdstrike is on, the falcon-sensor DaemonSet must run on both amd64 and arm64 nodes, so the image_tag in the <env>/platform/crowdstrike secret must be a multi-arch tag — available for sensor 7.15 and later, and recognizable as the tag without an architecture component (7.20.0-17306-1.falcon-linux.Release.US-1, not ...falcon-linux.x86_64.Release.US-1). Deploys reject architecture-specific tags at validation; update the secret before upgrading. A single-arch image would otherwise crashloop on the other architecture's nodes and leave them without EDR.