jiebi/CodeConvo huggingface dataset:
Change:
NPD e2e Tests wouldn't start 12/08 suggested it may be related to /cc No response No response /sig node /priority important-soon
do you think you can take a look?
checked the logs for the latest failure, failing with the below message while starting kubernetes systemd probe
/triage accepted /assign can you please follow up with on this?
Compared the changelog, there are no changes in the kubernetes/node-problem-detector on the failure date.
I suspect this issue might be from the k8s-staging image. let me know if there is any one that could take a look at this issue related to the image used in infra.
The following are my theories there must be some change in the ssh secret keys that is resulting in the unexpected commit digest Image has some changes related to manifest pulling in docker and containerd. k8s-staging image - issue.
/reopen still failing
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
the test is green now. There was the recent PR from that fixed it

Discussion:
flags.StringVar(&TestContext.ReportDir, "report-dir", "", "Path to the directory where the JUnit XML reports should be saved. Default is empty, which doesn't generate these reports.") flags.Var(cliflag.NewMapStringBool(&TestContext.FeatureGates), "feature-gates", "A set of key=value pairs that describe feature gates for alpha/experimental features.") flags.StringVar(&TestContext.ContainerRuntime, "container-runtime", "remote", "The container runtime of cluster VM instances (remote).") <del> flags.StringVar(&TestContext.ContainerRuntimeEndpoint, "container-runtime-endpoint", "unix:///var/run/dockershim.sock", "The container runtime endpoint of cluster VM instances.") </del> <ins> flags.StringVar(&TestContext.ContainerRuntimeEndpoint, "container-runtime-endpoint", "unix:///var/run/containerd/containerd.sock", "The container runtime endpoint of cluster VM instances.") </ins> flags.StringVar(&TestContext.ContainerRuntimeProcessName, "container-runtime-process-name", "dockerd", "The name of the container runtime process.") flags.StringVar(&TestContext.ContainerRuntimePidFile, "container-runtime-pid-file", "/var/run/docker.pid", "The pid file of the container runtime.") flags.StringVar(&TestContext.SystemdServices, "systemd-services", "docker", "The comma separated list of systemd services the framework will dump logs for.")
Change:
The only support at least one letterbut the error message is at least one letter or number. It will be error if portname only numbers, ex: '1-2' or '1' or '123'. Fix the error message or regex syntax No response at least 1.19+ None <details</details<details</details<details</details<details</details
/sig api-machinery
I would like to take up this issue. /assign
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten

Discussion:
errs = append(errs, "must contain only alpha-numeric characters (a-z, 0-9), and hyphens (-)") } if !portNameOneLetterRegexp.MatchString(port) { <del> errs = append(errs, "must contain at least one letter or number (a-z, 0-9)") </del> <ins> errs = append(errs, "must contain at least one letter (a-z)") </ins> } if strings.Contains(port, "--") { errs = append(errs, "must not contain consecutive hyphens")
Change:
We are using Azure AKS V1.20.7 and the service type in production environment is ClusterIP. In Kube-proxy logs, continuously I see the below printed line. "Not saving endpoints for unknown healthcheck" ] Not saving endpoints for unknown healthcheck It may increase Syncing time I believe. Kindly assist. It should not print below line in kube-proxy logs. "Not saving endpoints for unknown healthcheck" ] Not saving endpoints for unknown healthcheck Service is of type - ClusterIP Validate kube-proxy logs in kube-system No response Azure AKS 1.20.7 Azure AKS <details</details<details</details<details</details<details</details
/sig network
/assign
/cc
I think that this is a duplicate of It also has a PR to fix it
/triage accepted I think we should remove that log line, is not meaningful
Just confirming, should I make a PR removing log line.
Thank you It won’t print that line in next k8s version ? Like 1.21.7? Any specific version?
I have doubts that this qualifies for backporting, because it is only happening if the log level verbosity is 3 or higher, a verbosity level of 2 use to be the default IIRC. Also, It's not impacting any functionality. Not backporting this change means that this only be present in current version 1.24, for previous versions people can configure the kube-proxy loglevel verbosity to 2 or lower, and it will not log this messge. is there any way users can define the kube-proxy verbosity level to 2? any inconvenient for doing that?
For AKS (managed cluster), I just checked and the default log verbosity configured is 3 to enable debug logging. For self-managed Kubernetes cluster, I think users have control over the log verbosity but for managed by default verbose logging is enabled? Have we backported any similar logging changes before?
WDYT about backporting this patch? ^^^
looks like is a log part, sgtm to backport
would you like to take care of the backports?
Do you want to open the PRs for backport? If not, lmk and I can open them.
Open PRs for backport:

