Skip to content

support for nodeSelector and tolerations#1831

Closed
krancour wants to merge 12 commits intoknative:masterfrom
krancour:rev-scheduling
Closed

support for nodeSelector and tolerations#1831
krancour wants to merge 12 commits intoknative:masterfrom
krancour:rev-scheduling

Conversation

@krancour
Copy link
Contributor

@krancour krancour commented Aug 9, 2018

Fixes #1816

Thought this wouldn't be too controversial, so @jeremyrickard and I took a crack at it.

Proposed Changes

  • Support for nodeSelector and tolerations in revision spec

@knative-prow-robot knative-prow-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Aug 9, 2018
@krancour krancour changed the title Rev scheduling support for nodeSelector and tolerations Aug 9, 2018
@krancour
Copy link
Contributor Author

/test pull-knative-serving-go-coverage

@krancour
Copy link
Contributor Author

I'm really not sure what's up with prow right now. I can't seem to get it to re-run coverage either by bumping it or amending the PR.

Report above shows a 1.2% reduction in coverage. That's a lie. lol. This has 100% coverage. I just can't get the report to refresh.

@mattmoor
Copy link
Member

@steuhs

@krancour
Copy link
Contributor Author

/retest

@cppforlife
Copy link
Contributor

any thoughts about adding affinity as well? it seems that knative/build is also adding it: knative/build#237 (though they didnt add tolerations, only nodeSelector so far)

i could also see node anti-affinity (nodes and azs) being a good default that knative sets up for applications to increase high availability of services. thoughts?

Copy link
Contributor

@bbrowning bbrowning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking this on! And extra thanks for the tests that cover the new behavior.

I don't love having to copy all the validateToleration from Kubernetes itself, but I also don't see an obviously better way to handle that.

I do have a couple of requested changes - one trivial and one a bit more work to ensure the spec and conformance tests stay in sync with changes to the api, as described at https://github.com/knative/serving/tree/master/docs/spec

# https://istio.io/docs/tasks/traffic-management/egress/
#
istio.sidecar.includeOutboundIPRanges: "*"
istio.sidecar.includeOutboundIPRanges: "10.0.0.1/24"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was probably unintentionally included with this PR. I have the same local change and have almost accidentally included it in a PR as well 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops. That's embarrassing. Thank for catching it, @bbrowning.

// that node.
// More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
// +optional
NodeSelector map[string]string `json:"nodeSelector,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This api change (and the Tolerations below it) should include a corresponding change to the spec at https://github.com/knative/serving/blob/master/docs/spec/spec.md and the conformance tests at https://github.com/knative/serving/tree/master/test/conformance, if applicable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bbrowning I updated docs just now.

I'm really not sure whether the conformance tests are applicable here, and if so, I'm not sure where to begin.

@markusthoemmes
Copy link
Contributor

@krancour could you give a brief status here? It seems to be mostly there implementationwise. I'd be happy to help push it through if you don't have time to finish it up.

@krancour
Copy link
Contributor Author

@markusthoemmes sorry... I completely lost track of it. I'll be happy to clean this up and rebase this afternoon.

@knative-prow-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: krancour
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mdemirhan

If they are not already assigned, you can assign the PR to them by writing /assign @mdemirhan in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@krancour
Copy link
Contributor Author

I don't quite understand the "pull-knative-serving-build-tests" failure.

@krancour
Copy link
Contributor Author

/retest

@krancour
Copy link
Contributor Author

@bbrowning @mattmoor can either of you give me some insight on why the pull-knative-serving-build-tests are failing? It's not clear to me.

@markusthoemmes
Copy link
Contributor

@krancour it seems like a linting error in a markdown:

I0129 15:12:22.023] ------------------------------------
I0129 15:12:22.039] ---- Linting the markdown files ----
I0129 15:12:22.039] ------------------------------------
I0129 15:12:23.684] docs/spec/spec.md:176: MD009 Trailing spaces

@knative-metrics-robot
Copy link

The following is the coverage report on pkg/.
Say /test pull-knative-serving-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/serving/v1alpha1/revision_validation.go 94.7% 95.8% 1.1

@krancour
Copy link
Contributor Author

@markusthoemmes I'm not sure where you got that from. I couldn't find those same lines in the logs from the tests. Regardless, thank you.

I fixed the lint issue in the docs.

@markusthoemmes
Copy link
Contributor

meh. I missed the update and now we're back in merge conflict land again :/

@krancour
Copy link
Contributor Author

krancour commented Feb 8, 2019

I don't have the time to address those right now, unfortunately. It could be a while.

@markusthoemmes
Copy link
Contributor

@krancour Do you mind if I pick this up and rebase it? We need to make sure when merging that you get the proper credits for the commits but that should be solvable.

@krancour
Copy link
Contributor Author

@markusthoemmes go for it. Don't worry about credit. I value the change getting in more than credit for making it.

@markusthoemmes
Copy link
Contributor

@krancour opened a new PR with the rebased version. Would you please add a comment there that you're okay with me reopening it?

@krancour
Copy link
Contributor Author

krancour commented Apr 2, 2019

Closing because #3467 is more up to date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants