Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1276002 - If a replication controller contains all selectors of an existing controller, the former controller cannot create pods
Summary: If a replication controller contains all selectors of an existing controller,...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OKD
Classification: Red Hat
Component: Pod
Version: 3.x
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Andy Goldstein
QA Contact: Jianwei Hou
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-28 11:02 UTC by Xingxing Xia
Modified: 2015-11-10 16:30 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-28 17:08:58 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Xingxing Xia 2015-10-28 11:02:05 UTC
Description of problem:
Given a existing replication controller named "test-a" specifies selector as "a=b" and has created pods, try to create another controller named "test-b", which also contains selector "a=b" and other selector "c=d" as well, then "test-b" cannot create pods correctly

Version-Release number of selected component (if applicable):
openshift/oc v1.0.6-997-gff3b522
kubernetes v1.2.0-alpha.1-1107-g4c8e6f4

How reproducible:
Always


Steps to Reproduce:
1. oc login and create a project
2. Create rc "test-a" first
1> $ cat test-a.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: test-a
spec:
  replicas: 1
  selector:
    a: b
  template:
    metadata:
      labels:
        a: b
    spec:
      containers:
      - image: yapei/hello-openshift
        name: test-a
      restartPolicy: Always
2 > $ oc create -f test-a.yaml

3. Then create rc "test-b"
1> $ cat test-b.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: test-b
spec:
  replicas: 1
  selector:
    a: b
    c: d
  template:
    metadata:
      labels:
        a: b
        c: d
    spec:
      containers:
      - image: yapei/hello-openshift
        name: test-b
      restartPolicy: Always
2> oc create -f test-b.yaml

4. Check rc and pods
1> $ oc get rc
2> $ oc get pods
3> $ oc describe rc test-b

Actual results:
4.
2> Only pod of "test-a" exist
NAME           READY     STATUS    RESTARTS   AGE
test-a-3lknc   1/1       Running   0          39m
3> 
Name:		test-b
Namespace:	xxia-proj2
Image(s):	yapei/hello-openshift
Selector:	a=b,c=d
Labels:		a=b,c=d
Replicas:	0 current / 1 desired
Pods Status:	0 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
Events:
  FirstSeen	LastSeen	Count	From				SubobjectPath	Reason			Message
  ─────────	────────	─────	────				─────────────	──────			───────
  1m		1m		1	{replication-controller }			SuccessfulCreate	Created pod: test-b-4pg6g



Expected results:
pod of "test-b" should exist

Additional info:

Comment 1 Andy Goldstein 2015-10-28 17:08:58 UTC
This is working as designed. If you have multiple replication controllers with overlapping label selectors, they will fight with each other. The solution is to not have overlapping selectors across multiple RCs.

Comment 2 Xingxing Xia 2015-11-03 01:54:53 UTC
(In reply to Andy Goldstein from comment #1)
> This is working as designed. If you have multiple replication controllers
> with overlapping label selectors, they will fight with each other. The
> solution is to not have overlapping selectors across multiple RCs.

Sometimes when creating many resources, it is easy to forget which selectors have been already used, thus cause this overlapping issue. Is it better to add some mechanism to detect whether the new resource being created has overlapping selector with existing resources? If it detects, then prevent the new creation and give some prompt.

Comment 3 Andy Goldstein 2015-11-10 16:30:23 UTC
There is an open issue upstream for this: https://github.com/kubernetes/kubernetes/issues/2210


Note You need to log in before you can comment on or make changes to this bug.