Discussion:
for nsn, count := range newEndpoints { if hcs.services[nsn] == nil { <del> klog.V(3).InfoS("Not saving endpoints for unknown healthcheck", "service", nsn) </del> continue } klog.V(3).InfoS("Reporting endpoints for healthcheck", "endpointCount", count, "service", nsn)
Change:
The fake dynamic client does not support mock pagination or the self link. Add ability to propagate the metadata fields from a mock unstructured list to the served list by the fake lister. Repro linked in the MR x-ref. No response <details</detailsN/A N/A <detailsN/A </details<detailsN/A </details<detailsN/A </details
/sig api-machinery
/cc /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

Discussion:
} list := &unstructured.UnstructuredList{} <ins> list.SetRemainingItemCount(entireList.GetRemainingItemCount()) </ins> list.SetResourceVersion(entireList.GetResourceVersion()) <ins> list.SetContinue(entireList.GetContinue()) </ins> list.GetObjectKind().SetGroupVersionKind(listGVK) for i := range entireList.Items { item := &entireList.Items[i]

"apiVersion": "group/version", "kind":       "TheKindList", "metadata": map[string]interface{}{ <ins> "continue":        "", </ins> "resourceVersion": "", }, },

expectedList := &unstructured.UnstructuredList{} expectedList.SetGroupVersionKind(listGVK) expectedList.SetResourceVersion("") // by product of the fake setting resource version <ins> expectedList.SetContinue("") </ins> if diff := cmp.Diff(expectedList, list); diff != "" { t.Fatal("unexpected diff (-want, +got): ", diff)

expectedList := &unstructured.UnstructuredList{} expectedList.SetGroupVersionKind(listGVK) expectedList.SetResourceVersion("") // by product of the fake setting resource version <ins> expectedList.SetContinue("") </ins> expectedList.Items = append(expectedList.Items, u) if diff := cmp.Diff(expectedList, list); diff != "" {

expectedList := &unstructured.UnstructuredList{} expectedList.SetGroupVersionKind(listGVK) expectedList.SetResourceVersion("") // by product of the fake setting resource version <ins> expectedList.SetContinue("") </ins> expectedList.Items = []unstructured.Unstructured{u} if diff := cmp.Diff(expectedList, list); diff != "" {
Change:
We recently started using the list pager from client-go as part of Calico, and have seen reports of the following error showing up: No error, just beautiful paged list calls. Create 1,000 resources of a particular type, such as a NetworkPolicy. (Need 500 to trigger paging) Do a of all those resources with set. Originally filed here (but maybe that repo is not monitored): Reference issue in Calico: projectcalico/calico (comment) Reference Calico list pager code: We think this is the required fix: <detailsclient-go version (but bug seems to be in master too). </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted

Discussion:
options.Limit = p.PageSize } requestedResourceVersion := options.ResourceVersion <ins> requestedResourceVersionMatch := options.ResourceVersionMatch </ins> var list *metainternalversion.List paginatedResult := false

options.Limit = 0 options.Continue = "" options.ResourceVersion = requestedResourceVersion <ins> options.ResourceVersionMatch = requestedResourceVersionMatch </ins> result, err := p.PageFn(ctx, options) return result, paginatedResult, err }

// set the next loop up options.Continue = m.GetContinue() <del> // Clear the ResourceVersion on the subsequent List calls to avoid the </del> <ins> // Clear the ResourceVersion(Match) on the subsequent List calls to avoid the </ins> // `specifying resource version is not allowed when using continue` error. // See https://github.com/kubernetes/kubernetes/issues/85221#issuecomment-553748143. options.ResourceVersion = "" <ins> options.ResourceVersionMatch = "" </ins> // At this point, result is already paginated. paginatedResult = true }

p.t.Errorf("invariant violated, specifying resource version (%s) is not allowed when using continue (%s).", options.ResourceVersion, options.Continue) return nil, fmt.Errorf("invariant violated") } <ins> if options.Continue != "" && options.ResourceVersionMatch != "" { p.t.Errorf("invariant violated, specifying resource version match type (%s) is not allowed when using continue (%s).", options.ResourceVersionMatch, options.Continue) return nil, fmt.Errorf("invariant violated") } </ins> var list metainternalversion.List total := options.Limit if total == 0 {

want:      list(11, "rv:20"), wantPaged: true, }, <ins> { name:      "two pages with resourceVersion and resourceVersionMatch", fields:    fields{PageSize: 10, PageFn: (&testPager{t: t, expectPage: 10, remaining: 11, rv: "rv:20"}).PagedList}, args:      args{options: metav1.ListOptions{ResourceVersion: "rv:10", ResourceVersionMatch: metav1.ResourceVersionMatchNotOlderThan}}, want:      list(11, "rv:20"), wantPaged: true, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {
Change:
Also appears to be failing on: Failures as of 01/05. /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon Guessing since all tests with apparmor started failing - maybe app armor config was removed or some PR submitted recently.
/assign
ci-cri-containerd-node-e2e-features Last green run: First failed run:
This () is the only PR merged in kubernetes during the time between: Test started yesterday at 8:11 PM passed after 13m50s. (more info) Test started yesterday at 9:11 PM failed after 16m6s. (more info) And it happens to be related to AppArmor:
Working on a fix in

Discussion:
"k8s.io/client-go/tools/cache" watchtools "k8s.io/client-go/tools/watch" "k8s.io/klog/v2" <ins> "k8s.io/kubernetes/pkg/kubelet/kuberuntime" </ins> "k8s.io/kubernetes/test/e2e/framework" e2epod "k8s.io/kubernetes/test/e2e/framework/pod"

ginkgo.It("should reject an unloaded profile", func() { status := runAppArmorTest(f, false, v1.AppArmorBetaProfileNamePrefix+"non-existent-profile") <del> expectSoftRejection(status) </del> <ins> gomega.Expect(status.ContainerStatuses[0].State.Waiting.Message).To(gomega.ContainSubstring("apparmor")) </ins> }) ginkgo.It("should enforce a profile blocking writes", func() { status := runAppArmorTest(f, true, v1.AppArmorBetaProfileNamePrefix+apparmorProfilePrefix+"deny-write")

if t.Status.Reason == "AppArmor" { return true, nil } <ins> // Loading a profile not available on disk should return a container creation error if len(t.Status.ContainerStatuses) > 0 && t.Status.ContainerStatuses[0].State.Waiting.Reason == kuberuntime.ErrCreateContainer.Error() { return true, nil } </ins> } return false, nil })
Change:
Failing on cri-o serial job. Looks like the dbus command isn't available for graceful shutdown tests that aren't running on Ubuntu. /assign /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
/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
hmm, is this still issue? The testgrid job is still failing even after the fix appears to be merged? !
Please take a look when you get a chance, the error still seems to be that dbus-send is unavailable... /cc
oops... I forgot to add this to the other

Discussion:
"context" "fmt" "os" <ins> "os/exec" </ins> "path/filepath" "strconv" "time"

"k8s.io/kubernetes/pkg/features" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" kubelettypes "k8s.io/kubernetes/pkg/kubelet/types" <ins> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" </ins> testutils "k8s.io/kubernetes/test/utils" )

}) ginkgo.BeforeEach(func() { <ins> if err := lookEmitSignalCommand(); err != nil { e2eskipper.Skipf("skipping test because: %v", err) return } </ins> ginkgo.By("Wait for the node to be ready") waitForNodeReady() })

return err } <ins> func lookEmitSignalCommand() error { _, err := exec.LookPath("dbus-send") return err } </ins> func getNodeReadyStatus(f *framework.Framework) bool { nodeList, err := f.ClientSet.CoreV1().Nodes().List(context.TODO(), metav1.ListOptions{}) framework.ExpectNoError(err)
Change:
Failing on cri-o serial job. Looks like the dbus command isn't available for graceful shutdown tests that aren't running on Ubuntu. /assign /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
/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
hmm, is this still issue? The testgrid job is still failing even after the fix appears to be merged? !
Please take a look when you get a chance, the error still seems to be that dbus-send is unavailable... /cc
oops... I forgot to add this to the other

Discussion:
}) ginkgo.BeforeEach(func() { <ins> if err := lookEmitSignalCommand(); err != nil { e2eskipper.Skipf("skipping test because: %v", err) return } </ins> ginkgo.By("Wait for the node to be ready") waitForNodeReady()
Change:
The ctx object () is context.Background(). Thus, its Done() method returns a nil channel. Later, the nil channel is used to call and as their argument. The goroutines created in the two functions are leaked. No goroutine leaks in TestSelectorSpreadScore(). Run TestSelectorSpreadScore() No response all versions after <details</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
/sig scheduling (It sounds like leas in unit tests, which may be negligible. Does it cause some test failures?)
the test can pass.
/assign
/unassign /assign

Discussion:
client := fake.NewSimpleClientset( &v1.Service{Spec: v1.ServiceSpec{Selector: map[string]string{"foo": ""}}}, ) <del> ctx := context.Background() </del> <ins> ctx, cancel := context.WithCancel(context.Background()) defer cancel() </ins> informerFactory := informers.NewSharedInformerFactory(client, 0) _ = informerFactory.Core().V1().Services().Lister() informerFactory.Start(ctx.Done())

t.Run(test.name, func(t *testing.T) { nodes := makeNodeList(test.nodes) snapshot := cache.NewSnapshot(test.pods, nodes) <del> ctx := context.Background() </del> <ins> ctx, cancel := context.WithCancel(context.Background()) defer cancel() </ins> informerFactory, err := populateAndStartInformers(ctx, test.rcs, test.rss, test.services, test.sss) if err != nil { t.Errorf("error creating informerFactory: %+v", err)

t.Run(test.name, func(t *testing.T) { nodes := makeLabeledNodeList(labeledNodes) snapshot := cache.NewSnapshot(test.pods, nodes) <del> ctx := context.Background() </del> <ins> ctx, cancel := context.WithCancel(context.Background()) defer cancel() </ins> informerFactory, err := populateAndStartInformers(ctx, test.rcs, test.rss, test.services, test.sss) if err != nil { t.Errorf("error creating informerFactory: %+v", err)
Change:
The fix from seems to be incomplete/wrong. When disk is not found, the GET call for the disk fails with and it is not even reaching the DELETE call. PV to be deleted (its finalizer to be removed) when the underlying disk is already gone. a PVC. the created Azure disk and delete it manually. , delete the PVC. sure that corresponding PV fails to be deleted with reason: No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig cloud-provider /sig storage /area provider/azure /cc
this issue was fixed in CSI driver: what k8s version are you using now?
19.15 PS: This detail is provided in the issue itself. :)
should fix this issue, once it's merged into master branch, I will cherry pick to 1.23, 1.22, 1.21, and for the other versions, I think you need to patch with this PR by yourself, thanks.
/triage accepted /assign

Discussion:
disk, rerr := c.common.cloud.DisksClient.Get(ctx, resourceGroup, diskName) if rerr != nil { <ins> if rerr.HTTPStatusCode == http.StatusNotFound { klog.V(2).Infof("azureDisk - disk(%s) is already deleted", diskURI) return nil } </ins> return rerr.Error() }
Change:
I used to use 1.171 standalone Kubelet mode without an API server for my cluster. Because I’m not using API server, I can only get container events from Kubelet logs. But after I upgrade Kubelet to 1.20.1, I found that the log format is changed and Kubelet log is no longer logging container info(“FieldPath” field in logs) for events logs due to this change So with a newer version Kubelet, I cannot know which container those events belong to from Kubelet logs. container info(“FieldPath” field) should be back to Kubelet event logs Can reproduce it with any standalone Kubelet version after 1.18.20. I also want to what’s the best practice to get events for standalone Kubelet? Should “FieldPath” field add back to log? or is there any plan to add something like an “event server”, so users can configure and use it to get events for standalone Kubelet easier? 20.1 N/A <details</details<details</details<details</details<details</details
/sig node
seems to only change the log style. In this example, the pod name is still included in the log. /cc /sig instrumentation
/wg structured-logging
Pod name is still there, but the "FieldPath" field which includes container name is missing Old version log:
To add back FieldPath, change to An example of an event for pod: The log included name/namespace/kind/apiVersion/
/triage accepted
would you confirm this is expected or a regression?
/assign
Gentle ping on this, this is a blocking issue, without a fix, we need to stay with v1.18. Do we have a plan to fix this? or maybe I can help to fix it. Thanks
Removing fields like "fieldPath" was not intended. It should be ok to reintroduce this field to logs like showed in This is however not a bug as we don't provide any guarantee about log contents. Feel free to send a PR that will add this field back. /kind feature
/remove-kind bug

Discussion:
func (e *eventBroadcasterImpl) StartStructuredLogging(verbosity klog.Level) watch.Interface { return e.StartEventWatcher( func(e *v1.Event) { <del> klog.V(verbosity).InfoS("Event occurred", "object", klog.KRef(e.InvolvedObject.Namespace, e.InvolvedObject.Name), "kind", e.InvolvedObject.Kind, "apiVersion", e.InvolvedObject.APIVersion, "type", e.Type, "reason", e.Reason, "message", e.Message) </del> <ins> klog.V(verbosity).InfoS("Event occurred", "object", klog.KRef(e.InvolvedObject.Namespace, e.InvolvedObject.Name), "fieldPath", e.InvolvedObject.FieldPath, "kind", e.InvolvedObject.Kind, "apiVersion", e.InvolvedObject.APIVersion, "type", e.Type, "reason", e.Reason, "message", e.Message) </ins> }) }