jiebi/CodeConvo huggingface dataset:
Code change:
func StorageScratchCapacityFromFsInfo(info cadvisorapi2.FsInfo) v1.ResourceList { c := v1.ResourceList{ <del> v1.ResourceStorage: *resource.NewQuantity( </del> <ins> v1.ResourceStorageScratch: *resource.NewQuantity( </ins> int64(info.Capacity), resource.BinarySI), }

Related discussion:
text: Local storage is not expected to be available as a scheduling resource in v1.7. Kubelet is incorrectly exposing a resource named . This is incorrect because the feature is alpha and so it requires opt-in via feature flags and, the resource names are invalid. The expected resource names are listed - and . cc This is v1.7 blocker because we cannot expose a new resource in the API and rename it in a subsequent release.
CC I'll find someone on the storage team to address this.
/assign
GitHub didn't allow me to assign the following users: verult. Note that only 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
Code change:
}, ExpectedTaints: []*v1.Taint{networkUnavailableTaint}, }, <ins> { Name: "Ready is false", Node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Name:              "node0", CreationTimestamp: metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), Labels: map[string]string{ kubeletapis.LabelZoneRegion:        "region1", kubeletapis.LabelZoneFailureDomain: "zone1", }, }, Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ { Type:               v1.NodeReady, Status:             v1.ConditionFalse, LastHeartbeatTime:  metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), LastTransitionTime: metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), }, }, }, }, ExpectedTaints: []*v1.Taint{notReadyTaint}, }, </ins> } for _, test := range tests {

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:
}, ExpectedTaints: []*v1.Taint{networkUnavailableTaint}, }, <ins> { Name: "Ready is false", Node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Name:              "node0", CreationTimestamp: metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), Labels: map[string]string{ kubeletapis.LabelZoneRegion:        "region1", kubeletapis.LabelZoneFailureDomain: "zone1", }, }, Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ { Type:               v1.NodeReady, Status:             v1.ConditionFalse, LastHeartbeatTime:  metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), LastTransitionTime: metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), }, }, }, }, ExpectedTaints: []*v1.Taint{notReadyTaint}, }, </ins> } for _, test := range tests {

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:
"k8s.io/apimachinery/pkg/conversion" "k8s.io/apimachinery/pkg/types" utilnet "k8s.io/apimachinery/pkg/util/net" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" </ins> "k8s.io/kubernetes/pkg/api/v1" v1helper "k8s.io/kubernetes/pkg/api/v1/helper" "k8s.io/kubernetes/pkg/cloudprovider" <ins> "k8s.io/kubernetes/pkg/features" </ins> kubeletapis "k8s.io/kubernetes/pkg/kubelet/apis" "k8s.io/kubernetes/pkg/kubelet/cadvisor" "k8s.io/kubernetes/pkg/kubelet/events"

Related discussion:
text: Local storage is not expected to be available as a scheduling resource in v1.7. Kubelet is incorrectly exposing a resource named . This is incorrect because the feature is alpha and so it requires opt-in via feature flags and, the resource names are invalid. The expected resource names are listed - and . cc This is v1.7 blocker because we cannot expose a new resource in the API and rename it in a subsequent release.
CC I'll find someone on the storage team to address this.
/assign
GitHub didn't allow me to assign the following users: verult. Note that only 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
Code change:
dnsPolicy: Default containers: - name: fluentd-cloud-logging <del> image: gcr.io/google_containers/fluentd-gcp:1.21 </del> <ins> image: gcr.io/google_containers/fluentd-gcp:1.25 </ins> resources: limits: memory: 200Mi

Related discussion:
text: It's 400+mb and we need to pull it on every node. This leads to a lot of image pulling flake (), and also gets very expensive in some countries where bandwidth is sold at a premium. We took a stab at halving the size with: , but then realized that we were using an unsupported base image We tried to optimize to ~300Mb by building a smaller ubuntu:15 base, but that's still huge. Every other mandatory system daemon is built on busybox and so takes ~10Mb.
I can try again now that the agent supports
Newer Docker images using the spec from the official repository are based on AlpineLinux and are around ~38MB:
Code change:
waitForNumProxyLoops(t, p, 1) } <del> // TODO: Test UDP timeouts. </del> // TODO(justinsb): Add test for nodePort conflict detection, once we have nodePort wired in

