lxc_container: snapshot clone container creation incorrectly starts the origin container #2577
Comments
@cloudnull Note that this issue is now fully replicated. |
@cloudnull, ping. This issue is still waiting on your response. |
I'm now working on this issue and hope to have a fix in soon-ish. |
@cloudnull, ping. This issue is still waiting on your response. |
It seems that option - name: Create container overlay1 lxc_container: name: base1 clone_snapshot: yes clone_name: overlayfs1 state: stopped backing_store: overlayfs - name: Start container overlay1 lxc_container: name: overlayfs1 state: started |
@morfeush22 Yeah, that makes sense as a workaround. Thanks - we're doing something similar, but due to #2691 we're using the CLI commands anyway. |
@cloudnull, ping. This issue is still waiting on your response. |
2 similar comments
@cloudnull, ping. This issue is still waiting on your response. |
@cloudnull, ping. This issue is still waiting on your response. |
@cloudnull, ping. This issue is still waiting on your response. |
This repository has been locked. All new issues and pullrequests should be filed in https://github.com/ansible/ansible Please read through the repomerge page in the dev guide. The guide contains links to tools which automatically move your issue or pullrequest to the ansible/ansible repo. |
This issue was migrated to ansible/ansible#29336 |
ISSUE TYPE
COMPONENT NAME
lxc_container
ANSIBLE VERSION
CONFIGURATION
None
OS / ENVIRONMENT
I have used both Ubuntu 14.04 LTS and Ubuntu 16.04 LTS with the same results. More details in this gist: https://gist.github.com/odyssey4me/97e0edbb9e46748cdf8775b786f820b6
SUMMARY
When using the lxc_container module to create a container (overlayfs1) based on a snapshot of another container (base1) (ie
lxc-clone --snapshot
), instead of starting 'overlayfs1' the base container starts and thus the one that's supposed to start fails.STEPS TO REPRODUCE
Using https://gist.github.com/odyssey4me/97e0edbb9e46748cdf8775b786f820b6#file-0-create-containers-yml you will notice the changes in state. Instead of overlayfs1 and overlayfs2 being in a started state (with base1 and base2 in a stopped state), the result is the opposite.
The playbook below does a comparative test using the module and the CLI.
EXPECTED RESULTS
The container
overlayfs1
andoverlayfs2
should be running, while the base containers should be stopped.ACTUAL RESULTS
The container
base1
andoverlayfs2
are running. The containeroverlayfs1
tried to start, but failed because the base was running.The text was updated successfully, but these errors were encountered: