jiebi/CodeConvo huggingface dataset:
Change:
"testing" api "k8s.io/api/core/v1" <ins> "k8s.io/api/storage/v1beta1" </ins> meta "k8s.io/apimachinery/pkg/apis/meta/v1" utilfeature "k8s.io/apiserver/pkg/util/feature" fakeclient "k8s.io/client-go/kubernetes/fake"

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: During I develop a driver that supports raw block devices but do not need to be attached to nodes, I found it would fail when a pod mount a raw block device. PS: I use cluster-driver register and make requiredAttach as false. kubectl get csidriver csi-xxx -o yaml ! What you expected to happen: Mount a raw block device successfully. How to reproduce it (as minimally and precisely as possible): driver that supports raw block devices but do not need to be attached to nodes, I found it would fail when a pod mount a raw block device. cluster-driver register and make requiredAttach as false. a pod with raw block devices Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: BaiduCloud OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage /assign
I would send a PR later
Change:
"//vendor/k8s.io/apimachinery/pkg/util/net:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/strategicpatch:go_default_library", <del> "//vendor/k8s.io/apimachinery/pkg/util/uuid:go_default_library", </del> "//vendor/k8s.io/apimachinery/pkg/util/validation:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/yaml:go_default_library",

Discussion:
/kind bug /priority critical-urgent What happened: In I'm removing all the reapers, unfortunately when invoking foreground deletion on a DaemonSet the delete operation hangs and controller indefinitely tries to manage a removed DS. What you expected to happen: A foreground deletion properly removes DaemonSet and all its dependents. How to reproduce it (as minimally and precisely as possible): Invoke a delete operation against kube API (without using command). Anything else we need to know?: This behavior makes it so that none of the consumers of the API is not able to remove the DS controller due to present in the DS reaper. A working fix that passed the tests with the aforementioned PR is in but I'm not 100% it's correct. This is an issue that needs fixing before 1.11 goes out. /assign /sig apps /cc
fyi
I filed to fix it. As mentioned in the PR, this is because the DaemonSet controller races with garbage collector when it tries to update DaemonSet status of the DaemonSet being deleted. Here's what happens when hangs: /something performs a foreground deletion on a DaemonSet finalizer and DeletionTimestamp are both set history objects (ControllerRevisions) and pods are being deleted by garbage collector; meanwhile, DaemonSet controller tries to update DaemonSet status. Updating DaemonSet status requires constructing DaemonSet history objects, to figure out current revision and which pods do/don't belong to current revision updating DaemonSet status, DaemonSet controller tries to create a DaemonSet history object that matches current DaemonSet spec collector then tries to delete that DaemonSet history object. And repeat. Because we can't make DaemonSet pods be deleted before DaemonSet history objects (DaemonSet history objects don't own DaemonSet pods!), we cannot reliably calculate DaemonSet status without history objects anyways. Therefore, we don't update DaemonSet status for DaemonSet being deleted. Note that the reason why the kubectl delete hack works is because it forces DaemonSet pods to be removed before history objects.
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed.

: Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
utilflowcontrol "k8s.io/apiserver/pkg/util/flowcontrol" clientv3 "go.etcd.io/etcd/client/v3" "k8s.io/klog/v2" )

