-
Notifications
You must be signed in to change notification settings - Fork 392
Abstract the conductor image from service images #910
Comments
As a workaround I use the Ansible template module as described in #454 This conductor and container service split would be awesome and I think this also removes most of the need for templating the conductor base like #732 suggests. |
I have same error with kubectl plugin error
|
ISSUE TYPE
Consider a scenario where an application needs to be deployed on multiple images of different base operating systems for testing purposes. Specifying the conductor image of one base will cause the build process for service images using a different base to fail. Scanning through current issues, these might be related: #807, #812, #847, #904, as I have experienced the same or very similar errors when building service images that do not match or partially match the conductor image.
The documentation is clear about the fact that service images should be of the same family as the conductor image. This might be limiting as the potential workarounds include creating and maintaining a separate project for each base image. The other option is to use the docker_image to build from Dockerfiles, and then run them with docker_containter. What is not clear in the documentation is how run tasks on the created containers afterwards, if this approach is to be taken.
For example, the build for the below configuration and related role(s) will fail.
container.yml
roles/common/tasks/main.yml
or
roles/common/tasks/main.yml
Depending on the service images used that do not match the conductor image, the build will error out with a different error message. Using the multi-container example did not help either. What I noticed is that when using service images which do not match the conductor image and do not use any roles, the build process succeeds, for example a configuration file such as below will build successfully.
container.yml
I am not sure how practically feasible to abstract the conductor image from the service images. Would the enhancement in #777 help overcome such concerns?
The text was updated successfully, but these errors were encountered: