jiebi/CodeConvo huggingface dataset:
Change:
${GKE_REQUIRED_SKIP_TESTS[@]:+${GKE_REQUIRED_SKIP_TESTS[@]}}  ${GCE_DEFAULT_SKIP_TESTS[@]:+${GCE_DEFAULT_SKIP_TESTS[@]}}  ${GCE_FLAKY_TESTS[@]:+${GCE_FLAKY_TESTS[@]}}  <ins> ${GCE_SLOW_TESTS[@]:+${GCE_SLOW_TESTS[@]}}  </ins> )"} ;;

Discussion:
For example: I'm disabling the test in But we need to re-enable it, or roll-back the test.
fyi
Shouldn't this is part slow test, and the fix should be either: 1) Increase Kubernetes-e2-gke-ci timeout value if decide to include slow to that project or 2) disable all slow tests on that project? cc/ Which one is required here?
The test runs 50 pods per node, which is over the default --max-pod limit of kubelet. The test relies on the flag --max-pods=100 being set in cluster/gce/config- I will disable it for all GKE tests in On the other hand, it's not clear to me where the timeout is set for a specific build. /cc
Timeouts for each Jenkins build are in the Jenkins project configurations themselves, which are not currently saved in version control anywhere. :
Discussed with about the test offline. There are several issues: Do we want to run any kind of kubelet resource monitoring test on GKE? Is it useful? We only override max-pods in GCE. Should the test itself figure out what platform it can run based on the #pods in the test (see ) Per-test configuration allows greater flexibility (e.g., we may run 100 pods on GCE to test kubelet's scalability), but it'd make the tests more complicated as they need to be aware of the test environment (which many e2e tests already do); there is also the burden of updating the tests once the max-pod value changes. Does this test belong to SLOW tests or should it belong to a new category? Not all slow tests have the same attributes. Arguably this test could be enabled only on selective builds. The downside would be more flags -- less readable/manageable e2e configs. Not all builds which run SLOW tests have the proper timeout value to run this test. We need to manually change them every time a slow test is . Re-assigning this back to since she has more concerns about the PR.
Had offline discussion with We are going to split current Kubelet resource usage tracking test into two, one is targeted for GCE, another one is for GKE. In this case, we won't mess up the test code itself by introducing knobs. Re-assign this back to
Change:
// NodeMetrics sets resource usage metrics of a node. message NodeMetrics { <ins> // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata // +optional </ins> optional k8s.io.apimachinery.pkg.apis.meta.v1.ObjectMeta metadata = 1; // The following fields define time interval from which metrics were

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:
return } } <del> Failf("Timed out after %d seconds waiting for %s pods to reach valid state", podStartTimeout.Seconds(), updateDemoSelector) </del> <ins> Failf("Timed out after %v seconds waiting for %s pods to reach valid state", podStartTimeout.Seconds(), updateDemoSelector) </ins> } type updateDemoData struct {

Discussion:
Implement guestbook test as a kubectl-driven test in . this should be a fairly straightforward follow up from , if you are interested/have cycles.
As I wrote in the email the plan is: problem w guestbook example (). test becomes actual test (). it do ginkgo. Should be done this week, but it depends on how fast 1. can be done.
Change:
Interval:       interval, Timeout:        timeout, CleanupPolicy:  updateCleanupPolicy, <del> MaxUnavailable: intstr.FromInt(0), </del> <ins> MaxUnavailable: intstr.FromInt(1), </ins> MaxSurge:       intstr.FromInt(1), } if rollback {

Discussion:
Which jobs are failing: gce-master-scale-correctness Which test(s) are failing: all - whole test set OOMed Since when has it been failing: 2020-07-28 Testgrid link: https://k8s- Reason for failure: test pod OOMed after setting 16Gi memory limit Anything else we need to know:
/sig scalability /assign
/lgtm /approve
Not this window :) it was supposed to be for kubernetes/test-infra
Looks fixed?
Yeah - last run didn't OOM, so I think we can close this one.
Another 2 runs OOMed: /reopen
Reopened this issue. <detailsIn response to : Another 2 runs OOMed: </details
That seems really ridiculous to me. The fact that our performance tests can work with 16GB makes it super strange that simple correctness tests require 32GB+...
^^
/reopen Leaving discussion open
Reopened this issue. <detailsIn response to : /reopen Leaving discussion open </details
64Gi is too much, we need to find a proper limit: /cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Testgrid is green

The default value of maxUnavailable seems to be 0 instead of 1. I tried rolling update for an RC with 3 replicas and it gave me: It should have said keep 2 pods available if maxUnavailable was 1. cc
It was falsely set as 0, I will submit a PR to help fix this.
Maybe we did this because before we introduced MaxUnavailable, rolling-update was written in a way that max unavailable was zero and we didnt want to change that behavior. might remember.
This changes fundamental behaviour in rolling-update. If I'm upgrading a single replica, rolling update now succeeds immediately, even though the new replica isn't ready. It even deletes the old RC before the new one is ready. With maxUnavailable set to 0, prior to this change, rolling-update would wait for the new replica to be ready before returning and deleting the old replica. I don't understand why this behaviour was a bug. Can you explain before I open an issue for this? (I expect this will hit a lot of people when 1.2 is released).
I think points out an interesting issue here: how should we handle the case where a RC with a single replica. Keep the default as 1(or 0) for all rolling-update, or set it as 0 when we are updating a RC with a single replica.
Yes I dont think that we want to change the behavior of kubectl rolling-update. I think it is better to revert to keeping the default for maxUnavailable as 0 for all kubectl rolling-update (as it was in 1.1) cc
maxSurge should be 1 and maxUnavailable should be 0 by default. We need to ensure that rollback works, however, in the case that the newRC is unavailable. cc
Change:
"//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/watch:go_default_library", <ins> "//staging/src/k8s.io/client-go/kubernetes/scheme:go_default_library", </ins> "//staging/src/k8s.io/client-go/kubernetes/typed/core/v1:go_default_library", "//staging/src/k8s.io/client-go/rest:go_default_library", <ins> "//staging/src/k8s.io/client-go/rest/fake:go_default_library", </ins> "//staging/src/k8s.io/client-go/testing:go_default_library", ], )

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: I tried to use  in a unit test, however I get a nil pointer panic when is invoked. What you expected to happen: would return a that doesn't panic on any method call. Ideally, it would allow me to interact with the client in someway for testing. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: client-go version: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing
I believe this also impacts returning logs via a reactor as does not implement
Seems to be a problem with . Since we're creating the request with all empty fields. Not sure what the best way it to resolve this. The best thing I came up with is to use to return a request with everything set up. But I'm a noob here so that's just a shot in the dark :man_shrugging:
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
/remove-lifecycle stale
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
The request returned has a nil which is used in the
I have filed a PR trying to fix this issue.
Change:
package azure import ( <ins> "bytes" </ins> "context" "encoding/json" "fmt"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kubelet fails to start on a standard VM with MSI enabled with . Provider config: Logs: What you expected to happen: kubelet starts finds a token via MSI and starts. How to reproduce it (as minimally and precisely as possible): Create Azure VM with MSI enabled. Start kubelet with and . Anything else we need to know?: It was working in 1.9. Environment: Kubernetes version (use ): v1.10.0-beta.1 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): Container Linux 1576.5.0 Kernel (e.g. ): 4.14.11-coreos Install tools: Custom () Others:
/sig azure
there should be one log in kubelet if according to following code, while your logs don't have such log, could you confirm you are using the provided in your kubelet?
you can look at the log output. There are lines:
Seems it's a bug within azure cloud provider. Let me check what's wrong.
Added to v1.10 milestone since it is a critical bug fix. cc
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
I saw your PR. Thanks! However I'm uncertain how this was working in 1.9?
The description is not clear. It is broken in 1.10 because of a refactor: Config.UseManagedIdentityExtension overrides auth.AzureAuthConfig.UseManagedIdentityExtension. There is no such problem on old releases.
Change:
ginkgo.It("test Deployment ReplicaSet orphaning and adoption regarding controllerRef", func() { testDeploymentsControllerRef(f) }) <ins> ginkgo.It("Deployment should have a working scale subresource", func() { testDeploymentSubresources(f) }) </ins> /* Release: v1.12 Testname: Deployment Proportional Scaling

Discussion:
[x] two weeks soak end date : 26 Feb 2021 According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. with this query you can filter untested endpoints by their category and eligibility for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a Deployment with a static label Read the Deployment Update the DeploymentScale Get the DeploymentScale to ensure it is updated Patch the DeploymentScale Read the DeploymentScale to ensure it is Patch Delete the Namespace and Deployment Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent ----------------------------------------|
patchAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource readAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource replaceAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource (3 rows) If a test with these calls gets merged, test coverage will go up by N points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Issue was presented in the Conformance meeting of 9 Feb 2021 and it was agreed that that method see to achieve the purpose and a PR can be created. A similar approach would be taken for the DepoymentScale endpoints, and this issue was created for that purpose.
/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
Change:
tests := []struct { args              []string p                 *execParams <ins> name              string </ins> expectError       bool expectedPod       string expectedContainer string <ins> expectedArgs      []string </ins> }{ { p:           &execParams{}, expectError: true, <ins> name:        "empty", </ins> }, { p:           &execParams{podName: "foo"}, expectError: true, <ins> name:        "no cmd", </ins> }, { p:           &execParams{podName: "foo", containerName: "bar"}, expectError: true, <ins> name:        "no cmd, w/ container", </ins> }, { <del> p:           &execParams{podName: "foo"}, args:        []string{"cmd"}, expectedPod: "foo", </del> <ins> p:            &execParams{podName: "foo"}, args:         []string{"cmd"}, expectedPod:  "foo", expectedArgs: []string{"cmd"}, name:         "pod in flags", </ins> }, { p:           &execParams{}, args:        []string{"foo"}, expectError: true, <ins> name:        "no cmd, w/o flags", </ins> }, { <del> p:           &execParams{}, args:        []string{"foo", "cmd"}, expectedPod: "foo", </del> <ins> p:            &execParams{}, args:         []string{"foo", "cmd"}, expectedPod:  "foo", expectedArgs: []string{"cmd"}, name:         "cmd, w/o flags", </ins> }, { p:                 &execParams{containerName: "bar"}, args:              []string{"foo", "cmd"}, expectedPod:       "foo", expectedContainer: "bar", <ins> expectedArgs:      []string{"cmd"}, name:              "cmd, container in flag", </ins> }, } for _, test := range tests { cmd := &cobra.Command{} <del> podName, containerName, err := extractPodAndContainer(cmd, test.args, test.p) </del> <ins> podName, containerName, args, err := extractPodAndContainer(cmd, test.args, test.p) </ins> if podName != test.expectedPod { <del> t.Errorf("expected: %s, got: %s", test.expectedPod, podName) </del> <ins> t.Errorf("expected: %s, got: %s (%s)", test.expectedPod, podName, test.name) </ins> } if containerName != test.expectedContainer { <del> t.Errorf("expected: %s, got: %s", test.expectedContainer, containerName) </del> <ins> t.Errorf("expected: %s, got: %s (%s)", test.expectedContainer, containerName, test.name) </ins> } if test.expectError && err == nil { <del> t.Error("unexpected non-error") </del> <ins> t.Errorf("unexpected non-error (%s)", test.name) </ins> } if !test.expectError && err != nil { <del> t.Errorf("unexpected error: %v", err) </del> <ins> t.Errorf("unexpected error: %v (%s)", err, test.name) } if !reflect.DeepEqual(test.expectedArgs, args) { t.Errorf("expected: %v, got %v (%s)", test.expectedArgs, args, test.name) </ins> } } }

Discussion:
When running , if you don't specify the deprecated and instead just do , it doesn't strip off the 1st command line arg, so sends the command to the container, whereas correctly sends just Regression from
FYI
We still support --, correct?
yes, we still support , but it's marked deprecated.
cc
has the fix. (and better unit test coverage) Sorry for the breakage!
Change:
// makeNsenterArgs makes a list of argument to nsenter in order to do the // requested mount. <del> func makeNsenterArgs(source, target, fstype string, options []string) []string { </del> <ins> func (n *NsenterMounter) makeNsenterArgs(source, target, fstype string, options []string) []string { </ins> nsenterArgs := []string{ "--mount=/rootfs/proc/1/ns/mnt", <del> "/usr/bin/mount", </del> <ins> "--", n.absHostPath("mount"), </ins> } args := makeMountArgs(source, target, fstype, options)

Discussion:
What happened: Windows documentation claims: V1.VolumeMount.mountPropagation - only MountPropagationHostToContainer is available. However, the internals suggest otherwise; is always returned on Windows: Either the docs should be corrected, or the Kubelet should be updated, or we should have a comment on why this does in fact enable MountPropagationHostToContainer on Windows. /cc /sig windows
/cc
/cc
I think the doc is not accurate. The doc claims the same thing. For MountPropagationHostToContainer option, we can test it whether it is working or not.
i created two PRs to address the documentation gap. we will also test this and get back to this thread.
For 1.15 we may need to update Kubelet code to allow HostToContainer.
Change:
if podAddErr != nil { t.Fatalf("AddPod failed. Expected: <no error> Actual: <%v>", podAddErr) } <del> waitForVolumeAttachedToNode(t, generatedVolumeName, nodeName2, asw) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName2, cache.AttachStateAttached, asw) </del> <ins> waitForVolumeAttachStateToNode(t, generatedVolumeName, nodeName2, cache.AttachStateAttached, asw) </ins> } func Test_Run_UpdateNodeStatusFailBeforeOneVolumeDetachNodeWithReadWriteOnce(t *testing.T) {

Discussion:
pull-kubernetes-unit reconciler TestRunOneVolumeDetachFailNodeWithReadWriteOnce unknown, maybe recently? No response /sig storage
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
The test is still flaking but it is almost rare. Please see the link below for the test history. The root cause is that the detach operation is not triggered or completed within 100ms. 1) not triggered: 2) triggered but not completed: It seems no better way to fix it unless we increase sleep time in the test. i.e. (100ms -200ms) I'm not sure if it is valuable to fix it. cc what do you think?
any flake should be fixed even if it's rare.
/assign
Change:
gvr("flowcontrol.apiserver.k8s.io", "v1alpha1", "flowschemas"): { Stub:             `{"metadata": {"name": "va1"}, "spec": {"priorityLevelConfiguration": {"name": "name1"}}}`, ExpectedEtcdPath: "/registry/flowschemas/va1", <del> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta2", "FlowSchema"), </del> <ins> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta3", "FlowSchema"), </ins> }, // --

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/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]: