# Spinifex cloud-init datasource pin, shared by every system-VM image.
# The installed name differs by image and the prefix is load-bearing:
# read_conf_d() applies cloud.cfg.d in REVERSE and mergemanydict() is
# first-source-wins, so a 90- name loses to cloud-init's own 90_dpkg.cfg
# ('_' sorts above '-') and is silently discarded. The vllm profile installs
# it as 99-spinifex-ec2-imds.cfg for that reason.
#
# The system VM's user-data is delivered only via IMDS (the NoCloud seed
# was retired in #411), and IMDS (169.254.169.254) is reachable only once
# mulga-mgmt-net has brought up the data NIC via DHCP and the per-tap
# br-imds datapath has reconciled. On the first-launched (primary) control
# plane that datapath can lag cloud-init's stock 120s probe window, so with
# the default max_wait cloud-init gives up and falls back to DataSourceNone
# — permanently losing the launch user-data (no SPINIFEX_K3S_ROLE → no k3s
# server). Raise max_wait so cloud-init keeps polling IMDS until the
# datapath is ready instead of falling through to None.
datasource_list: [ Ec2, None ]
datasource:
  Ec2:
    # Poll IMDS up to 10 min (default 120s). Well past the ~264s at which
    # the datapath became reachable in the observed race; a slow boot, never
    # a lost role.
    max_wait: 600
    timeout: 20
    # DMI is spoofed to an ec2 id by the launcher; don't abort if a strict
    # id check ever misfires.
    strict_id: false
    metadata_urls:
      - http://169.254.169.254