jiebi/CodeConvo huggingface dataset:
Change:
for objRef, request := range requests { out := o.addPrefixIfNeeded(objRef, o.Out) if err := o.ConsumeRequestFn(request, out); err != nil { <del> return err </del> <ins> if !o.IgnoreLogErrors { return err } fmt.Fprintf(o.Out, "error: %vn", err) </ins> } }

Discussion:
What happened: Running on a pod with two containers, of which one has restarted but the other hasn't results in a undesired behavior. I get an inconsistent outcome, sometimes just a report of , other times I get the other containers logs followed by the error. What you expected to happen: I expect to get to see the full response of all containers, even though one container without any --previous logs throwed an error. How to reproduce it (as minimally and precisely as possible): The output can look like this... Anything else we need to know?: The flag by itself ("If watching / following pod logs, allow for any errors that occur to be non-fatal") doesn't influence this, but a workaround is to use to be able to see the full output. Kubernetes version (use ): Cloud provider or hardware configuration: GKE OS (e.g: ): Ubuntu 20.04 Kernel (e.g. ): 5.4.0-58-generic
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
/sig cli
do you have an example yaml file to create these containers?
yikes I feared I'd be asked this question :) Well, I provided a minimal example in the original post.
Thank you very much. I'll take a look.
Hmm... I can replicate this issue with the example you provided. Very explanatory instructions! I'll investigate tomorrow.
I used the example to reproduce this issue. Created pod through above. The state of pod is Running. I guess the reason is that none of the containers in pod have Terminated state.Only when one of containers is Terminated. The param --previous will return the result normally.
looking at these lines... ...I discovered that adding the option significantly increases the frequency that the "bash" container's logs are printed (the numbers are how many times was printed out of 100 runs):
Can i work on this issue?
/assign
Go ahead I'd love for you too. Hopefully my notes help!
Change:
// IPTablesMasqueradeBit must be specified or defaulted. return nil, fmt.Errorf("Unable to read IPTablesMasqueradeBit from config") } <del> proxierIPTables, err := iptables.NewProxier(iptInterface, utilsysctl.New(), execer, config.IPTablesSyncPeriod.Duration, config.IPTablesMinSyncPeriod.Duration, config.MasqueradeAll, int(*config.IPTablesMasqueradeBit), config.ClusterCIDR, hostname, getNodeIP(client, hostname)) </del> <ins> proxierIPTables, err := iptables.NewProxier( iptInterface, utilsysctl.New(), execer, config.IPTablesSyncPeriod.Duration, config.IPTablesMinSyncPeriod.Duration, config.MasqueradeAll, int(*config.IPTablesMasqueradeBit), config.ClusterCIDR, hostname, getNodeIP(client, hostname), recorder, ) </ins> if err != nil { glog.Fatalf("Unable to create proxier: %v", err) }

