Race Condition Issue: Assign Order of Execution to Certain Components.

[acarlstein]

Summary

There are occations where the order of deployment of components (of kind such as Job, CloudFunctionsFunction, etc.) matters. Find a way to indicate in the kustomize.yaml file in which order certain components should be deployed.

Description

Lets assume you're trying to deploy a Cloud Function using the CRD CloudFunctionsFunction of apiVersion cloudfunctions.cnrm.cloud.google.com/v1beta1.

This component requires that either:

• You provide an url to a repository where the code reside,
• or you to provide an url of a storage bucket where the code resides inside a ZIP file.

Regredably, the repository where the code resides isn't accessable by CloudFunctionsFunctions; therefore, you can only follow the "Zip file" approach. This increases the complexity because we want to have everything in one place.

We tried a solution by:

1. Storing the code inside a ConfigMap of apiVersion v1
2. Use a Job of apiVersion batch/v1 to (1) copy the code inside a zip file and (2) save the zip file into a storage bucket.
3. The CloudFunctionFunction uses the zip file from the storage bucket

The Problem

The problem is the order of execution. Kustomize sometimes deployes the CloudFunctionsFunctions prior the Job zippnig and storing the code from the ConfigMap. The CloudFunctionsFunction will deploy "succesfully" but fail to run due the ZIP file been missing, then it doesn't try again to get it. This is a race condition issue.

Proposed Solutions

The following are some solutions to this issue:

1. Following the example of systems such as "Terraform" and "Blueprints" introduce the argument dependsOn.
2. Allow the use of annotations used for the purpose to indicate which components should run first. Example:
   job.yaml: Order: "1"

Definition of Done

Provide a mechanism that allows to indicate the order of deployment of all or certain components. Ensuring that some components will be deployed prior to other components.

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.