Discussion:
TestChangeCRD " TestChangeCRD": 37, Recently, not sure the date. No response_ /sig api-machinery
also flaking in weirdly, this doesn't show up at all in
cc I can't tell if this is related to the openapi change or not
Actually, I think this is an issue either with the test or with watch behavior, not sure which. The test starts 10 watches, lets them run, then waits for them to exit cleanly, and instead, they are getting watch errors. I can't tell if the watch errors are expected or not, or if server or watch client behavior changed here or not. Opened to debug further
and stand out as a recent change to watching
cc on whether the watching changes in could explain this integration test getting watch errors it didn't previously get
also stands out
would explain this integration test getting watch errors it didn't previously get?
the filter is enabled only when the server run option has a positive time duration (the default is zero). I searched the k/k repo, only the unit tests in enables this filter: I did a quick scan of the logs, did not see any graceful termination activity either. I will take a deeper look at the logs
and all merged changes were limited to that filter?
This is a Go test, so the entire test output is treated as the failure message. That output is very different from one failure to the other, so in triage we probably have x different "clusters" with one failure in each, instead of one cluster with x failures. I don't know what triage does with such small clusters.
we have changes in only the the filter adds to the request context, I just searched the code base, did not find any other call site for by default, should block (on a nil channel) If the test is receiving an event, it implies that the following case is executing, right?
xref: ??
Thank you all for deflaking.
/triage accepted
Change:
{ObjectMeta: metav1.ObjectMeta{Name: "nodeB", Labels: label2}}, {ObjectMeta: metav1.ObjectMeta{Name: "nodeC", Labels: label3}}, }, <ins> expectedAntiAffinity: topologyToMatchedTermCount{ {key: "region", value: "r1"}: 2, {key: "zone", value: "z11"}:  2, {key: "zone", value: "z21"}:  1, }, expectedAffinity: topologyToMatchedTermCount{}, </ins> }, { name: "preFilterState matching pod affinity and anti-affinity are updated correctly after adding and removing a pod", pendingPod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "pending", Labels: selector1}, <ins> Spec: v1.PodSpec{ Affinity: &v1.Affinity{ PodAffinity: affinityComplex, }, }, </ins> }, existingPods: []*v1.Pod{ {ObjectMeta: metav1.ObjectMeta{Name: "p1", Labels: selector1},

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Maybe it should be What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig Scheduling
I feel it is a valid error. But need confirmation from sig-scheduling maintainers. ... is it okay if I work on this?
ok
Yeah, this is a bug in preemption
/assign
Change:
} func (a *poller) Run(stopCh <-chan struct{}) { <del> var failure int go wait.Until(func() { configuration, err := a.get() if err != nil { failure++ if failure >= a.failureThreshold { a.notReady() } return </del> <ins> go wait.Until(a.sync, a.interval, stopCh) } func (a *poller) sync() { configuration, err := a.get() if err != nil { a.failures++ if a.failures >= a.failureThreshold { a.notReady() </ins> } <del> failure = 0 a.setConfigurationAndReady(configuration) }, a.interval, stopCh) </del> <ins> return } a.failures = 0 a.setConfigurationAndReady(configuration) </ins> }

Discussion:
Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.
Change:
if !strings.HasPrefix(mp, myMPSlash) { continue // skip -- not nested beneath myMountPoint } <del> if prevNestedMP != "" && strings.HasPrefix(mp, prevNestedMP) { </del> <ins> isNested := false for _, prevNestedMP := range prevNestedMPs { if strings.HasPrefix(mp, prevNestedMP) { isNested = true break } } if isNested { </ins> continue // skip -- double nested beneath myMountPoint } // since this mount point is nested, remember it so that we can check that following ones aren't nested beneath this one <del> prevNestedMP = mp + string(os.PathSeparator) </del> <ins> prevNestedMPs = append(prevNestedMPs, mp+string(os.PathSeparator)) </ins> retval = append(retval, mp[len(myMPSlash):]) } }

Discussion:
to have all the mount points sorted and grouped. For example, the following strings are sorted in this exact order: With the current implementation, test, we would get: This is worse on Windows, where paths usually have backslashes instead (with no test changes): [1] ` should group mount points correctly. /kind bug /sig windows Kubernetes master, Kubernetes v1.25 and older. N/A N/A <details</details<details</details<details</details
/triage accepted /milestone v1.26
Change:
http.Error(w, "", http.StatusNotFound) return } <del> json, err := runtime.Encode(r.codecs.LegacyCodec(), discoveryGroup) if err != nil { http.Error(w, err.Error(), http.StatusInternalServerError) return } if _, err := w.Write(json); err != nil { panic(err) } </del> <ins> responsewriters.WriteObjectNegotiated(r.codecs, schema.GroupVersion{}, w, req, http.StatusOK, discoveryGroup) </ins> }

Discussion:
<!-- 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 ): build--5-v1.7.5-3 Environment: Cloud provider or hardware configuration: Laptop (bare metal) OS (e.g. from /etc/os-release): Fedora 26 Kernel (e.g. ): Linux localhost.localdomain 4.11.0-0.rc6.git0.1.fc26.x8664 SMP Mon Apr 10 19:45:50 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: make && hack/local-cluster- -o _output/bin What happened: built from and ran with local-cluster- All commands gave the following error: Running showed the output: What you expected to happen: for commands to work, and Content-type to show How to reproduce it (as minimally and precisely as possible):
ccing
I see the text plain content type, but not kubectl errors
i was using the wrong version of kubectl. updated to new and i'm not getting an error any longer.
Text/plain coming back from the server is still an issue
cc
I'm not seeing against head and the pastebin is gone. Did you reproduce?
I did last week. Insecure and secured port behaved differently
You can reproduce this using against a Kubernetes cluster built from HEAD
Hi all, I think we could use write Content-type correctly. I have made a PR to fix this.
Change:
#   KUBE_PASSWORD function get-password { # go template to extract the auth-path of the current-context user <del> local template='{{$ctx := index . "current-context"}}{{$user := index . "contexts" $ctx "user"}}{{index . "users" $user "auth-path"}}' </del> <ins> local template='{{with $ctx := index . "current-context"}}{{$user := index . "contexts" $ctx "user"}}{{index . "users" $user "auth-path"}}{{end}}' </ins> local file=$("${KUBE_ROOT}/cluster/kubectl.sh" config view -o template --template="${template}") <del> if [[ -r "$file" ]]; then </del> <ins> if [[ ! -z "$file" && -r "$file" ]]; then </ins> KUBE_USER=$(cat "$file" | python -c 'import json,sys;print json.load(sys.stdin)["User"]') KUBE_PASSWORD=$(cat "$file" | python -c 'import json,sys;print json.load(sys.stdin)["Password"]') return

Discussion:
contains function get-password. This uses a template which gets the current context. But a user who has not yet used the kubectl contexts feature has no context set. This causes a nil pointer deref while evaluating the template.
I think kube-up creates the needed entries in the .kubeconfig file. But it calls get-password before it does that. Need to allow the kubectl config view command to fail.
okay, I have a fix.
Change:
// 2. the ones passed in from framework.TestContext.ExtraEnvs // So this function needs to be called after the extra envs are applied. func updateImageWhiteList() { <del> // Union NodeImageWhiteList and CommonImageWhiteList into the framework image white list. framework.ImageWhiteList = NodeImageWhiteList.Union(commontest.CommonImageWhiteList) </del> <ins> // Union NodePrePullImageList and CommonImageWhiteList into the framework image pre-pull list. framework.ImageWhiteList = NodePrePullImageList.Union(commontest.CommonImageWhiteList) </ins> // Images from extra envs framework.ImageWhiteList.Insert(getNodeProblemDetectorImage()) framework.ImageWhiteList.Insert(getSRIOVDevicePluginImage())

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should come up with a better name for : Why is this needed: From /sig testing /priority important-soon /cleanup /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --We should come up with a better name for : From /priority important-soon /cleanup /help /good-first-issue 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'd like to help out with this. /assign
mind. It seems like you have a PR for it already. /unassign
And I misread the changes you made in . I'm back on this one. /assign
I'm going to rename this to . Please let me know if there are any objections or if there are things that I should be considering.
please feel free to take it. I'm only changing ImageWhileList withint
ultimately was changed to NodePrePullImageList because that's what it's actually used for, not for any sort of filtering.
Change:
Skip("Nvidia GPUs do not exist on the node. Skipping test.") } <ins> framework.WaitForAllNodesSchedulable(f.ClientSet, framework.TestContext.NodeSchedulableTimeout) </ins> By("Creating the Google Device Plugin pod for NVIDIA GPU in GKE") devicePluginPod = f.PodClient().CreateSync(framework.NVIDIADevicePlugin(f.Namespace.Name))

Discussion:
<!-- 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: The test has been failing since Nov 22nd. Looks like it is because the test restarts Kubelet and then calls getLocalNode() which checks for node readiness. Not sure why this problem only started to show up recently. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.9 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): COS Kernel (e.g. ): Install tools: Others:
/sig node
Hi, Just FYI, . Maybe it is helpful for you.
Change:
} orphan := false switch { <ins> case options.OrphanDependents == nil && options.PropagationPolicy == nil && len(initialFinalizers) == 0: // if there are no deletion options, the default policy for replication controllers is orphan orphan = true </ins> case options.OrphanDependents != nil: // if the deletion options explicitly specify whether to orphan, that controls orphan = *options.OrphanDependents

Discussion:
Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: TestStressingCascadingDeletion Testgrid link: Reason for failure: Maybe related: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig api-machinery
I'm seeing lots of these.
post-submit failures (all of these are flakes):
first failure seen in postsubmit is , part of ... preceeding many runs looked clean
I verified the delete options as seen by the server are identical before and after , so I don't think it is a functional change related to that PR
notably, many other tests in this suite started flaking on 3/7 and after ()
figured it out, dropped the detection of empty deletion options which would trigger the test to wait for all pods to be observed by the GC controller
Change:
"encoding/json" "fmt" "io" <del> "io/ioutil" </del> "strings" "unicode" jsonutil "k8s.io/apimachinery/pkg/util/json" <del> "k8s.io/klog/v2" </del> "sigs.k8s.io/yaml" )

Discussion:
This bug was privately disclosed and told to open here. What happened: NewYAMLOrJSONDecoder from has an index out of bounds issue which can cause callers to panic. Download attached reproducer file Run golang test: When run with v0.19.3: Additionally, this can be seen in kubectl directly (below is kubectl 1.20.0): Environment: Kubernetes version (use ): Verified with 1.19, 1.20
/sig api-machinery
This piece attempts to find line+column position of a json syntax error. To do that it assumes that full input is available which is not true: is : is only the first data chunk: The subject happens e.g. when syntax error offset is past buffer size and Test to reproduce the panic: I am not sure it is easily possible to find line+column of json syntax error as full input may not be available. Maybe it should only attempt to find line+column if offset is within the first chunk (i.e. below buffer size).
Line number calculation in and updated in
do you want to submit a patch to with a defensive check to avoid the panic ( compare and )
I have raised a discussion on having line number in the . The consensus there is that it should be possible to count lines with a full input at hand and it does not worth to have it in the core library due to performance impact and maintenance costs. The problem of here is that it attempts to find out line number without having full input at hand. I think the defensive patch is not the right approach because line calculation is incorrect anyway even when there is no panic: begins at a value with a syntax error, i.e. in a stream of two values and syntax error in the second value it would contain only the second value and thus new lines in the first value in the stream would not be counted. I think the following options are there: to stream taken from . This is straightforward but changes interface. I can not find any code that uses field, it is only used in the error message that would change: line number only if offset is within the length of the first data chunk (). I am not sure what would be the unknown line number then, perhaps. line number properly during stream decoding, see This has some performance penalty as line number is calculated in any case even if there is no syntax error, i.e.

in the majority of the cases.
cc /triage accepted
This is probably acceptable.
I have opened a PR
Thank you for support.
Change:
# Start a single instance of hazelcast and set environment variables "DNS_DOMAIN=cluster" and "POD_NAMESPACE=default" in the container. kubectl run hazelcast --image=hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default" <ins> # Start a single instance of hazelcast and set labels "app=hazelcast" and "env=prod" in the container. kubectl run hazelcast --image=nginx --labels="app=hazelcast,env=prod" </ins> # Start a replicated instance of nginx. kubectl run nginx --image=nginx --replicas=5

Discussion:
If you run a command like: $ kubectl run --image=nginx --labels app=web --labels env=prod web It only uses the latest declaration of and drops the earlier options specified. Especially because the --help documentation on does not specify the format, this is impairing the user experience. I looked around a few other CLIs to see how they handle this. curl, for example, uses to additively collect headers (instead of a comma-separated list), therefore each value specified is used. "docker run" command ignores the earlier --name argument when you specify another one. I am wondering if we can easily detect non-additive/overwriting args specified multiple times in an invocation. /kind bug /sig cli
I think this is reasonable for improving cli tool user experience. For different commands, it may different in the options, but for each of them we can add warning messages at least for the end user to realize what had happened in the backend, especially for the ignored staff
/sig cli
why use for flag instead of ? i don't think should overwrite
/cc
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
500, /* cpuLimit */ 200, /* memLimit */ f) <del> common.CreateCPUHorizontalPodAutoscaler( </del> <ins> t.hpa = common.CreateCPUHorizontalPodAutoscaler( </ins> t.rc, 20, /* targetCPUUtilizationPercent */ 1,  /* minPods */

Discussion:
Currently the time it takes for HPA and CA to scale up after load increase is not measured at all, and this can lead to regressions that will be missed. This issue is about adding an e2e test that will prevent such regressions.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
Filip, can you reopen? I cannot do this myself, and this issue is clearly not closed yet.
Thanks Wojtek!