From 55e15c6644759edc8b1fba342eb785967633502e Mon Sep 17 00:00:00 2001 From: Jason Frey Date: Fri, 13 Oct 2023 22:03:44 -0400 Subject: [PATCH] Fix issue where new service account ENV var is forced in every process ManageIQ::Providers::Workflows::Engine.floe_docker_runner is called in a config/initializer, which means that it is being executed in every Rails environment on boot. This includes things like `bin/rake evm:deployment_status`, which happens very early on in the orchestrator boot process. When the orchestrator is on Kubernetes, it starts creating a Floe::Kubernetes::Runner, but then requires the new AUTOMATION_JOB_SERVICE_ACCOUNT, which doesn't exist as it is only meant to exist in the new AutomationWorker. Because of this the orchestrator fails to boot. This commit allows that value to be nil, so it can move on. However, we should find a way to avoid creating the runner on every boot, which is a better solution. --- lib/manageiq/providers/workflows/engine.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/manageiq/providers/workflows/engine.rb b/lib/manageiq/providers/workflows/engine.rb index 36919fc..b04a746 100644 --- a/lib/manageiq/providers/workflows/engine.rb +++ b/lib/manageiq/providers/workflows/engine.rb @@ -47,7 +47,7 @@ def self.floe_docker_runner "token_file" => "/run/secrets/kubernetes.io/serviceaccount/token", "ca_cert" => "/run/secrets/kubernetes.io/serviceaccount/ca.crt", "namespace" => File.read("/run/secrets/kubernetes.io/serviceaccount/namespace"), - "task_service_account" => ENV.fetch("AUTOMATION_JOB_SERVICE_ACCOUNT") + "task_service_account" => ENV.fetch("AUTOMATION_JOB_SERVICE_ACCOUNT", nil) } Floe::Workflow::Runner::Kubernetes.new(options)