jiebi/CodeConvo huggingface dataset:
Change:
iterations := 100 <ins> ginkgo.By("getting a starting resourceVersion") configmaps, err := c.CoreV1().ConfigMaps(ns).List(context.TODO(), metav1.ListOptions{}) framework.ExpectNoError(err, "Failed to list configmaps in the namespace %s", ns) resourceVersion := configmaps.ResourceVersion </ins> ginkgo.By("starting a background goroutine to produce watch events") donec := make(chan struct{}) stopc := make(chan struct{})

Discussion:
By inspection, the "should receive events on concurrent watches in same order" conformance test does two things that are not stable: Starts watches from resourceVersion=0 Relies on watch connections without handling timeouts/restarts This test can fail on clusters that have configmaps autocreated in namespaces already because ordering of watch events for resourceVersion=0 watches is undefined (see ) Watch connections used by conformance tests should use well-defined ordering (starting from resourceVersions other than 0) and handle interruptions properly. 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:
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
Change:
// GetSELinuxSupport returns true if given path is on a mount that supports // SELinux. func (hu *HostUtil) GetSELinuxSupport(pathname string) (bool, error) { <del> return GetSELinux(pathname, procMountInfoPath) </del> <ins> return GetSELinux(pathname, procMountInfoPath, selinux.SELinuxEnabled) </ins> } // GetOwner returns the integer ID for the user and group of the given path

Discussion:
On a busy system, kubelet failed to tell the container runtime that a pod's CSI volume supports SELinux and should be relabeled with pod's SELinux label. The pod then can't access the volume. Kubelet correctly detects that the CSI volume supports SELinux and tells the container runtime to relabel it. Unknown. Get a busy system and try hard? CSI volume plugin tried to detect that the volume supports SELinux during SetupAt. This check failed: Current CSI volume plugin code silently consumes the error and assumes that the volume does not support SELinux at all: Therefore, the volume is marked as mounted and given to the container runtime without the right SELinux options and the runtime does not relabel volume. <details22.0 </details<detailsNone </details<details</details<details</details<detailsCRI-O, but I think it's not really relevant. </details<details</details
/sig storage /triage accepted
We've updated kubelet in our clusters to v1.20.13 (which contains the cherry picked fix), but still observe the issue
Change:
} cfg.NodeCIDRMaskSize = o.NodeCIDRMaskSize <ins> cfg.NodeCIDRMaskSizeIPv4 = o.NodeCIDRMaskSizeIPv4 cfg.NodeCIDRMaskSizeIPv6 = o.NodeCIDRMaskSizeIPv6 </ins> return nil }

Discussion:
What happened: I used dual-stack and set the parameter of kube-controller to --node-cidr-mask-size-ipv4=24 --node-cidr-mask-size-ipv6=96, but the podCidr my node got was still a /64 mask What you expected to happen: The mask the node gets should be the /96 I set How to reproduce it (as minimally and precisely as possible): Deploy the cluster using kubeadm, which is configured as followsAnd modify the network-plugin of kubelet to be kubenet Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: KVM virtual machine OS (e.g: ): VERSION="18.04.2 LTS (Bionic Beaver)" Kernel (e.g. ): Linux k8s02-01 4.15.0-70-generic -Ubuntu SMP Tue Nov 12 10:36:11 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
is the configuration above correct? should be using integers instead of strings to configure the node-cidr-masks? Ref.
I initially tried using integers, but kubeadm init reported an error.That's why I replaced it with a string, and then I didn't get an error
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
thank you for reporting this. I'll take a look.
/assign
Change:
// Returns a cache.ListWatch that finds all pods that need to be // scheduled. func (factory *ConfigFactory) createUnassignedPodLW() *cache.ListWatch { <del> return cache.NewListWatchFromClient(factory.Client, "pods", api.NamespaceAll, fields.Set{getHostFieldLabel(factory.Client.APIVersion()): ""}.AsSelector()) </del> <ins> return cache.NewListWatchFromClient(factory.Client, "pods", api.NamespaceAll, fields.Set{client.PodHost: ""}.AsSelector()) </ins> } func parseSelectorOrDie(s string) fields.Selector {

Discussion:
My broke it for v1beta3, then fixed it for v1beta3 and broke it for v1beta1. I'm working on a fix.
Honestly I'm very surprised that more people aren't complaining-- integration test logs are full of noise because of this.
Exact text of error log is "Failed to watch *api.Node: field label not supported: "
cc
Change:
visibility = ["//visibility:public"], deps = [ "//pkg/api/legacyscheme:go_default_library", <ins> "//pkg/apis/admission/install:go_default_library", "//pkg/apis/admissionregistration/install:go_default_library", "//pkg/apis/apiserverinternal/install:go_default_library", </ins> "//pkg/apis/apps/install:go_default_library", "//pkg/apis/authentication/install:go_default_library", "//pkg/apis/authorization/install:go_default_library",

Discussion:
What happened: Tried to convert a v1beta1 Ingress object to v1, and received the following error: What you expected to happen: The conversion to work. How to reproduce it (as minimally and precisely as possible): Then run: /sig cli /assign
Can i work on this issue?
/assign
/triage accepted
Change:
REGISTRY?=gcr.io/google-containers IMAGE?=debian-hyperkube-base <del> TAG=0.5 </del> <ins> TAG=0.6 </ins> ARCH?=amd64 CACHEBUST?=1

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods with volumeMount gitRepo volumes in 1.8.0 see the following error in kubelet logs (also in ) It is important to not that the git repo clone is done via ssh. I think what is happening is that hyperkube image now used to have command in it and now it does not have it. So the git clone command that kubelet runs fails with the above stacktrace since it cannot find . What you expected to happen: gitRepo is volume mounted. How to reproduce it (as minimally and precisely as possible): Reproducible in kubernetes 1.8.0+ hyperkube images. Anything else we need to know?: This probably is due to missing ssh binary in the new 1.8.0 hyperkube images. The commit might be an issue. Will comment further if I find otherwise. Environment: Kubernetes version (use ): =1.8.0 Cloud provider or hardware configuration**: Not Application. OS (e.g. from /etc/os-release): hyperkube base image Kernel (e.g. ): Install tools: Others:
How did you installed Kubernetes may I ask?
how does this help?
Normally, it is suggest to install kubelet as a daemon on host instead of using hyperkube container. cc you may be interested in this issue.
Need your help in identifying the fix here. I can send something for review. Suggestions are welcome.
The problem is that ssh isn't installed inside of the container. I don't know if it should be either, as the hyperkube image grows so large. If you install the openssh-client, it should work
Yes I did identify that as the problem if you see the description I mentioned. I pointed to a git commit that might have caused this. I am not sure what package installation has changed in the hyperkube container. "ssh" used to be available and now it is not. For the gitrepo feature to work it should be available.
Ah okay. If it was there before, we might want to add it back. SGTM.
Yeah, I switched the hyperkube image base from to our with some additional dependencies back. Apparently due to lack of volume + hyperkube test coverage, I've missed a number of dependencies needed.

cc
we could use dropbear as a replacement for just the ssh client?
I would prefer to use the openssh client over the dropbear client. It has wider usage and a stronger security track record IMO. The dropbear client also has somewhat different usage and configuration, so arguably using it is still a regression over the previous state. Saving a couple MB isn't worth using worse utilities, however much fun "dockerfile-golfing" is.
to fix
cherrypick to release-1.8:
This should be fixed in v1.8.3.
Change:
for _, initDriver := range csiTestDrivers { curDriver := initDriver(config) <ins> curConfig := curDriver.GetDriverInfo().Config </ins> Context(testsuites.GetDriverNameWithFeatureTags(curDriver), func() { <del> driver := curDriver </del> BeforeEach(func() { <ins> // Reset config. The driver might have modified its copy // in a previous test. curDriver.GetDriverInfo().Config = curConfig </ins> // setupDriver <del> driver.CreateDriver() </del> <ins> curDriver.CreateDriver() </ins> }) AfterEach(func() { // Cleanup driver <del> driver.CleanupDriver() </del> <ins> curDriver.CleanupDriver() </ins> }) <del> testsuites.RunTestSuite(f, driver, csiTestSuites, csiTunePattern) </del> <ins> testsuites.RunTestSuite(f, curDriver, csiTestSuites, csiTunePattern) </ins> }) }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce/gke multizone/regional jobs Which test(s) are failing: Only PD tests Since when has it been failing: Around 12/21 with the 16:49 run Testgrid link: https://k8s- Reason for failure: TBD Anything else we need to know: <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
The runs started flaking after merged. cc Here's one failing run: Pod pod-subpath-test-gcepd-dynamicpv-pfsm failed to schedule because of conflicting node selectors: We shouldn't need to set the node selector for PD tests using PVs.
The PR broke the subpath test because the modification to the config struct embedded in the driver info now persists across tests: A quick fix would be to reset that field in CreateDriver. The long-term fix is the change discussed in My preference is to do the quick fix now, then either merge or close PRs in this order: (needs a decision about logging of tests that aren't getting defined, see ) a future PR for What I'd like to avoid is having to rebase PR on top of the long-term solution for issue - that'll be lots of code conflicts.
/assign PR is here: PR
Change:
return &REST{store} } <ins> // Implement CategoriesProvider var _ rest.CategoriesProvider = &REST{} // Categories implements the CategoriesProvider interface. Returns a list of categories a resource is part of. func (c *REST) Categories() []string { return []string{"api-extensions"} } </ins> var swaggerMetadataDescriptions = metav1.ObjectMeta{}.SwaggerDoc() // ConvertToTable implements the TableConvertor interface for REST.

Discussion:
What would you like to be : Adding a "webhooks" group to kubectl to show mutating/validating webhooks would be super useful Why is this needed: There are a few reasons this is useful (to me): often cannot remember the right names for these resources, are very long and I often have a typo often want to enumerate all of them on the system. cc
/sig cli
I think this is a great idea, definitely something I could've used in the past. I'd be interested in taking a pass at implementing this if the proposal gets accepted.
Instead of building a category based on the types we have, I would build the category based on why people look at them. I suspect a category like which returned admission config admission config for various CSI types to list in CRD would be very helpful.
Webhook is far too generic. By putting admission webhooks in there we basically steal that word from the ecosystem to be used for other purposes. "admissionwebhooks" I could agree with.
Yeah, there are other webhooks, e.g. CRD conversion webhooks or authz webhooks...
I'd expect the short names "mwc" and "vwc" to be set up, are they not?
Unfortunately, they are not.
/triage accepted /assign
does category tolerate namespacing? i.e. would be tolerated? Still a bit long, but shorter than
It's a string, so you could theoretically namespace that.
Change:
ns := f.Namespace.Name By("Initializing PV source") <del> t.pvSource = t.createGCEVolume() </del> <ins> t.pvSource, _ = framework.CreateGCEVolume() </ins> pvConfig := framework.PersistentVolumeConfig{ NamePrefix: "pv-upgrade", PVSource:   *t.pvSource,

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --We should have an e2e to test issue . The test needs to delete a PVC while a pod is still using it, and then restart the controller manager. /kind bug /sig storage
CC
/assign unofficially so I can find this later.
Change:
active := int32(len(jobCtx.activePods)) newSucceededPods, newFailedPods := getNewFinishedPods(jobCtx) jobCtx.succeeded = job.Status.Succeeded + int32(len(newSucceededPods)) + int32(len(jobCtx.uncounted.succeeded)) <del> failed := job.Status.Failed + int32(len(newFailedPods)) + int32(len(jobCtx.uncounted.failed)) </del> <ins> failed := job.Status.Failed + int32(nonIgnoredFailedPodsCount(jobCtx, newFailedPods)) + int32(len(jobCtx.uncounted.failed)) </ins> var ready *int32 if feature.DefaultFeatureGate.Enabled(features.JobReadyPods) { ready = pointer.Int32(countReadyPods(jobCtx.activePods))

Discussion:
Pod backoff calculation excludes pods that match an rule in the failure policy: This could lead to fast retries, overwhelming the control plane, if most failures match an rule. The semantics of is not to count towards the limit, but the backoff should still be respected. /sig apps Recreations to be throttled. a Job with failure policy that matches every kind of failure. a container that always fails You would observe immediate recreation. No response_ 27+ <detailsN/A </details<details</details<details</details<details</details<details</details
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
cc
Change:
<ins> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package filters import ( "net/http" "net/http/httptest" "testing" ) func TestCacheControl(t *testing.T) { tests := []struct { name string path string startingHeader string expectedHeader string }{ { name:           "simple", path:           "/api/v1/namespaces", expectedHeader: "no-cache, private", }, { name:           "openapi", path:           "/openapi/v2", expectedHeader: "no-cache, private", }, { name:           "already-set", path:           "/api/v1/namespaces", startingHeader: "nonsense", expectedHeader: "nonsense", }, } for _, test := range tests { t.Run(test.name, func(t *testing.T) { handler := http.HandlerFunc(func(http.ResponseWriter, *http.Request) { //do nothing }) wrapped := WithCacheControl(handler) testRequest, err := http.NewRequest(http.MethodGet, test.path, nil) if err != nil { t.Fatal(err) } w := httptest.NewRecorder() if len(test.startingHeader) > 0 { w.Header().Set("Cache-Control", test.startingHeader) } wrapped.ServeHTTP(w, testRequest) actual := w.Header().Get("Cache-Control") if actual != test.expectedHeader { t.Fatal(actual) } }) } } </ins>

Discussion:
The kube-apiserver is protected, so it's responses should not be cached. The only known exception is for openapi data which is not sensitive, which is large, and which has etags. /assign
/sig api-machinery
Change:
// Represents a projected volume source type ProjectedVolumeSource struct { // list of volume projections <ins> // +optional </ins> Sources []VolumeProjection `json:"sources" protobuf:"bytes,1,rep,name=sources"` // Mode bits used to set permissions on created files by default. // Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511.

Discussion:
What happened: I created a Pod with a ProjectedVolume with an empty array of , but Kubernetes transformed that value to . Some clients are happy with either value (e.g. Go) while others are not (e.g. Python). For example, the following is accepted and stored by Kubernetes, but cannot be read by the Python client: The field has been transformed to : Even a JSON patch has no effect: What you expected to happen: I expected the required (OpenAPI) field of core/v1.ProjectedVolumeSource to be returned as the empty array I submitted. How to reproduce it (as minimally and precisely as possible): Create the above Pod: See that has been transformed to : See that the officially-supported Python client is unable to deserialize the Pod: Anything else we need to know?: I recognize there's a lot of layers involved in the steps above. The ineffectiveness of the JSON patch is what makes me think the culprit is somewhere in the field spec or API somehow. /sig api-machinery Environment: Kubernetes version (use ): [official-clients]:
/remove-sig api-machinery /sig storage the issue is in the API definition, which does not indicate the sources field is optional (even though it is)
/cc
Change:
cmd.Flags().StringP("output", "o", "", "Output format. One of: json|yaml|template|templatefile.") cmd.Flags().String("output-version", "", "Output the formatted object with the given version (default api-version).") cmd.Flags().Bool("no-headers", false, "When using the default output, don't print headers.") <del> cmd.Flags().StringP("template", "t", "", "Template string or path to template file to use when -o=template or -o=templatefile.") </del> <ins> cmd.Flags().StringP("template", "t", "", "Template string or path to template file to use when -o=template or -o=templatefile.  The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview]") </ins> } // OutputVersion returns the preferred output version for generic content (JSON, YAML, or templates)

Discussion:
periodic-conformance-main-k8s-main Kubernetes e2e suite.SynchronizedBeforeSuite 07/17 23:52PDT We saw a similar issue in , which was fixed by upgrading the control plane OS from Ubuntu 18.04 to 22.04. /sig cluster-lifecycle
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
/sig node It seems to be related to SWAP.
There is a bug in containerd that is fixed in v1.6.14. The test here is using v1.6.8. Kubernetes v1.27 supported containerd versions: 1.7.0+, 1.6.15+
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Still failing after is merged. Have we tried bumping the control plane OS image to ubuntu 22.04, like ?
Nevermind, the latest testgrid job might have been triggered before the PR was merged. I am observing this and will close this once I see the job passes.
Containerd version is already v1.6.21 in 's log There maybe still other problems.
can fix a similar failure in .
/close The failure of the swap is fixed by . The current failure is a flake that is mentioned in
Closing this issue. <detailsIn response to : /close The current failure is a flake that is mentioned in 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
Change:
newStatus.Phase = api.PodUnknown } else { newStatus.Info = result.Status.Info <del> newStatus.Phase = getPhase(&pod.Spec, newStatus.Info) if netContainerInfo, ok := newStatus.Info[leaky.PodInfraContainerName]; ok { if netContainerInfo.PodIP != "" { newStatus.PodIP = netContainerInfo.PodIP } </del> <ins> newStatus.PodIP = result.Status.PodIP if newStatus.Info == nil { // There is a small race window that kubelet couldn't // propulated the status yet. This should go away once // we removed boundPods newStatus.Phase = api.PodPending } else { newStatus.Phase = result.Status.Phase </ins> } } return newStatus, err

Discussion:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.
Change:
if err == nil { t.Fatalf("MyCRD doesn't support fieldValidation, yet no error found") } <ins> err = fieldValidationVerifier.HasSupport(schema.GroupVersionKind{Group: "", Version: "v1", Kind: "List"}) if err == nil { t.Fatalf("List does not support fieldValidation, yet no error found") } </ins> }

Discussion:
kubectl apply performs validation before the apply. Non-CRD resources (e.g. pods / deployments) don't need CRD schema for validation, but if we use resource, kubectl calls . In my Kubernetes cluster, administrator doesn't allow users to list CRDs, so user cannot apply non-CRD resources (e.g. pods / deployments) with resource. doesn't happen because we're going to apply two Deployments. should not happen because we're going to apply two Deployments. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted /assign
/priority backlog