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

Do not propagate build labels to build pods #3502

Closed
liggitt opened this issue Jun 30, 2015 · 10 comments
Closed

Do not propagate build labels to build pods #3502

liggitt opened this issue Jun 30, 2015 · 10 comments
Assignees
Labels
area/compatibility component/build kind/bug Categorizes issue or PR as related to a bug. priority/P1

Comments

@liggitt
Copy link
Contributor

liggitt commented Jun 30, 2015

Follow-up from #2295

Adding a single label for selecting a build is ok (though the label should probably be more namespaced than "build"), but we should not be copying all labels from build API objects to their pods. Pods labels are used group pods under services and replication controllers, and copying random labels into builds pods is likely to get them routed to by services (which would be bad) or "managed" by replication controllers (which would also be bad).

@liggitt liggitt added kind/bug Categorizes issue or PR as related to a bug. priority/P1 component/build labels Jun 30, 2015
@liggitt
Copy link
Contributor Author

liggitt commented Jun 30, 2015

cc @bparees @smarterclayton @soltysh

@liggitt
Copy link
Contributor Author

liggitt commented Jun 30, 2015

Copy code is in build/controller/strategy/util.go#getPodLabels

@bparees
Copy link
Contributor

bparees commented Jun 30, 2015

@liggitt thanks. copying my final comment from the original issue over to here now:

@soltysh I think this needs to:

  1. add a new label (openshift.io/build.name)
  2. only add that label to build pods and no other labels
  3. update the filter logic in our various controllers to use the new label || the old label
  4. note that the old label is deprecated ( @smarterclayton how exactly do we do that? )

@smarterclayton
Copy link
Contributor

On Jun 29, 2015, at 11:11 PM, Ben Parees notifications@github.com wrote:

@liggitt https://github.com/liggitt thanks. copying my final comment from
the original issue over to here now:

@soltysh https://github.com/soltysh I think this needs to:

  1. add a new label (openshift.io/build.name)
  2. only add that label to build pods and no other labels
  3. update the filter logic in our various controllers to use the new label
    || the old label
  4. note that the old label is deprecated ( @smarterclayton
    https://github.com/smarterclayton how exactly do we do that? )

This issue should be tagged with the compat tag. We should create a doc in
the root that describes what, when, and how we plan to change. The when is
post 3.1 / 1.2.


Reply to this email directly or view it on GitHub
#3502 (comment).

@smarterclayton
Copy link
Contributor

We need to remove support for this before I cut 1.0.7

@bparees
Copy link
Contributor

bparees commented Oct 20, 2015

Remove support for the old label?

@smarterclayton
Copy link
Contributor

Yeah

On Mon, Oct 19, 2015 at 11:32 PM, Ben Parees notifications@github.com
wrote:

Remove support for the old label?


Reply to this email directly or view it on GitHub
#3502 (comment).

@bparees
Copy link
Contributor

bparees commented Oct 20, 2015

The when is post 3.1 / 1.2.

so don't you want to cut 1.0.7 before we remove this?

@smarterclayton
Copy link
Contributor

We announced in 1.0.6 we'd remove it in 1.0.7

On Tue, Oct 20, 2015 at 9:07 AM, Ben Parees notifications@github.com
wrote:

The when is post 3.1 / 1.2.

so don't you want to cut 1.0.7 before we remove this?


Reply to this email directly or view it on GitHub
#3502 (comment).

@bparees
Copy link
Contributor

bparees commented Oct 20, 2015

removing here: #5250

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/compatibility component/build kind/bug Categorizes issue or PR as related to a bug. priority/P1
Projects
None yet
Development

No branches or pull requests

4 participants