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.

Sign up for GitHub

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

Jump to bottom

Remove cloning label from target pods to fix pod affinity #279

Closed
zvikorn opened this issue Jul 29, 2018 · 2 comments
Closed

Remove cloning label from target pods to fix pod affinity #279

zvikorn opened this issue Jul 29, 2018 · 2 comments

Comments

@zvikorn
Copy link
Contributor

zvikorn commented Jul 29, 2018

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.
zvikorn added a commit to zvikorn/containerized-data-importer that referenced this issue Jul 29, 2018
@zvikorn
Remove cloning label from target pods to fix pod affinity. kubevirt#279
c43daf8
@zvikorn zvikorn mentioned this issue Jul 29, 2018
Merged
@zvikorn
Copy link
Contributor Author

zvikorn commented Jul 29, 2018

Fixed. PR - #280

zvikorn added a commit to zvikorn/containerized-data-importer that referenced this issue Jul 31, 2018
@zvikorn
Remove cloning label from target pods to fix pod affinity. kubevirt#279
3d075dc
zvikorn added a commit to zvikorn/containerized-data-importer that referenced this issue Jul 31, 2018
@zvikorn
Having the cloning label in the target pod, make the pod affinity fails.
2432b0c 
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
jeffvance pushed a commit that referenced this issue Jul 31, 2018
@jeffvance
Having the cloning label in the target pod, make the pod affinity fai…
723e222 
…ls. (#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
@jeffvance
Copy link
Contributor

fixed #280

aglitke pushed a commit to aglitke/containerized-data-importer that referenced this issue Jul 31, 2018
@aglitke
Having the cloning label in the target pod, make the pod affinity fai…
3734b1d 
…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 pushed a commit to aglitke/containerized-data-importer that referenced this issue Aug 1, 2018
@aglitke
Having the cloning label in the target pod, make the pod affinity fai…
691e696 
…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
This was referenced Aug 1, 2018
Merged
Closed
jeffvance pushed a commit that referenced this issue Aug 1, 2018
@aglitke @jeffvance
Backports of Cloning PRs #280 and #297 to 1.1 branch (#301)
2925c85 
* 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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jeffvance @zvikorn