When a container is committed to a new image, all its settings such as environment variables and labels will be persisted as well, including those used by the plugin to track containers.
When a container created from such image is started, the plugin will consider it as being a managed container, and will:
1) disable the hosted cloud agent (if the image was created from a test container).
2) destroy the container if it was manually started (eg. with the docker start command line) since we cannot map any internal state to it.
This is unwanted. When a managed container is committed back to an image, containers manually started from it should be left untouched by the plugin. If such image is used as cloud agent image, the persisted meta-data should not interferes with newly created containers.
Possible solution:
Erase all prior plugin meta-data when starting a new container.
Detect if the container is a "copy" of a managed container (comitted and reinstantiated). This should be doable by saving as label the initial image ID and comparing it with the container source image ID at runtime. If there is no match: assume that the container is unmanaged.
When a container is committed to a new image, all its settings such as environment variables and labels will be persisted as well, including those used by the plugin to track containers.
When a container created from such image is started, the plugin will consider it as being a managed container, and will: 1) disable the hosted cloud agent (if the image was created from a test container). 2) destroy the container if it was manually started (eg. with the docker start command line) since we cannot map any internal state to it.
This is unwanted. When a managed container is committed back to an image, containers manually started from it should be left untouched by the plugin. If such image is used as cloud agent image, the persisted meta-data should not interferes with newly created containers.
Possible solution: