Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backports of Cloning PRs #280 and #297 to 1.1 branch #301

Merged
merged 2 commits into from
Aug 1, 2018

Conversation

aglitke
Copy link
Member

@aglitke aglitke commented Aug 1, 2018

This backports two fixes from master to fix the following issues:

Fixes #298

When cloning a source pvc to a target pvc the target pvc has a different file hierarchy. This is because tar is invoked at the container root in the source case but expanded inside the pvc volume mount in the target case. Fix by using pushd in the source case as well.

Fixes #302

Having the cloning label in the target pod, make the pod affinity fails.
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.

aglitke and others added 2 commits July 31, 2018 16:30
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>
…ls. (kubevirt#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.
kubevirt#279
@aglitke aglitke changed the title 298 Backports of PRs #280 and #297 to 1.1 branch Aug 1, 2018
@aglitke aglitke changed the title Backports of PRs #280 and #297 to 1.1 branch Backports of Cloning PRs #280 and #297 to 1.1 branch Aug 1, 2018
@jeffvance
Copy link
Contributor

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants