jiebi/CodeConvo huggingface dataset:
Code change:
}, { "ImportPath": "github.com/evanphx/json-patch", <del> "Rev": "ed7cfbae1fffc071f71e068df27bf4f0521402d8" </del> <ins> "Rev": "94e38aa1586e8a6c8a75770bddf5ff84c48a106b" </ins> }, { "ImportPath": "github.com/exponent-io/jsonpath",

Related discussion:
text: /kind bug What happened: Wrote a that returned a faulty json patch which specified an our of range index (e.G. when there is only one container). This resulted in the apiserver crashing. Stacktrace: What you expected to happen: No crash /sig-api-machinery
/sig api-machinery
This maybe a bug in . I will follow this question.
This bug had been fixed in PR: you can checkout it.
Thanks for your comment but I don't think the linked PR fixed the issue, as it got merged almost a year ago and I am running Kube 1.10.1 which does contain that patch but still panics. Just from quickly looking at the code I the linked PR I believe there are two things wrong: The check if the index is valid only happens when a negative index was given should be
Once the PR of is merged I will update kubernetes.
/kind bug
Code change:
if (endpoints.subsets != null && !endpoints.subsets.isEmpty()){ for (Subset subset : endpoints.subsets) { for (Address address : subset.addresses) { <del> list.add(InetAddress.getByName(address.IP)); </del> <ins> list.add(InetAddress.getByName(address.ip)); </ins> } } } <del> } </del> <ins> logger.info("Available endpoints: " + list); } else { logger.warn("Endpoints are not available"); } </ins> } catch (IOException | NoSuchAlgorithmException | KeyManagementException ex) { logger.warn("Request to kubernetes apiserver failed", ex); }

Related discussion:
text: The namespace seems to be hard coded :
cc:
Thanks. We can improve it after v1 release.
Code change:
// +k8s:deepcopy-gen=package <del> package testing </del> <ins> package testing // import "k8s.io/apimachinery/pkg/runtime/serializer/testing" </ins>

Related discussion:
text: Look at one of the directories under (Please don't pick more than one directory for one PR as it will cause issues for reviewers) Find all the files named (example find -name ) See the following link it has a this tells tools how this package needs to be imported. So we should ensure that each has an import Add a description appropriate to the package (similar to the one below) Look through sub directories and see if there are any other important directories that are likely to be used by outside users and add a Why are we doing this? We perfer to use vanity urls instead of directly using to refer to code, so this helps ensure that tools honor our wish. See It would be good to have some package level documentation since these directories under staging/ are meant to be for use by folks outside of kubernetes github org. /good-first-issue
/kind documentation /sig architecture
currently working my through Not going to use / assign since there could be a number of PRs for this issue.
/lifecycle active /good-first-issue edit: hmm..
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 : /lifecycle active /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
May I try on
IIUC this means that there needs to be a even at the root of the repo? Then how does work? :thinking:
Hi , can I make a PR for this directory ?
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
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 .
Code change:
// +k8s:deepcopy-gen=package <del> package testing </del> <ins> package testing // import "k8s.io/apimachinery/pkg/runtime/serializer/testing" </ins>

Related discussion:
text: /lifecycle rotten
I guess this is still not done, was supposed to partially fix this issue. /reopen
Reopened this issue. <detailsIn response to : I guess this is still not done, was supposed to partially fix this 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
/remove-lifecycle rotten /area code-organization
Code change:
"k8s.io/api/core/v1" settings "k8s.io/api/settings/v1alpha1" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/watch"

Related discussion:
text: <!-- 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: is consistently failing because of PodPreset feature tests, which require settings/v1alpha1, which is no longer enabled by default What you expected to happen: . How to reproduce it (as minimally and precisely as possible): . Anything else we need to know?: This was caused by and kubernetes/test-infra Environment: . Kubernetes version (use ): . Cloud provider or hardware configuration**: . OS (e.g. from /etc/os-release): . Kernel (e.g. ): . Install tools: . 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 service-catalog
does the alpha CI job enable alpha API versions?
file has "AllAlpha=true" Maybe would be better?
Code change:
testCase.modifyRest(storage) } <del> err := storage.tryDefaultValidateServiceClusterIPFields(&testCase.svc) </del> <ins> err := storage.tryDefaultValidateServiceClusterIPFields(testCase.oldSvc, &testCase.svc) </ins> if err != nil && !testCase.expectError { t.Fatalf("error %v was not expected", err) }

Related discussion:
text: 1) start with a single stack cluster 2) create a PreferDualStack service 3) configure API server with a 2nd service CIDR 4) Confirm the above service is not dual-stack 5) Add a label to the above service 6) Observe that the service becomes dual-stack I think the correct answer is to have a "repair loop" that upgrades (and downgrades!) PreferDualStack Services to match the config. I think this is a GA blocker.
/triage accepted The current thought is: of type with are special new breed of api objects that I don't think we have any similar precedent in the apis, i could be wrong. Their behavior is tied to how the cluster is configured. Thus their behavior must change as the cluster behavior change. a way the user is stating . If it is cluster then i am good with two ClusterIPs. If it is single stack cluster then I am also good with a single ClusterIP. One can assume that if the user was ok was with getting a additional IP when possible then they must be ok with taking it away when it is no longer possible. Based on the above I believe best course of action is create a new repair loop or piggyback on any of the existing (or better: fix it in rest stack during list and get calls). The new logic takes care of matching to the .
reproducer and regression test if somebody takes this, feel free to add it
ack - Scheduled to tackle 3rd week of May. Will definitely include that patch.
Code change:
type multiGroupVersioner struct { target             schema.GroupVersion acceptedGroupKinds []schema.GroupKind <ins> coerce             bool </ins> } // NewMultiGroupVersioner returns the provided group version for any kind that matches one of the provided group kinds.

Related discussion:
text: What happened: Set up a HA cluster with 1.9 and 1.10 API servers (occurs on any apiserver skew boundary where a cohabitating resource's storage version changed groups) Observed errors when modifying workload objects: when modified via the 1.10 server, saw this error in the 1.9 server: when modified via the 1.9 server, saw this error in the 1.10 server: When this error was encountered, all watchers for the resource in question would be dropped and have to re-establish, and the internal watchers feeding the watch cache would drop and re-establish What you expected to happen: Watch events from all supported storage versions are processed correctly How to reproduce it (as minimally and precisely as possible): Start a server from master (for inspectability, store in json). With Create a deployment (e.g. kube-dns in kube-system) Establish a watch via extensions (kubectl get deployments.extensions --all-namespaces -w) Establish a watch via apps (kubectl get --all-namespaces -w) Tail the kube-apiserver log Change the apps/v1 deployment in etcd to extensions/v1beta1: Observer client watches drop and server log errors: Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig api-machinery /cc /priority critical-urgent
error is triggered by this returning false: constructed here: the info about expected cohabitating groups is not included in the list of acceptable inputs
Code change:
// while making decisions. BalanceAttachedNodeVolumes featuregate.Feature = "BalanceAttachedNodeVolumes" <del> // owner: @kevtaylor // alpha: v1.14 // beta: v1.15 // ga: v1.17 // // Allow subpath environment variable substitution // Only applicable if the VolumeSubpath feature is also enabled VolumeSubpathEnvExpansion featuregate.Feature = "VolumeSubpathEnvExpansion" </del> // owner: @vladimirvivien // alpha: v1.11 // beta:  v1.14

Related discussion:
text: /kind cleanup /sig storage /sig node Description: Feature gate VolumeSubpathEnvExpansion was GA in 1.17 and is marked for removal in 1.19 Related Issues: GA Release:
/assign
/cc
Code change:
legacyregistry.MustRegister(CgroupManagerDuration) legacyregistry.MustRegister(PodWorkerStartDuration) legacyregistry.MustRegister(ContainersPerPodCount) <del> legacyregistry.RawMustRegister(newPodAndContainerCollector(containerCache)) </del> legacyregistry.MustRegister(PLEGRelistDuration) legacyregistry.MustRegister(PLEGDiscardEvents) legacyregistry.MustRegister(PLEGRelistInterval)

Related discussion:
text: Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign
Code change:
}, } podWithHook := getPodWithHook("pod-with-prestop-https-hook", imageutils.GetPauseImageName(), lifecycle) <ins> // make sure we spawn the test pod on the same node as the webserver. nodeSelection := e2epod.NodeSelection{} e2epod.SetAffinity(&nodeSelection, targetNode) e2epod.SetNodeSelection(&podWithHook.Spec, nodeSelection) </ins> testPodWithHook(podWithHook) }) })

Related discussion:
text: release-master-informing: capz-windows-containerd-masterKubernetes e2e suite: [It] [sig-node] Container Lifecycle Hook when create a pod with lifecycle hook should execute prestop https hook properly [MinimumKubeletVersion:1.23] [NodeConformance] Kubernetes e2e suite: [It] [sig-node] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart https hook properly [MinimumKubeletVersion:1.23] [NodeConformance] Both the tests have been failing during most of the runs since 20th October Kubernetes e2e suite: [It] [sig-node] Container Lifecycle Hook when create a pod with lifecycle hook should execute prestop https hook properly [MinimumKubeletVersion:1.23] [NodeConformance] | 1m6s -- | -- {Oct 31 18:42:02.425: Timed out after 30.001s. Expected <errors.errorString | 0xc0015283b0: { s: "failed to match regexp "GET /echo?msg=prestop" in output "I1031 18:41:06. 8988 ] Started HTTP server on port 9090nI1031 18:41:06. 8988 ] Started UDP server on port 9091n"", } to be nil failed (0xc000f1d000) +0x469 () +0x335} Kubernetes e2e suite: [It] [sig-node] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart https hook properly [MinimumKubeletVersion:1.23] [NodeConformance] | 5m11s -- | -- {Oct 31 19:05:50.205: timed out while waiting for pod container-lifecycle-hook-6892/pod-with-poststart-https-hook to be running and ready failed (PodClient).CreateSync(0xc000eb5920, 0x22?) +0x94 (0xc0045e8c00) +0x73 () +0x325} No response_ /sig windows cc
/triage accepted /cc
These failures happen also with Kubernetes master + containerd master with Flannel CNI. Testgrid link:
I figured out why these new failures appear.
Code change:
}, } podWithHook := getPodWithHook("pod-with-prestop-https-hook", imageutils.GetPauseImageName(), lifecycle) <ins> // make sure we spawn the test pod on the same node as the webserver. nodeSelection := e2epod.NodeSelection{} e2epod.SetAffinity(&nodeSelection, targetNode) e2epod.SetNodeSelection(&podWithHook.Spec, nodeSelection) </ins> testPodWithHook(podWithHook) }) })

Related discussion:
text: I've submitted the fix via PR
This issue is also affecting 1.25 tests: If possible, we should cherry-pick to the release-1.25 branch once it's merged on master.
Code change:
func main() { klog.InitFlags(nil) if err := app.Run(); err != nil { <del> fmt.Fprintf(os.Stderr, "error: %vn", err) </del> os.Exit(1) } <del> os.Exit(0) </del> }

Related discussion:
text: <!-- 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: kubectl version --client=yes command is giving the following error message. Error message is repeated at the start and the end and also containing programming jargon Error: invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). invalid argument "yes" for "--client" flag: strconv.ParseBool: parsing "yes": invalid syntax What you expected to happen: The error message can be improved with one of the two variants invalid argument "yes" for "--client" flag Examples: Print the client and server versions for the current context kubectl version Options: --client=false: Client version only (no server required). -o, --output='': One of 'yaml' or 'json'. --short=false: Print just the version number. Usage: kubectl version [flags] [options] Use "kubectl options" for a list of global command-line options (applies to all commands). (or) Invalid argument "yes" for "--client" flag How to reproduce it (as minimally and precisely as possible): Run the command kubectl version --client=yes Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: AWS OS (e.g: ): Amazon Linux Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cli
Hi Thanks for posting this issue! It turns out that this duplicate output has been in kubectl, and all the other cli cmds, since . This should be fixed by , and hopefully we can cherry pick it back to at least .
Code change:
glog.V(4).Infof("Pod %s deleted.", pod.Name) if d := dc.getDeploymentForPod(pod); d != nil && d.Spec.Strategy.Type == extensions.RecreateDeploymentStrategyType { // Sync if this Deployment now has no more Pods. <del> rsList, err := dc.getReplicaSetsForDeployment(d) </del> <ins> rsList, err := util.ListReplicaSets(d, util.RsListFromClient(dc.client)) </ins> if err != nil { return }

Related discussion:
text: IMO it feels like a bad practice to have mutating resource handlers. The deletePod handler is used for queueing a Recreate deployment once it has no pods running. It should merely look at the ReplicaSets that have owner refs as opposed to using dc.getReplicaSetsForDeployment. The orphaning/adoption dance is already happening inside the reconcilation loop.
I'd like to work on this
feel free to grab it. I can't assign the issue to you so I'll add myself; ping me on the PR when you have one.
Code change:
namespace := nsObj.(*api.Namespace) // upon first request to delete, we switch the phase to start namespace termination <del> if namespace.DeletionTimestamp == nil { </del> <ins> if namespace.DeletionTimestamp.IsZero() { </ins> now := util.Now() namespace.DeletionTimestamp = &now namespace.Status.Phase = api.NamespaceTerminating

Related discussion:
text: There is a funny subtle behvaiour in get namespaces, in which if i call more than one time, it seems that the removal from Terminating state is accelarated. It seems this might indicate a bug, or maybe its not a bug and the eventual semantics of is a little funny sometimes. in any case, here's what we are seeing : 1) when i delete a namespace the first time usning kubectl, we get a state change to . that is correct, of course. 2) but ... if make the call a second time, then the same status line is immediately removed from . Expected behaviour : A second call to "kubectl delete ..." shouldn't have any effect on the timing of removal of a namespace from 'Terminating' state*... So i guess there is some "eventual consistency" subtle bug that is resolved by repeated calls to
suggests this may not be e bug, maybe its just the etcd eventual deleter thingy.
Looks to definitely be a bug. The 2nd delete seems to have interrupted the delete process and artifacts (like events) from the namespace still exist in etcd.
investigating...
oops, see the error, will submit a fix.
I have a fix, but need a test case, will submit PR tomorrow AM
Code change:
<del> 2.50 </del> <ins> 2.51 </ins>

Related discussion:
text: The test image currently uses as its BASEIMAGE: Per , v3.12 reached end of support on 2022-05-01 and is no longer receiving regular bugfixes or security fixes. Current versions of the image appear vulnerable to known CVEs as a result. I don't know if a fix is quite as simple as just The image's base should be an in-support version which is maintained with at least security fixes. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig testing
is like that, but then there are 2 additional steps the changes the image that has been built with the postsubmit job the repo to use the new image More detail in If you want to try, please make sure you are going to follow up with all the steps, you can see other promotions PRs too /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : is like that, but then there are 2 additional steps promote the image that has been built with the postsubmit job update the repo to use the new image </details
Thank you for this information! Is the manual and of images described in that same document something that you would consider a prerequisite for a proposed change like this? Or is it safe to assume that the automated PR test bucket(s) would provide sufficient test coverage?
I always trust the CI system
Good enough for me! Leading off with
/triage accepted
Code change:
} output, err := json.Marshal(agg) require.NoError(t, err) <del> // Content-type is "aggregated" discovery format. w.Header().Set("Content-Type", AcceptV2Beta1) </del> <ins> // Content-Type is "aggregated" discovery format. Add extra parameter // to ensure we are resilient to these extra parameters. w.Header().Set("Content-Type", AcceptV2Beta1+"; charset=utf-8") </ins> w.WriteHeader(http.StatusOK) w.Write(output) }))

Related discussion:
text: We are using (and ) to interact with Kubernetes clusters behind a couple of proxy layers. One of these proxies completes the headers to include character encoding details. This was working fine until recently, when client-go/kubectl have started to fail when interacting with the discovery API. It seems that a recent change has made kubectl more restrictive of the content-type that it expects. I suspect that it is related to this commit: For example, this is an error from a kubectl command: We can of course try to fix it on our end, removing that charset information. However, it is a valid content-type and the way kubectl is handling the content-type there seems like it is relying on implementation details of kube-apiserver (that it does not add metadata to the content-type). I propose to fix this issue in , by properly parsing and handling the content-type.
cc /kind regression /kind bug /sig api-machinery /priority important-soon looks like the switch statement in downloadLegacy() needs to be more tolerant of the variety of content-types it can get from a server (including text/plain or no content-type if old servers could have returned that...)
/transfer kubernetes/kubernetes
Something went wrong or the destination repo kubernetes/kubernetes/kubernetes does not exist. <detailsIn response to : /transfer kubernetes/kubernetes 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
/transfer kubernetes
Yep, the string comparison for the content-type is flimsy, let's address that. Thanks for the report!
/assign
/triage accepted
/cc
The fix is being cherry-picked back to: : :