Discussion:
When kube-proxy fails to open a nodeport, it gives up setting up the rest of the iptables rules for the service. Leaving the service not usable. Cannot even use it with clusterIP. Kube-proxy only logs this error in . No useful information can be retrieved with kubectl. Need to record a event at least.
Ideally would the changes be removed and then reported back? Is there a preferred log or place to return the error?
the event maybe a better solution; as other port maybe success.
Need to surface the problem somewhere. An event seems okay
, there's and in ; should we reuse it or create new recorders for ?
Just reuse it. After all, it is within the same component. Are you going to submit a PR?
sure, my pleasure.
Great! Thanks! Let me know when the PR is ready.
Change:
if (pattern.VolMode == v1.PersistentVolumeBlock && t.runTestBlock != nil) || (pattern.VolMode == v1.PersistentVolumeFilesystem && t.runTestFile != nil) { ginkgo.It(t.testItStmt, func() { <del> if pattern.VolMode == v1.PersistentVolumeBlock && driver.GetDriverInfo().InTreePluginName == "kubernetes.io/local-volume" { // TODO: https://github.com/kubernetes/kubernetes/issues/74552 framework.Skipf("Local volume volume plugin does not support block volume reconstruction (#74552)") } </del> init() defer cleanup()

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (block volmode)] disruptive[Disruptive] Should test that pv used in a pod that is force deleted while the kubelet is down cleans up when the kubelet returns. Since when has it been failing: 10/8/19 Testgrid link: https://k8s- Reason for failure: Introduced by but root cause is probably Anything else we need to know:
/assign
/milestone 1.17 /priority important-soon this is consistently failing in release-master-informing job could you please take a look?
The provided milestone is not valid for this repository. Milestones in this repository: [, , , , , , , , ] Use to clear the milestone. <detailsIn response to : /milestone 1.17 /priority important-soon 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
/milestone v1.17
Change:
if err := o.Complete(tf, &cobra.Command{}); err != nil { t.Errorf("Unexpected error: %v", err) } <del> if err := o.Validate(); err != nil { </del> <ins> if err := o.Validate(nil); err != nil { </ins> t.Errorf("Unexpected error: %v", err) } <ins> if err := o.Validate([]string{"extraParameter0"}); !strings.Contains(err.Error(), "extra arguments") { t.Errorf("Unexpected error: should fail to validate the args length greater than 0") } </ins> if err := o.Run(); err != nil { t.Errorf("Cannot execute version command: %v", err) }

Discussion:
ran instead of and got no error and then though that was the right version kubectl should fail for unexpected extra arguments
/sig cli
/assign
/triage accepted
Change:
storageutils.VerifyExecInPodSucceed(f, pod2, "[ ! -f /mnt/test-0/hello-world ]") } <del> defer StopPod(f.ClientSet, pod2) </del> <ins> defer StopPodAndDependents(f.ClientSet, pod2) </ins> return nil }

Discussion:
<!-- 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: Since when has it been failing: Testgrid link: Reason for failure: I0722 06:26:18.056] I0722 06:26:18.057] [Driver: csi-hostpath] I0722 06:26:18.057] I0722 06:26:18.057] [Testpattern: Generic Ephemeral-volume (default fs) [Feature:GenericEphemeralVolume] (late-binding)] ephemeral skipped 448 lines unfoldmore I0722 06:30:33.845] Jul 22 06:30:33.845: INFO: Wait up to 5m0s for pod "inline-volume-tester2-hhcbd" to be fully deleted I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Pod inline-volume-tester-74jqh has the following logs: /dev/sda1 on /mnt/test-0 type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30) I0722 06:31:06.117] I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Deleting pod "inline-volume-tester-74jqh" in namespace "ephemeral-9141" I0722 06:31:06.155] Jul 22 06:31:06.155: INFO: Wait up to 5m0s for pod "inline-volume-tester-74jqh" to be fully deleted I0722 06:31:38.264] Jul 22 06:31:38.264: FAIL: no dangling PVCs I0722 06:31:38.264] Expected I0722 06:31:38.265] <[]v1.PersistentVolumeClaim | len:1, cap:1: [ I0722 06:31:38.265] { I0722 06:31:38.265] TypeMeta: {Kind: "", APIVersion: ""}, I0722 06:31:38.

265] ObjectMeta: { skipped 315 lines unfold_more I0722 06:32:16.896] STEP: Destroying namespace "ephemeral-9141" for this suite. I0722 06:32:16.931] Jul 22 06:32:16.931: INFO: Namespace ephemeral-9141 was already deleted I0722 06:32:16.932] STEP: Destroying namespace "ephemeral-522" for this suite. I0722 06:32:16.966] Jul 22 06:32:16.966: INFO: Namespace ephemeral-522 was already del Anything else we need to know: /cc /sig storage /priority critical-urgent /milestone v1.19
I have tracked this down and it looks like that changes were made in that affected how Pods were being deleted in the e2e framework (specifically commit ). This caused failures in other tests, so the commit was reverted in I will have a fix open shortly that uses foreground deletion only for these storage tests. /assign /cc Side note: I see already saw this
Change:
package v1alpha1 import ( <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" )

Discussion:
no explanation for metadata filed of NodeMetrics/PodMetrics, code: should be like $ kubectl explain NodeMetrics KIND: NodeMetrics VERSION: DESCRIPTION: NodeMetrics sets resource usage metrics of a node. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. usage <map[string]string-required- The memory usage is the memory working set. window <string-required- and $ kubectl explain PodMetrics KIND: PodMetrics VERSION: DESCRIPTION: PodMetrics sets resource usage metrics of a pod. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: containers <[]Object-required- Metrics for all containers are collected within the same time window. kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window <string-required- able to see the explanation for metadata filed of NodeMetrics/PodMetrics Kubernetes Version: v1.22.0-rc.0+
/sig instrumentation
/kind documentation /assign /triage accepted
Change:
* [kubectl config](kubectl_config.md)	 - config modifies kubeconfig files <del> ###### Auto generated by spf13/cobra on 8-Dec-2015 </del> <ins> ###### Auto generated by spf13/cobra on 8-Jan-2016 </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_config_view.md?pixel)]()

Discussion:
It acts like a boolean flag but requires an argument, unlike boolean flag is pretty much every environment. We need to find a better way to express the things that this is expressing. Maybe a add a tristate to the pflag lib that behaves the same way but doesn't demand an argument?
cc
The handles "true", "false", "unset" and has a default value. I seem to recall you were looking at changing it, but we needed to preserve the value. The complain here is that you have to do instead of just . /cc
fixing is really easy....
Change:
<ins> /* Copyright 2017 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 kubeadm // Role labels are applied to Nodes to mark their purpose.  In particular, we // usually want to distinguish the master, so that we can isolate privileged // pods and operations. // // Originally we relied on not registering the master, on the fact that the // master was Unschedulable, and on static manifests for master components. // But we now do register masters in many environments, are generally moving // away from static manifests (for better manageability), and working towards // deprecating the unschedulable field (replacing it with taints & tolerations // instead). // // Even with tainting, a label remains the easiest way of making a positive // selection, so that pods can schedule only to master nodes for example, and // thus installations will likely define a label for their master nodes. // // So that we can recognize master nodes in consequent places though (such as // kubectl get nodes), we encourage installations to use the well-known labels. // We define NodeLabelRole, which is the preferred form, but we will also recognize // other forms that are known to be in widespread use (NodeLabelKubeadmAlphaRole). const ( // NodeLabelKubeadmAlphaRole is a label that kubeadm applies to a Node as a hint that it has a particular purpose. // Use of NodeLabelRole is preferred. NodeLabelKubeadmAlphaRole = "kubeadm.alpha.kubernetes.io/role" ) </ins>

Discussion:
used to show masters, but as of it no longer does. This is not in accordance with our deprecation policy I believe. cc
That commit/PR is not relevant as there are no supported users/deployment methods that are using label. kubeadm v1.4 or v1.5 was the last. What you're really looking for is who/what removed printing things based on the label...
No blame on you The regression is that we have stopped printing masters in . There may be more to it that a simple revert of , but we should probably start there.
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
This has been fixed in recent versions
Change:
// (see `applyPlatformSpecificDockerConfig` and `performPlatformSpecificContainerCleanup` // methods for more info). containerCleanupInfos map[string]*containerCleanupInfo <ins> cleanupInfosLock      sync.RWMutex </ins> } // TODO: handle context.

Discussion:
What happened: Windows kubelet panic occasionally on nodes which have high volume of pods run and delete. Full logs: Preliminary investigate result: How to reproduce it (as minimally and precisely as possible): Run high volume of pods and delete them when they completed in Windows nodes. Environment: Kubernetes version (use ): 1.17.7 Cloud provider or hardware configuration: Azure AKS OS (e.g: ): Windows Server 2019 Kernel (e.g. ): 10.0..1282
/assign I would like to give this a shot.
/remove-sig windows I think this is not a windows specific problem. /sig node /area kubelet
Hi! Thanks for your report, I have filed to address this issue.
This issue is a bit urgent for our situation, it occurs every few days in production clusters. Seems the PR is pending a few days, is it possible to increase the priority to merge it trunk and 1.17/1.18 branch? Thanks
I understand how urgent this issue is, but I am not privileged to do anything further :(
Do you know anyone who can help?
looks like a simple fix, add a lock for , I could help.
There is already a fix by , the problem is the PR is pending, not sure if you or someone can increase the priority to merge it trunk and 1.17/1.18 branch asap. Our AKS clusters are affecting by this frequently.
Thanks guys.
Change:
// ServiceAnnotationLoadBalancerMixedProtocols is the annotation used on the service // to create both TCP and UDP protocols when creating load balancer rules. ServiceAnnotationLoadBalancerMixedProtocols = "service.beta.kubernetes.io/azure-load-balancer-mixed-protocols" <ins> // serviceTagKey is the service key applied for public IP tags. serviceTagKey = "service" // clusterNameKey is the cluster name key applied for public IP tags. clusterNameKey = "kubernetes-cluster-name" </ins> ) var (

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: We deployed two Kubernetes clusters to the same Azure Resource Group. Created services of load balancer type on both clusters. One of the services never received a public IP. Upon investigation, we noticed that the first Kubernetes cluster deleted the Azure Public IP that was created for the service by the other cluster. Apparently, all public IPs in the resource group are retrieved: then public IPs which don't match this criteria: are deleted. This logic besides the name of the kubernetes service should also consider the K8s cluster where the public IP originated from to avoid stepping on each other's toes when multiple clusters share the same resource group. What you expected to happen: In case multiple clusters run in the same resource group a cluster should delete only resources created by itself. How to reproduce it (as minimally and precisely as possible): Create two Kubernetes clusters (1.14) with different cluster names to the same resource group than create kubernetes services of load balancer type in each cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
thanks for reporting the issue, this is the bug we should fix for sharing resource group. /sig azure /kind bug /assign
Change:
TTY:       tty, }, api.Scheme) <del> return p.Attach.Attach("POST", req.URL(), p.Config, stdin, p.Out, p.Err, tty) </del> <ins> err = p.Attach.Attach("POST", req.URL(), p.Config, stdin, p.Out, p.Err, tty) if err != nil { return err } if p.Stdin && tty && pod.Spec.RestartPolicy == api.RestartPolicyAlways { fmt.Fprintf(p.Out, "Session ended, resume using 'kubectl attach %s -c %s -i -t' command when the pod is runningn", pod.Name, containerToAttach.Name) } return nil </ins> } // GetContainer returns the container to attach to, with a fallback.

Discussion:
After a times out, you can usually reattach with something like . But not all users realize that. It would be nice, when a or session ends, to print
Change:
${IP_ALIAS_SUBNETWORK} fi fi <del> if [[ ${SERVICE_CLUSTER_IP_SUBNETWORK} == ${INSTANCE_PREFIX}-subnet-services ]]; then echo "Removing auto-created subnet ${NETWORK}:${SERVICE_CLUSTER_IP_SUBNETWORK}" if [[ -n $(gcloud beta compute networks subnets describe  --project "${PROJECT}"  --region ${REGION}  ${SERVICE_CLUSTER_IP_SUBNETWORK} 2>/dev/null) ]]; then gcloud --quiet beta compute networks subnets delete  --project "${PROJECT}"  --region ${REGION}  ${SERVICE_CLUSTER_IP_SUBNETWORK} fi fi </del> } # Generates SSL certificates for etcd cluster. Uses cfssl program.

Discussion:
When using IP aliases on GCE, use a secondary range rather than subnetwork to reserve cluster IPs.
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
Change:
Pod:         st.MakePod().Name("test-prefilter").UID("test-prefilter").Obj(), NumAllNodes: 2, Diagnosis: framework.Diagnosis{ <del> NodeToStatusMap:      framework.NodeToStatusMap{}, </del> <ins> NodeToStatusMap: framework.NodeToStatusMap{ "1": framework.NewStatus(framework.UnschedulableAndUnresolvable, "injected unschedulable status").WithFailedPlugin("FakePreFilter"), "2": framework.NewStatus(framework.UnschedulableAndUnresolvable, "injected unschedulable status").WithFailedPlugin("FakePreFilter"), }, </ins> PreFilterMsg:         "injected unschedulable status", UnschedulablePlugins: sets.New("FakePreFilter"), },

Discussion:
When PreFilter returns UnschedulableAndUnresolvable, we don't need to run the preemption, but currently we run. This unexpected preemption could cause errors from the preemption by trying to read non-exist PreFilter data. As pointed out (), actually we didn't run the preemption in such cases in the past versions, but introduced this bug. /kind bug /kind regression /sig scheduling /triage accepted /priority important-soon
/assign
will fix this.
Change:
} // Mounter.SetUp() <del> if err := csiMounter.SetUp(nil); err != nil { </del> <ins> fsGroup := int64(2000) if err := csiMounter.SetUp(&fsGroup); err != nil { </ins> t.Fatalf("mounter.Setup failed: %v", err) } path := csiMounter.GetPath()

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When a volume for a CSI-based PV being mounted, the code does not apply the fsGroup value when the PV is marked as readOnly = false. What you expected to happen: if pv.readOnly == false, then the fsGroup ownership value should be applied to the mounted volume.
/assign /sig storage
Change:
}, []string{"resource"}, ) <ins> WatchCacheReadWait = compbasemetrics.NewHistogramVec( &compbasemetrics.HistogramOpts{ Namespace:      namespace, Subsystem:      subsystem, Name:           "read_wait_seconds", Help:           "Histogram of time spent waiting for a watch cache to become fresh.", StabilityLevel: compbasemetrics.ALPHA, Buckets:        []float64{0.005, 0.025, 0.05, 0.1, 0.2, 0.4, 0.6, 0.8, 1.0, 1.25, 1.5, 2, 3}, }, []string{"resource"}) </ins> ) var registerMetrics sync.Once

Discussion:
Part of From For now posted as a "help wanted" issue, however if we cannot hit the timeline for 1.30 code freeze () I would take it over so we don't miss. Still issue is simple enough that it can be quickly implemented. Implementation tips: Add a metric around waitUnitlFreshAndBlock method Metric should be a histogram with latency buckets similar to api latency Metric should have label for resource version. A way to monitor watch cache impact on request latency.
/sig api-machinery /triage accepted /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 : /sig api-machinery /triage accepted /help 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