jiebi/CodeConvo huggingface dataset:
Code change:
Both https://k8s- and https://k8s- started failing recently. Their 1.7 counterparts are passing. The difference between the last passing and the first failing tests is: Probably something in broke the tests. /sig scheduling /cc /kind bug
It looks like there isn't enough cpu on the master to run the cos-nvidia-installer daemonset. Did we add any addons recently?
My previous comment is a red herring. It is an issue with . Ill post a fix soon. From the scheduler logs on the master:
that's a benign error. The daemonset is not expected to run on the master. But there is no easy way to express that request in our APIs.
Yes, the pod not scheduling on the master is benign. The actual error is that we do not report node condition , so it is left as . The fix is to report that is false.
The tests are still failing. /reopen
/assign
I will be updating to track progress.
tests are green again! /close

Related discussion:
text: Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ { <ins> Type:               v1.NodeOutOfDisk, Status:             v1.ConditionFalse, Reason:             "KubeletHasSufficientDisk", Message:            fmt.Sprintf("kubelet has sufficient disk space available"), LastHeartbeatTime:  metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), LastTransitionTime: metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), }, { </ins> Type:               v1.NodeMemoryPressure, Status:             v1.ConditionFalse, Reason:             "KubeletHasSufficientMemory",
Code change:
Both https://k8s- and https://k8s- started failing recently. Their 1.7 counterparts are passing. The difference between the last passing and the first failing tests is: Probably something in broke the tests. /sig scheduling /cc /kind bug
It looks like there isn't enough cpu on the master to run the cos-nvidia-installer daemonset. Did we add any addons recently?
My previous comment is a red herring. It is an issue with . Ill post a fix soon. From the scheduler logs on the master:
that's a benign error. The daemonset is not expected to run on the master. But there is no easy way to express that request in our APIs.
Yes, the pod not scheduling on the master is benign. The actual error is that we do not report node condition , so it is left as . The fix is to report that is false.
The tests are still failing. /reopen
/assign
I will be updating to track progress.
tests are green again! /close

Related discussion:
text: Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ { <ins> Type:               v1.NodeOutOfDisk, Status:             v1.ConditionFalse, Reason:             "KubeletHasSufficientDisk", Message:            fmt.Sprintf("kubelet has sufficient disk space available"), LastHeartbeatTime:  metav1.Time{}, LastTransitionTime: metav1.Time{}, }, { </ins> Type:               v1.NodeMemoryPressure, Status:             v1.ConditionFalse, Reason:             "KubeletHasSufficientMemory",
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /priority failing-test /area test-infra What happened: job is failing. See https://k8s- https://k8s- https://k8s- https://k8s- What you expected to happen: test should pass
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/assign
Reiterating the mentions to trigger a notification: <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'm guessing that something got messed up in the bazel cache when reverting from 0.5.2 to 0.4.5. I'm not sure how best to fix.
How about updating everything to bazel 0.5.3 at once? I know you're trying to do a step-by-step approach to avoid breakages, but I suspect it will be cheaper to just deal with a brief outage while we update? (aka update the bazelbuild image to 0.5.3 and then merge your PR with updated and working BUILD rules?)
there's at least one other issue I've discovered with the latest go rules - the binary no longer works, due to changes introduced in that might be arguably better (at least everything still builds?), though it's frustrating that it makes things more broken in a different way.

Related discussion:
text: <ins> FROM debian:jessie RUN apt-get update RUN apt-get -qy install python-seqdiag make curl WORKDIR /diagrams RUN curl -sLo DroidSansMono.ttf https://googlefontdirectory.googlecode.com/hg/apache/droidsansmono/DroidSansMono.ttf ADD . /diagrams CMD bash -c 'make >/dev/stderr && tar cf - *.png' </ins>  No newline at end of file
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /priority failing-test /area test-infra What happened: job is failing. See https://k8s- https://k8s- https://k8s- https://k8s- What you expected to happen: test should pass
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/assign
Reiterating the mentions to trigger a notification: <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'm guessing that something got messed up in the bazel cache when reverting from 0.5.2 to 0.4.5. I'm not sure how best to fix.
How about updating everything to bazel 0.5.3 at once? I know you're trying to do a step-by-step approach to avoid breakages, but I suspect it will be cheaper to just deal with a brief outage while we update? (aka update the bazelbuild image to 0.5.3 and then merge your PR with updated and working BUILD rules?)
there's at least one other issue I've discovered with the latest go rules - the binary no longer works, due to changes introduced in that might be arguably better (at least everything still builds?), though it's frustrating that it makes things more broken in a different way.

Related discussion:
text: %.png: %.seqdiag $(FONT) seqdiag --no-transparency -a -f '$(FONT)' $< <ins> # Build the stuff via a docker image .PHONY: docker docker: docker build -t clustering-seqdiag . docker run --rm clustering-seqdiag | tar xvf - docker-clean: docker rmi clustering-seqdiag || true docker images -q --filter "dangling=true" | xargs docker rmi fix-clock-skew: boot2docker ssh sudo date -u -D "%Y%m%d%H%M.%S" --set "$(shell date -u +%Y%m%d%H%M.%S)" </ins>
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /priority failing-test /area test-infra What happened: job is failing. See https://k8s- https://k8s- https://k8s- https://k8s- What you expected to happen: test should pass
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/assign
Reiterating the mentions to trigger a notification: <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'm guessing that something got messed up in the bazel cache when reverting from 0.5.2 to 0.4.5. I'm not sure how best to fix.
How about updating everything to bazel 0.5.3 at once? I know you're trying to do a step-by-step approach to avoid breakages, but I suspect it will be cheaper to just deal with a brief outage while we update? (aka update the bazelbuild image to 0.5.3 and then merge your PR with updated and working BUILD rules?)
there's at least one other issue I've discovered with the latest go rules - the binary no longer works, due to changes introduced in that might be arguably better (at least everything still builds?), though it's frustrating that it makes things more broken in a different way.

Related discussion:
text: ``` Just call `make` to regenerate the diagrams. <ins> ## Building with Docker If you are on a Mac or your pip install is messed up, you can easily build with docker. ``` make docker ``` The first run will be slow but things should be fast after that. To clean up the docker containers that are created (and other cruft that is left around) you can run `make docker-clean`. If you are using boot2docker and get warnings about clock skew (or if things aren't building for some reason) then you can fix that up with `make fix-clock-skew`. ## Automatically rebuild on file changes If you have the fswatch utility installed, you can have it monitor the file system and automatically rebuild when files have changed.  Just do a `make watch`. </ins>  No newline at end of file
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: "format": "int32" }, "revisionHistoryLimit": { <del> "description": "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 2.", </del> <ins> "description": "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.", </ins> "type": "integer", "format": "int32" },
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: "revisionHistoryLimit": { "type": "integer", "format": "int32", <del> "description": "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 2." </del> <ins> "description": "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10." </ins> }, "paused": { "type": "boolean",
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">revisionHistoryLimit</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 2.</p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">integer (int32)</p></td> <td class="tableblock halign-left valign-top"></td>
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: // in extensions. These addons are: // - MaxUnavailable during rolling update set to 25% (1 in extensions) // - MaxSurge value during rolling update set to 25% (1 in extensions) <del> // - RevisionHistoryLimit set to 2 (not set in extensions) </del> <ins> // - RevisionHistoryLimit set to 10 (not set in extensions) </ins> // - ProgressDeadlineSeconds set to 600s (not set in extensions) func SetDefaults_Deployment(obj *appsv1beta2.Deployment) { // Default labels and selector to labels from pod template spec.
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: } if obj.Spec.RevisionHistoryLimit == nil { obj.Spec.RevisionHistoryLimit = new(int32) <del> *obj.Spec.RevisionHistoryLimit = 2 </del> <ins> *obj.Spec.RevisionHistoryLimit = 10 </ins> } if obj.Spec.ProgressDeadlineSeconds == nil { obj.Spec.ProgressDeadlineSeconds = new(int32)
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: MaxUnavailable: &defaultIntOrString, }, }, <del> RevisionHistoryLimit:    newInt32(2), </del> <ins> RevisionHistoryLimit:    newInt32(10), </ins> ProgressDeadlineSeconds: newInt32(600), Template:                defaultTemplate, },
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: // The number of old ReplicaSets to retain to allow rollback. // This is a pointer to distinguish between explicit zero and not specified. <del> // Defaults to 2. </del> <ins> // Defaults to 10. </ins> // +optional optional int32 revisionHistoryLimit = 6;
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: // The number of old ReplicaSets to retain to allow rollback. // This is a pointer to distinguish between explicit zero and not specified. <del> // Defaults to 2. </del> <ins> // Defaults to 10. </ins> // +optional RevisionHistoryLimit *int32 `json:"revisionHistoryLimit,omitempty" protobuf:"varint,6,opt,name=revisionHistoryLimit"`
Code change:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps

Related discussion:
text: "template":                "Template describes the pods that will be created.", "strategy":                "The deployment strategy to use to replace existing pods with new ones.", "minReadySeconds":         "Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)", <del> "revisionHistoryLimit":    "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 2.", </del> <ins> "revisionHistoryLimit":    "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.", </ins> "paused":                  "Indicates that the deployment is paused.", "rollbackTo":              "The config this deployment is rolling back to. Will be cleared after rollback is done.", "progressDeadlineSeconds": "The maximum time in seconds for a deployment to make progress before it is considered to be failed. The deployment controller will continue to process failed deployments and a condition with a ProgressDeadlineExceeded reason will be surfaced in the deployment status. Once autoRollback is implemented, the deployment controller will automatically rollback failed deployments. Note that progress will not be estimated during the time a deployment is paused. Defaults to 600s.",
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I was attempting to filter pods with a using client-go selecting by its . I tried multiple variations until I ended up with . When filtering by , list of pod(s) came back empty even if pod with the IP we are filtering by was running. Then I tried reproducing it by calling the Kubernetes API directly which had the same result, list of pods came back empty: What you expected to happen: When passing the IP of the previously retrieved running Pod, I expected to get that Pod returned in the result. How to reproduce it (as minimally and precisely as possible): create a simple , get its IP (For example using - query Kubernetes: Anything else we need to know?: If I leave out the pod IP, I get all the pods back. I also tried using different formats when doing the curl, not one of them return anything. Also it seems like field is . As a side note I retrieved the URL which I used from debugging which calls client-go made. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: minikube version: v0.20.0 OS (e.g. from /etc/os-release): minikube OS Kernel (e.g. ): minikube kernel: Install tools: minikube Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Currently the for only support , , , and . I've already submitted a PR in . PTAL.
cc

Related discussion:
text: podSpecificFieldsSet["spec.nodeName"] = pod.Spec.NodeName podSpecificFieldsSet["spec.restartPolicy"] = string(pod.Spec.RestartPolicy) podSpecificFieldsSet["status.phase"] = string(pod.Status.Phase) <ins> podSpecificFieldsSet["status.podIP"] = string(pod.Status.PodIP) </ins> return generic.AddObjectMetaFieldsSet(podSpecificFieldsSet, &pod.ObjectMeta, true) }
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: I was attempting to filter pods with a using client-go selecting by its . I tried multiple variations until I ended up with . When filtering by , list of pod(s) came back empty even if pod with the IP we are filtering by was running. Then I tried reproducing it by calling the Kubernetes API directly which had the same result, list of pods came back empty: What you expected to happen: When passing the IP of the previously retrieved running Pod, I expected to get that Pod returned in the result. How to reproduce it (as minimally and precisely as possible): create a simple , get its IP (For example using - query Kubernetes: Anything else we need to know?: If I leave out the pod IP, I get all the pods back. I also tried using different formats when doing the curl, not one of them return anything. Also it seems like field is . As a side note I retrieved the URL which I used from debugging which calls client-go made. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: minikube version: v0.20.0 OS (e.g. from /etc/os-release): minikube OS Kernel (e.g. ): minikube kernel: Install tools: minikube Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Currently the for only support , , , and . I've already submitted a PR in . PTAL.
cc

Related discussion:
text: fieldSelector: fields.ParseSelectorOrDie("status.phase=Pending"), expectMatch:   false, }, <ins> { in: &api.Pod{ Status: api.PodStatus{PodIP: "1.2.3.4"}, }, fieldSelector: fields.ParseSelectorOrDie("status.podIP=1.2.3.4"), expectMatch:   true, }, { in: &api.Pod{ Status: api.PodStatus{PodIP: "1.2.3.4"}, }, fieldSelector: fields.ParseSelectorOrDie("status.podIP=4.3.2.1"), expectMatch:   false, }, </ins> } for _, testCase := range testCases { m := MatchPod(labels.Everything(), testCase.fieldSelector)
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup /sig scheduling Descriptions: According to the discussion at , we'll move the node condition filter into a new predicates; and use feature gate to turn-off/on it. /cc
/assign

Related discussion:
text: factory.RegisterFitPredicate("CheckNodeDiskPressure", predicates.CheckNodeDiskPressurePredicate), // Fit is determied by node condtions: not ready, network unavailable and out of disk. <del> factory.RegisterFitPredicate("CheckNodeCondition", predicates.CheckNodeConditionPredicate), </del> factory.RegisterMandatoryFitPredicate("CheckNodeCondition", predicates.CheckNodeConditionPredicate), // Fit is determined by volume zone requirements.
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup /sig scheduling Descriptions: According to the discussion at , we'll move the node condition filter into a new predicates; and use feature gate to turn-off/on it. /cc
/assign

Related discussion:
text: schedulerFactoryMutex sync.Mutex // maps that hold registered algorithm types <del> fitPredicateMap          = make(map[string]FitPredicateFactory) mandatoryFitPredicateMap = make(map[string]FitPredicateFactory) priorityFunctionMap      = make(map[string]PriorityConfigFactory) algorithmProviderMap     = make(map[string]AlgorithmProviderConfig) </del> <ins> fitPredicateMap        = make(map[string]FitPredicateFactory) mandatoryFitPredicates = sets.NewString() priorityFunctionMap    = make(map[string]PriorityConfigFactory) algorithmProviderMap   = make(map[string]AlgorithmProviderConfig) </ins> // Registered metadata producers priorityMetadataProducer  MetadataProducerFactory
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup /sig scheduling Descriptions: According to the discussion at , we'll move the node condition filter into a new predicates; and use feature gate to turn-off/on it. /cc
/assign

Related discussion:
text: schedulerFactoryMutex.Lock() defer schedulerFactoryMutex.Unlock() validateAlgorithmNameOrDie(name) <del> mandatoryFitPredicateMap[name] = func(PluginFactoryArgs) algorithm.FitPredicate { return predicate } </del> <ins> fitPredicateMap[name] = func(PluginFactoryArgs) algorithm.FitPredicate { return predicate } mandatoryFitPredicates.Insert(name) </ins> return name }