jiebi/CodeConvo huggingface dataset:
Code change:
# Setup the container runtime on the node. It supports both # Docker and containerd. function Setup-ContainerRuntime { <ins> Install-Pigz </ins> if (${env:CONTAINER_RUNTIME} -eq "containerd") { Install_Containerd Configure_Containerd

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : pigz for GCE Windows Why is this needed: Pigz improves the image layer extraction performance for multi-core systems. Pigz is usually preinstalled on Linux. This enhancement is scoped specifically for the GKE Windows node scripts. For Context:
/assign me
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions 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
GitHub didn't allow me to assign the following users: me. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign me 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
/sig windows /assign jeremyje
s/GKE/GCE/? as in kube-up?
Replaced but I don't understand the kube-up part.
is how one creates a GCE cluster from this repo. Otherwise we'd be talking about something that isn't part of kubernetes.
Code change:
var outTimestamp time.Time var err error if tc.metric.singleObject != nil { <del> outReplicas, outUtilization, outTimestamp, err = replicaCalc.GetObjectMetricReplicas(tc.currentReplicas, tc.metric.targetUtilization, tc.metric.name, testNamespace, tc.metric.singleObject) </del> <ins> outReplicas, outUtilization, outTimestamp, err = replicaCalc.GetObjectMetricReplicas(tc.currentReplicas, tc.metric.targetUtilization, tc.metric.name, testNamespace, tc.metric.singleObject, selector) </ins> } else if tc.metric.selector != nil { if tc.metric.targetUtilization > 0 { <del> outReplicas, outUtilization, outTimestamp, err = replicaCalc.GetExternalMetricReplicas(tc.currentReplicas, tc.metric.targetUtilization, tc.metric.name, testNamespace, tc.metric.selector) </del> <ins> outReplicas, outUtilization, outTimestamp, err = replicaCalc.GetExternalMetricReplicas(tc.currentReplicas, tc.metric.targetUtilization, tc.metric.name, testNamespace, tc.metric.selector, selector) </ins> } else if tc.metric.perPodTargetUtilization > 0 { outReplicas, outUtilization, outTimestamp, err = replicaCalc.GetExternalPerPodMetricReplicas(tc.currentReplicas, tc.metric.perPodTargetUtilization, tc.metric.name, testNamespace, tc.metric.selector) }

Related discussion:
text: without this feature we cannot use HPA as is and we need to figure out how to build/run fork (which can be challenging because everything inside controller-manager). also we are planning to upgrade to 1.10 quickly, but not sure for 1.11 (e.g. we are two versions behind now).
Sounds like a plan :) Will try and get this done tomorrow morning!
- I submitted a pr for this - would love your eyes on it so you can see if you think it meets your use case :)
/assign
GitHub didn't allow me to assign the following users: mattjmcnaughton. Note that only and repo collaborators can be assigned. <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 checked the code and it seems good to me. About the comment about scaling down if the readyPods<CurrentPods, we should be fine since our metric is already not including the pods that are not ready.
Is there any advance in this ticket? I'm wondering if this made it to k8s 1.10 or if we need to wait for k8s 1.11?
The PR is lgtm-ed and it will merge once the code freeze is lifted. Meaning it will go to 1.11. To get it into 1.10 you would need to get approval for milestone from (sig-autoscaling lead).
Code change:
BuildImageRegistry:      "k8s.gcr.io/build-image", InvalidRegistry:         "invalid.com/invalid", GcEtcdRegistry:          "k8s.gcr.io", <del> GcHttpdRegistry:         "k8s.gcr.io/e2e-test-images", </del> GcRegistry:              "k8s.gcr.io", SigStorageRegistry:      "k8s.gcr.io/sig-storage", GcrReleaseRegistry:      "gcr.io/gke-release",

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --/sig windows /cc After was merged I think.
I agree that looks like the issue. It started failing between the two commits: on this run:
/triage accepted
/assign
Code change:
BuildImageRegistry:      "k8s.gcr.io/build-image", InvalidRegistry:         "invalid.com/invalid", GcEtcdRegistry:          "k8s.gcr.io", <del> GcHttpdRegistry:         "k8s.gcr.io/e2e-test-images", </del> GcRegistry:              "k8s.gcr.io", SigStorageRegistry:      "k8s.gcr.io/sig-storage", GcrReleaseRegistry:      "gcr.io/gke-release",

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Kubernetes e2e suite: [sig-apps] StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should have a working scale subresource [Conformance] Kubernetes e2e suite: [sig-apps] StatefulSet [] Basic StatefulSet functionality [StatefulSetBasic] should perform canary updates and phased rolling updates of template modifications [Conformance] and a few others.
/sig windows
/triage accepted
/cc should be resolved by
Currently blocked because there are some issues pushing the httpd test images to . Slack thread:
Latest thread:
The job failing is:
is where the fixes for publishing this image is being tracked
Code change:
} } <del> // Case 4: Schedule Pod with NetworkUnavailable toleration. </del> <ins> // Case 4: Schedule Pod with NetworkUnavailable and NotReady toleration. </ins> networkDaemonPod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "network-daemon-pod",

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: What happened: admission control plugin in apiserver. a deployment with 1 replica. The pod is successfully launched. By default the admission control plugin will add following toleration in the pod. the node where the above pod is running. of image locality policy and above toleration in the pod, scheduler still choose the node to launch the pod. The pod is in state and failed to create. What you expected to happen: The pod should be scheduled to healthy node and created successfully. How to reproduce it (as minimally and precisely as possible): See above steps. Anything else we need to know?: Environment: Kubernetes version (use ): v1.10 Cloud provider or hardware configuration: openstack OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-121-generic Install tools: N/A Others:
/sig scheduler
/sig scheduling /sig node
I think that we should avoid scheduling pods to nodes which is not ready even it can tolerate and , comments
As the pod already claimed to tolerate NotReady, this is an expected behavior. P.S. If the eviction dose not happen after 5m, that should be the bug. Please reopen the issue and modify the description. This is what tolerations is designed for :) And there are many use cases for pod to be scheduled to NotReady nodes (mostly during cluster deployment).
I think maybe you can configure effect to avoid scheduling to those nodes.
scheduler still choose the NotReady node to launch the pod For running, the toleration is used for graceful termination by ; if is enabled, it's better to also taint node with for .
Wondering how the pod can start to run if the Node is not ready at deployment time? Can you specify a use case here?
It won't need to start, system pod pending will be expected :) The point is, freedom for users to decide what tolerations they want matters here. I don't think it's reasonable to combine with in this case.
Perhaps, add to default toleration of admission control plugin could eliminate the confusion.
We should align the behavior when enabled or disabled : if is disabled, will not schedule pod to not-ready node. if is enabled, we should also taint node with .
Code change:
} } <del> // Case 4: Schedule Pod with NetworkUnavailable toleration. </del> <ins> // Case 4: Schedule Pod with NetworkUnavailable and NotReady toleration. </ins> networkDaemonPod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "network-daemon-pod",

