RunOnFlux/flux v8.11.1

on GitHub

Summary

Three related improvements to how FluxOS schedules app spawning and what every app container sees in its environment:

1. Enterprise-network nodes now start spawning apps at T+62m instead of waiting the legacy 125–135m window. Non-enterprise nodes keep the original timing. Identity is read from the boot-time cache; unresolved nodes fall back to non-enterprise scheduling (safe default).
2. Spawn-deferral paths in trySpawningGlobalApplication now behave correctly on enterprise nodes. Tier-mismatch, static-IP, datacenter, and arcane-non-enterprise-app deferrals are skipped (enterprise nodes don't need them), but the target-IP-mismatch branch is preserved so enterprise nodes still
   honor specs that pin a concrete node list.
3. Every app container now receives two Flux-provided env vars — FLUX_NODE_HOST_IP (host's public IP) and FLUX_APP_NAME. Apps can reference them directly or via ${VAR} expansion in config files that support it (e.g. Datadog's DD_HOSTNAME=${FLUX_NODE_HOST_IP}). Appended last, so they win over any
   identically-named operator-supplied values.

Taken together, these change how fast enterprise nodes come online with their assigned workloads, and give operators a standard, zero-spec way to pull host identity into their apps.

Changes by file

• ZelBack/src/services/serviceManager.js — single 62-minute spawn-gate timer; enterprise nodes fire immediately, non-enterprise nodes schedule a second timer for the remaining 63–73m so they land in the original 125–135m window.
• ZelBack/src/services/appLifecycle/appSpawner.js — enterprise nodes bypass the appsToBeCheckedLater deferral block for tier / static-IP / datacenter / arcane-non-enterprise-app reasons, but still defer on target-IP mismatch.
• ZelBack/src/services/dockerService.js — appDockerCreate unconditionally appends FLUX_NODE_HOST_IP and FLUX_APP_NAME to options.Env before container creation. If the node IP cannot be resolved, FLUX_NODE_HOST_IP is skipped with a warning rather than failing the container.

Behavior notes

• Non-enterprise nodes are unchanged for spawn timing and deferral logic.
• Existing apps that don't reference the new env vars are unaffected — duplicate names (if any operator already sets FLUX_NODE_HOST_IP / FLUX_APP_NAME) are overridden by the platform injection because Docker keeps the last value for duplicate env entries.
• target-IP deferral on enterprise nodes is intentional: enterprise app specs can still restrict installs to a listed IP set, and bypassing that would have installed on the wrong nodes.

Test plan

• Boot a non-enterprise node and confirm Starting to spawn applications logs in the original 125–135m window.
• Boot an enterprise node (pubkey in enterpriseNodesPublicKeys) and confirm Starting to spawn applications (enterprise, 62m) at T+62m.
• Install an app on a non-enterprise node whose spec targets a different IP list and confirm it still defers (no regression).
• Install an app on an enterprise node whose spec targets a different IP list and confirm it defers (target-IP branch still effective).
• Install an app on an enterprise node with a tier / static-IP / datacenter / arcane-non-enterprise-app constraint that previously deferred and confirm it no longer defers.
• Exec into a newly-created container and confirm env | grep FLUX_ shows FLUX_NODE_HOST_IP=<host public IP> and FLUX_APP_NAME=<app name>.
• Operator spec that references ${FLUX_NODE_HOST_IP} in a config file (Datadog-style) resolves correctly at app startup.
• Verify ESLint passes on the three touched files.