When resource provisioners create services that take some time to start up or have init containers that must complete before the workload services start, we need to determine a start up order.
This PR adds a new service called wait_for_resources which is used as a coordination point. This is only added when resource services are provisioned and it gets a dependency added for each one. When present, the workload services will now wait for this service to run before they may start.
You can see this affect in the unit test added in generate_test.go.
The ready condition is tuned based on what we can detect about the container. Since we cannot always distinguish services that are init containers, we have an opt-in / best-effort label which can be added in provisioners to indicate that we must wait for the service to actually finish.
When resource provisioners create services that take some time to start up or have init containers that must complete before the workload services start, we need to determine a start up order.
This PR adds a new service called
wait_for_resourceswhich is used as a coordination point. This is only added when resource services are provisioned and it gets a dependency added for each one. When present, the workload services will now wait for this service to run before they may start.You can see this affect in the unit test added in generate_test.go.
The ready condition is tuned based on what we can detect about the container. Since we cannot always distinguish services that are init containers, we have an opt-in / best-effort label which can be added in provisioners to indicate that we must wait for the service to actually finish.