Related discussion:
text: with timeout is used for graceful termination of 'running pods' for feature. We should not re-schedule pod to not-ready unless tolerating it explicitly.
reopen this for more discussion :)
Let me extracted the mixed problems in this issue :-) First one: These two default tolerations attached to the pod by means: if the node is tainted as or , wait for 300s before the pod is evicted from the node. While according to the issue description, is working as expected (pods are not evicted immediately). This part should be closed. Second one: The discussion raised is actually about taint during eviction: if TaintNodesByCondition is enabled, we should also taint node with NotReady:NoSchedule. My thoughts is: it's reasonable to taint node with as well for consistency consideration (but I'm hesitate if only for eliminating confusion as pods are expected to pending on NotReady nodes) I think it should be clearer now.
I open a PR If TaintNodesByCondition is enable, taint node with NotReady:NoSchedule and Unreachable:NoSchedule.
, we did not catch 1.11 release, so this issue will be handled in 1.12 :)
in 1.9.7enable the TaintNodesByCondition and taint nodee.g. node01 with NotReady:NoSchedulethen pod also can not be scheduled to node01 even when node01 is healthy. What you expected to happen: The pod should be scheduled to node01 when it is healthy node and not be scheduled to node01 when it is not ready. Thanks
How did you do that? by kubectl? The fix is not ready until 1.12.
YesI tried "kubectl taint nodes node01 ",and also tried "kubectl taint nodes node01 "
this feature did not handle taint manually
Ok, thanks a lot! So I can not solve the problem manually now and what I should do is just waiting for the version 1.12, right?
Code change:
assert := assert.New(t) <del> plugMgr := newInitializedVolumePlugMgr() </del> <ins> plugMgr, rootDir := newInitializedVolumePlugMgr(t) if rootDir != "" { defer os.RemoveAll(rootDir) } </ins> plug, err := plugMgr.FindPluginByName(flockerPluginName) assert.NoError(err)

Related discussion:
text: Unit tests on our CI have apparently been failing for 2 weeks and no one noticed (oops!)... The PR that seems to have caused the failures is . The failing test is - . Full Test Log: I'm not sure why this is failing on our CI and not on shippable. Has anyone else seen something similar? That test only seems to fail on the second run through with . Our unit tests run in a container built specifically for testing k8s-mesos: The Dockerfile for the env: Is anyone else able to repro with the above env or their own?
/cc
that test was around a week ago, it's doesn't seem possible to me that it was failing since 2 weeks ago. Anyway, we have few duplications of this issue: this one And the PR where is working on: It's a little bit difficult to me to follow all the conversations in all the differente places about the same bug, could it be possible to unificate some? Since you provided the environment I will try and take a look to reproduce it locally. Thanks!
I think I've got a working patch in
Closing in favor of &
Code change:
assert := assert.New(t) <del> plugMgr := newInitializedVolumePlugMgr() </del> <ins> plugMgr, rootDir := newInitializedVolumePlugMgr(t) if rootDir != "" { defer os.RemoveAll(rootDir) } </ins> plug, err := plugMgr.FindPluginByName(flockerPluginName) assert.NoError(err)

Related discussion:
text: reports the following failure after syncing with latest code: --- FAIL: TestSetUpAtInternal (0.00s) Error Trace: Error: Not equal: "expected-to-be-set-properly" (expected) != "" (actual) FAIL FAIL 0.067s cc/
CC
Taking a look. What do you mean with failed sometimes? Is it a random failure?
Can you please provide more information. This test seems to be consistently green in our CI runs.
The test is failing on this assertion: but as you can see on the previous line I am checking that there was no error on that call. So the function is returning for the error checking but it's not setting . Only place where it can happen is here: Is the not been clean between runs?
When I said "the only place where it can happen" it was because the other s are being returned after a check. I think that there is no other way to get there.
PS: I run the test suite 100 times and I didn't get any error: (That branch is based on the branch)
can you test to see if the patch in fixes things for you?
See for reproducible test environment and failure logs.
Based on the solution in it sounds like this test creates files the first time through which causes the tests to fail on the second time through.
Code change:
recorder := recorderWithFakeClock(api.EventSource{Component: "eventTest"}, eventBroadcaster, clock) for index, item := range table { clock.Step(1 * time.Second) <del> logWatcher1 := eventBroadcaster.StartLogging(t.Logf) // Prove that it is useful logWatcher2 := eventBroadcaster.StartLogging(func(formatter string, args ...interface{}) { </del> <ins> logWatcher := eventBroadcaster.StartLogging(func(formatter string, args ...interface{}) { </ins> if e, a := item.expectLog, fmt.Sprintf(formatter, args...); e != a { t.Errorf("Expected '%v', got '%v'", e, a) }

Related discussion:
text: I wasn't able to find automatically create issue for this, but I may not know what to search for. Is our bot creating issues for unit test failures? - this failure looks to me as something in client testing libraries.
If it's exposed in JUnit output, then the bot should be making issues for it.
It's not exposed in junit due to :(
Lots of failures in , probably all this bug.
Yeah this seems to be happening a lot. Raising priority.
I thought was reverted but it's not. I'll revert it.
golang 1.6 doesn't fix the race:
Sent .
Code change:
glog.Errorf("Failed to check whether disk is attached. err: %s", err) return false, err } <del> for _, controllerType := range supportedSCSIControllerType { controllerkey, _ := getControllerKey(controllerType, vmdevices) if controllerkey == virtualDiskControllerKey { return true, nil } } return false, ErrNonSupportedControllerType </del> <ins> return true, nil </ins> } // Returns the object key that denotes the controller object to which vmdk is attached.

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): v1.4.x v1.5.x v1.6.x master Environment: vSphere based install with vSphere Cloud Provider enabled. Cloud provider or hardware configuration: vSphere OS (e.g. from /etc/os-release): NA Kernel (e.g. ):NA Install tools:kubernetes-anywhere Others: What happened: vSphere Cloud Provider configures additional SCSI adapters to scale the number of volumes that can be attached to a VM (1 adapter = 16 disks). The code within the cloud provider does not handle this correctly. Additional disks attach successfully to the VM but when k8s verifies the attach status it fails leading to k8s retrying the attach that never succeeds. In addition to this when the SCSI adapter is created for the first time the code does not use it to attach the disk leading to a failed attach disk request to the cloud provider. What you expected to happen: Additional disks should be to the VM upto the max number supported. How to reproduce it (as minimally and precisely as possible): Create a single node cluster and create a statefulset with 16 replicas or have a pod with more than 16 disks. Anything else we need to know:
A fix for this is coming up..
cc
Huh, I wonder if something changed between 1.3 and newer?
Code change:
glog.Errorf("Failed to check whether disk is attached. err: %s", err) return false, err } <del> for _, controllerType := range supportedSCSIControllerType { controllerkey, _ := getControllerKey(controllerType, vmdevices) if controllerkey == virtualDiskControllerKey { return true, nil } } return false, ErrNonSupportedControllerType </del> <ins> return true, nil </ins> } // Returns the object key that denotes the controller object to which vmdk is attached.

Related discussion:
text: We had tested up to 40-something volumes on 1.3. There was a fun discussion internally because it would always fail at SCSI ID 7 and I had to explain SCSI to some younger engineers :)
Code change:
if !found { t.Errorf("Failed to find node %v in schedulerinternalcache.", node.Name) } <del> if cache.nodeTree.NumNodes != 1 || cache.nodeTree.Next() != node.Name { </del> <ins> if cache.nodeTree.NumNodes() != 1 || cache.nodeTree.Next() != node.Name { </ins> t.Errorf("cache.nodeTree is not updated correctly after adding node: %v", node.Name) }

Related discussion:
text: Description: , part of the is exporting a field which allows to modify its value externally. This also means that this field is not thread-safe. Solution: Expose a method that returns this value in a thread-safe way and do not export the field. /kind bug /sig scheduling
Code change:
"create_clusterrole_test.go", "create_clusterrolebinding_test.go", "create_configmap_test.go", <ins> "create_cronjob_test.go", </ins> "create_deployment_test.go", "create_job_test.go", "create_namespace_test.go",

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Why is this needed: Because of is not recommended to create cronjob (with flags) anymore. But there is no imperative command available for to create cronjob. /sig CLI <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/assign
GitHub didn't allow me to assign the following users: Pingan2017. Note that only and repo collaborators can be assigned. For more information please see <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 wanna work on this. give me several days
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Code change:
import ( "fmt" <ins> "net/http" </ins> "reflect" "strconv" "strings"

Related discussion:
text: When attempting to fetch a resource version that is too old, the behavior of watch (for both HTTP and web sockets) changed when watch cache was enabled. The watch cache returns a 410 - without the watch cache, we return 200 and then write an "error" entry to the watch stream. This broke a client that dependent on the watch behavior, and moreover is inconsistent with other errors we set in the registry. Also, for watch over web sockets, most javascript clients will be unable to get at a 410 error from the connection, because browsers don't get access to the data. We should restore the watch cache behavior to be consistent with the previous behavior as this is a regression in API semantics. Resource without watch cache, watching too old: Resource with watch cache, watching too old:
I think this is candidate for back port to 1.2 to restore the previous behavior.
since this broke your javascript client, FYI because of watch cache
+1 for backport
hmm - we enabled watch cache in 1.1 - so this should also be broken in 1.1
It's possible that it was always nondeterministic and just depends on how fast the call to the storage layer executes. I think all of our in-tree clients will handle it either way.
I'm fairly certain this never used to behave this way, because OpenShift hasn't enabled the watch catch and we have never had a report of this until we enabled the watch cache for Kube resources just recently. , Daniel Smith wrote:
I see what you mean about ordering - etcd remote call would almost never be fast enough to beat the watch event. In practice, I suspect no one ever saw this without the watch error. Either way, for web sockets if we don't fix this clients can't get this error (the browser eats the 410 during the websocket negotiation and client code can't get access). So it's at least broken for web sockets. , Clayton Coleman wrote:
Well, it should be easy to just not wait at all, maybe? I'm OK with changing this behavior.
Although, are web clients XSS hardened? I'm not sure that we're optimizing for them currently.
If you mean CSRF, it isn't an issue with bearer token auth.
Code change:
import ( "fmt" <ins> "net/http" </ins> "reflect" "strconv" "strings"

Related discussion:
text: Basic auth should already have a big warning around it saying "not safe with browsers"
Maybe I'm missing something, but it seems deterministic to me. This is the uncached watch impl: once the resourceVersion parses, there is no path that returns a direct error, so all errors would have to be returned as an event via the ResultChan(). I don't see us reading from that until after we've already written a 200 and flushed:
Having read the docs, I was very surprised that "type": "ERROR" notices are sent as 200 (even over plain http), with the semantic code e.g. 410 only represented under inside. I see there was good motivation here to stick to 200, but it should be called out in the documentation. doesn't show at all how watch returns errors, and it even says "clients must handle the case by recognizing the status code 410 Gone" which really makes one expect an actual HTTP 410.
I agree this should be called out in the docs. Can you file a bug there and/or send a PR? I don't think this ~4 year old issue is the best place to track that. (Good detective work finding this, though!)