Related discussion:
text: Depends on UDP clients have a timeout (so we don't leak connections forever), but the test does not cover this. To do this, we probably need to track active connections, and plumb that all the way down to the goroutines spawned by the ProxyLoop routines. This is probably something we want to do anyway to be able to monitor.
Code change:
waitForNumProxyLoops(t, p, 1) } <ins> func TestUDPProxyTimeout(t *testing.T) { lb := NewLoadBalancerRR() service := proxy.ServicePortName{NamespacedName: types.NamespacedName{Namespace: "testnamespace", Name: "echo"}, Port: "p"} lb.OnEndpointsUpdate([]api.Endpoints{ { ObjectMeta: api.ObjectMeta{Name: service.Name, Namespace: service.Namespace}, Subsets: []api.EndpointSubset{{ Addresses: []api.EndpointAddress{{IP: "127.0.0.1"}}, Ports:     []api.EndpointPort{{Name: "p", Port: udpServerPort}}, }}, }, }) p, err := createProxier(lb, net.ParseIP("0.0.0.0"), &fakeIptables{}, net.ParseIP("127.0.0.1"), nil, time.Minute) if err != nil { t.Fatal(err) } waitForNumProxyLoops(t, p, 0) svcInfo, err := p.addServiceOnPort(service, "UDP", 0, time.Second) if err != nil { t.Fatalf("error adding new service: %#v", err) } waitForNumProxyLoops(t, p, 1) testEchoUDP(t, "127.0.0.1", svcInfo.proxyPort) // When connecting to a UDP service endpoint, there shoule be a Conn for proxy. waitForNumProxyClients(t, svcInfo, 1, time.Second) // If conn has no activity for serviceInfo.timeout since last Read/Write, it shoule be closed because of timeout. waitForNumProxyClients(t, svcInfo, 0, 2*time.Second) } </ins> func TestMultiPortProxy(t *testing.T) { lb := NewLoadBalancerRR() serviceP := proxy.ServicePortName{NamespacedName: types.NamespacedName{Namespace: "testnamespace", Name: "echo-p"}, Port: "p"}

Related discussion:
text: Depends on UDP clients have a timeout (so we don't leak connections forever), but the test does not cover this. To do this, we probably need to track active connections, and plumb that all the way down to the goroutines spawned by the ProxyLoop routines. This is probably something we want to do anyway to be able to monitor.
Code change:
allowWatchBookmark bool }{ { // test old client won't get Bookmark event <del> timeout:            2 * time.Second, </del> <ins> timeout:            3 * time.Second, </ins> expected:           false, allowWatchBookmark: false, }, { <del> timeout:            2 * time.Second, </del> <ins> timeout:            3 * time.Second, </ins> expected:           true, allowWatchBookmark: true, },

Related discussion:
text: Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.
Code change:
return err } <del> if !o.Quiet && o.Stdin && t.Raw && o.Pod.Spec.RestartPolicy == corev1.RestartPolicyAlways { fmt.Fprintf(o.Out, "Session ended, resume using '%s %s -c %s -i -t' command when the pod is runningn", o.CommandName, o.Pod.Name, containerToAttach.Name) </del> <ins> if msg := o.reattachMessage(containerToAttach.Name, t.Raw); msg != "" { fmt.Fprintln(o.Out, msg) </ins> } return nil }

Related discussion:
text: When attaching to an ephemeral container, prints a message suggesting that the container can be reattached after it exists. This is not true because an ephemeral container is never restarted. This cosmetic issue should be resolved for
/assign /sig node /triage accepted /priority important-longterm
Code change:
if cpuList[1] != 1 { cpu1, cpu2 = cpuList[1], 1 } <ins> if isMultiNUMA() { cpuList = cpuset.MustParse(getCoreSiblingList(0)).ToSlice() cpu2 = cpuList[1] } } else if isMultiNUMA() { cpuList = cpuset.MustParse(getCoreSiblingList(0)).ToSlice() cpu1, cpu2 = cpuList[1], cpuList[2] </ins> } expAllowedCPUsListRegex = fmt.Sprintf("^%d|%dn$", cpu1, cpu2) err = f.PodClient().MatchContainerOutput(pod.Name, pod.Spec.Containers[0].Name, expAllowedCPUsListRegex) framework.ExpectNoError(err, "expected log not found in container [%s] of pod [%s]",

Related discussion:
text: Which jobs are failing: N/A - AFAICT CI jobs works fine Which test(s) are failing: Since when has it been failing: no historical record on CI Testgrid link: N/A Reason for failure: I believe the tests make too many assumptions around the hardware, and the code is actually OK. to be confirmed. Anything else we need to know:
/sig node /sig testing
also affects the recently topology manager e2e tests. My PR uses a different approach to check resource alignment so is not affected. /cc
I'll work on a PR to fix this issue ASAP
Thanks for opening this issue. We knew about this, just had not opened an issue to track it, so thanks for doing that! Deepthi has been looing at CPU Manager tests, not sure if she has some PR in progress or not. I'll make sure to forward this to her (can find her user id here ....) in case she has something in progress
Code change:
pod := getSwapTestPod(f, qosClass, memoryRequestEqualLimit) pod = runPodAndWaitUntilScheduled(f, pod) <del> gomega.Expect(isPodCgroupV2(f, pod)).To(gomega.BeTrueBecause("cgroup v2 is required for swap")) </del> <ins> if !isPodCgroupV2(f, pod) { e2eskipper.Skipf("swap tests require cgroup v2") } </ins> gomega.Expect(getSwapBehavior()).To(gomega.Or(gomega.Equal(types.NoSwap), gomega.BeEmpty()), "NodeConformance is expected to run with NoSwap") expectNoSwap(f, pod)

Related discussion:
text: master-informing: ci-crio-cgroupv1-node-e2e-conformanceE2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Best-effort E2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Burstable E2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Burstable with memory request equals to limit E2eNode Suite.[It] [sig-node] Swap [LinuxOnly] [NodeFeature:NodeSwap] [NodeConformance] with configuration QOS Guaranteed After was merged No response /sig node
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
/assign
/cc
Code change:
We will now update the servers that are running out in your cluster. $ cd kubernetes <del> $ cluster/cloudcfg.sh -u=30s rollingupdate dataController </del> <ins> $ cluster/kubecfg.sh -u=30s rollingupdate dataController </ins> Watch the UX, it will update one pod every 30 seconds until all of the pods have the new color.

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Overall Since when has it been failing: Nov 20 between 8:41 PST and 12:43 PST (it's been "failing" before that as well, but now none of the tests are running at all) Testgrid link: Reason for failure: Looks like  failed (), so is not building the env properly Slack discussion: Anything else we need to know*: /sig cluster-lifecycle /area provider/gcp
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
fixed here:
/assign
Code change:
# # Args: #   --input-pkg-root <string> <del> #     The root package under which to search for types.go files which request </del> <ins> #     The root package under which to search for *.go files which request </ins> #     clients to be generated.  This must be Go package syntax, e.g. #     "k8s.io/foo/bar". # <ins> #   --one-input-api <string> #     A specific API (a directory) under the --input-pkg-root for which to #     generate a client.  If this is not set, clients for all APIs under the #     input root will be generated (under the --output-pkg-root). # </ins> #   --output-pkg-root <string> #     The root package into which generated directories and files will be #     placed.  This must be Go package syntax, e.g. "k8s.io/foo/bar".

Related discussion:
text: function in script has following issues: function only supports file but we have multiple types file with name as in . Hence this function is not working in our case. For the mitigation there is already an open . I have asked for including our changes as well. We have multiple files under a for example and . Because of this for appears twice and it generates duplicate informers We only need unique elements before passing it to . I followed this approach for unique elements: We have packages under . Earlier we were generating client only for and . But with the new I am not able to do that. I am using the following call to function: It results in following flags to As there is no directory as , it doesnot generate anything. Is it still possible to call on specific folder as it was done with earlier scripts? One mitigation I can think of is to call function on whole and then remove the marker from the types for which genclient is not needed. But the issue is we won't be able to pass the flag for each pkg. function in script is not working as expected.
/sig api-machinery
/cc
/triage accepted
Hi . I knew that there were all sorts of clients out there doing all sorts of things with these scripts, so I am not surprised to find you. :) Do you have a PR which attempts to use kube_codegen, so I can repro your issues directly?
I think you have one too many in there Aside from that, the real problem here is that these old codegen tools make some deeeeeeep assumptions about the ability to string-join various arguments and get the right results. It's awful. I was trying to make it simpler in this script, which I did for all of the in-tree consumers, but out of tree people apparently don't always follow the same conventions. For example, we generate clients for every directory that requests it. For a reason I do not know, you have files like which say but you don't actually want a client? If you specify then it t
So this code expects that you generate an omnibus client. What if I add a flag, like which you can use to call it for each API to make distinct clients? In truth the codegen tools need to be fixed, but that has SO MUCH ripple I just can't right now.
Code change:
# # Args: #   --input-pkg-root <string> <del> #     The root package under which to search for types.go files which request </del> <ins> #     The root package under which to search for *.go files which request </ins> #     clients to be generated.  This must be Go package syntax, e.g. #     "k8s.io/foo/bar". # <ins> #   --one-input-api <string> #     A specific API (a directory) under the --input-pkg-root for which to #     generate a client.  If this is not set, clients for all APIs under the #     input root will be generated (under the --output-pkg-root). # </ins> #   --output-pkg-root <string> #     The root package into which generated directories and files will be #     placed.  This must be Go package syntax, e.g. "k8s.io/foo/bar".

Related discussion:
text: As the codegen was breaking us at several step, hence didn't prepared the PR.
Thanks for the PR. I have one more concern, is it possible to call and client-gen on the same pkg? With the current script, that is not possible because of the line It removes all the generated files first and then calls the . Hence the later clientset gen will remove the earlier generated clients.
Why are you generating a client for an internal version that isn't served?
My mistake. We need to stop using clients for internal versions.
Code change:
ErrCodeResourceVersionConflicts: "resource version conflicts", ErrCodeInvalidObj:               "invalid object", ErrCodeUnreachable:              "server unreachable", <ins> ErrCodeTimeout:                  "request timeout", </ins> } func NewKeyNotFoundError(key string, rv int64) *StorageError {

Related discussion:
text: It is possible to issue a list request which exceeds the duration set by the request-timeout apiserver flag. The request-timeout flag does not appear to be enforced when the apiserver is decoding the response from etcd. Specifically, listing a large number of CRDs from etcd can result in high request latency from using json encoding compared to protobuf encoding. While overall etcd latency is low, the overall listing from storage latency may be over the 1 minute timeout, particularly if the apiserver needs to fetch multiple pages from etcd. We expected the list requests to be subject to the duration specified by the request-timeout flag when this latency is coming from the listing from storage phase of the request. Create 4000 CRs and list all the objects from etcd in 2 pages of 2000 objects. If the time to list 1 page + decode takes around 50s, listing 2 pages will result in the listing from storage phase of the request taking around 1 minute and 40s before the request fails and the client is returned a 500 response code. Logs for apiserver Trace message: Audit log entry: Related issue for supporting protobuf for CRDs: <details</details<detailsAWS </details<details</details<details</details<details</details<details</details
/sig api-machinery CC:
Interesting.. - do you know where exactly we stuck? In the call to storage: we pass the context that has timeout set, so that shouldn't hang. OTOH, for the processing part: (a) I don't know if transformer honors the context - it probably depends on the implementation (b) but the decoding (appendListitem) certainly isn't honoring the context So (b) might definitely be a problem, even independently from from the transformer So I guess what I'm saying is that if listing from etcd finishes fast but the decoding is what takes most of time, then what you described can certainly be a problem. But is that the thing you're observing?
Yes, that is our understanding. Specifically, that the decoding which occurs in appendListItem doesn't respect the context: As a separate follow-up, it would be useful to include decoding time, or at least the overall listing from storage time, as a separate latency annotation, given the audit log entry is only capturing this latency as part of
+1.