Invoke tar from same location in source and target mode #297
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When cloning we were invoking tar at the container root in the source mode and within the volume mount in target mode. The result was the disk.img file appearing in a tmp/clone/image subdirectory in the target pvc instead of being copied exactly. Signed-off-by: Adam Litke <alitke@redhat.com>
|
lgtm |
aglitke
added a commit
to aglitke/containerized-data-importer
that referenced
this pull request
Jul 31, 2018
When cloning we were invoking tar at the container root in the source mode and within the volume mount in target mode. The result was the disk.img file appearing in a tmp/clone/image subdirectory in the target pvc instead of being copied exactly. Signed-off-by: Adam Litke <alitke@redhat.com>
jeffvance
pushed a commit
that referenced
this pull request
Aug 1, 2018
* Invoke tar from same location in source and target mode (#297) When cloning we were invoking tar at the container root in the source mode and within the volume mount in target mode. The result was the disk.img file appearing in a tmp/clone/image subdirectory in the target pvc instead of being copied exactly. Signed-off-by: Adam Litke <alitke@redhat.com> * Having the cloning label in the target pod, make the pod affinity fails. (#280) The target pod looks for a pod with a specific label (specified in the pod affinity) that matches the source pod label. In my case the target pod included this label as well, so we can see that the target pod found matching pod, but it is the WRONG pod. It's itself!! The target was running without finding the source pod first. If we remove this label from the target pod, it will find the source pod and then will be scheduled on the same node. If it does not find the source pod (because the scheduler tried to schedule it before the source pod), it will be in 'Pending' state until the source pod is scheduled, and then will be running on the same node. #279
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When cloning we were invoking tar at the container root in the source
mode and within the volume mount in target mode. The result was the
disk.img file appearing in a tmp/clone/image subdirectory in the target
pvc instead of being copied exactly. Fixes #296
Signed-off-by: Adam Litke alitke@redhat.com