jiebi/CodeConvo huggingface dataset:
Change:
ci-kubernetes-e2e-gce-scale-correctness [sig-node] Pods Extended Pod Container Status should never report success for a pending container 2021-02-19 https://k8s- ! Feb 19 12:22:34.933: 1 errors: pod pod-submit-status-0-11 on node gce-scale-cluster-minion-group-2-cczj container unexpected exit code 128: start=1970-01-01 00:00:00 +0000 UTC end=2021-02-19 12:21:43 +0000 UTC reason=StartError message=failed to create containerd task: OCI runtime create failed: starting container process caused " container init caused " mounting "/var/lib/kubelet/pods/-96dc-4682-af6a-" to rootfs "" at "" caused "stat /var/lib/kubelet/pods/-96dc-4682-af6a- no such file or directory""": unknown /sig scalability /sig node It failed 6/10 times in recent runs /priority critical-urgent /cc /cc
/triage accepted /cc
I do not see any recent changes in test setup, apart from test renames.
Test is already ignoring: Looks very similar, so probably regex should be extended. Original issues and PRs: /assign
could you triage?
We meet tomorrow, I'll make sure this is on our board/agenda.
Injected service account tokens changed from secret-based to projected-token based by default in , which merged 2/18 That coincides with this flake starting: as points out, the test already tolerated secret volume setup errors, I guess because those error messages are expected to occur spuriously in rapidly restarting containers? If it was acceptable for secret volume errors to be encountered in this test before, I agree the regex should be expanded to accomodate projected volume tokens. opened to do this. Separately, is sig storage or sig node looking at

Discussion:
ginkgo.It("should never report success for a pending container", func() { ginkgo.By("creating pods that should always exit 1 and terminating the pod after a random delay") <del> var reBug88766 = regexp.MustCompile(`rootfs_linux.*kubernetes.io~secret.*no such file or directory`) </del> <ins> var reBug88766 = regexp.MustCompile(`rootfs_linux.*kubernetes.io~(secret|projected).*no such file or directory`) </ins> var ( lock sync.Mutex
Change:
<!-- 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 --- 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 cli
/triage accepted

Discussion:
// MakeRegexpArray splits a comma separated list of regexps into an array of Regexp objects. func MakeRegexpArray(str string) ([]*regexp.Regexp, error) { <ins> if str == "" { return []*regexp.Regexp{}, nil } </ins> parts := strings.Split(str, ",") result := make([]*regexp.Regexp, len(parts)) for ix := range parts {

method:        "PUT", expectAccept:  false, }, <ins> { name:          "test23", acceptPaths:   DefaultPathAcceptRE, rejectPaths:   DefaultPathRejectRE, acceptHosts:   DefaultHostAcceptRE, rejectMethods: DefaultMethodRejectRE, path:          "/api/v1/namespaces/default/pods/somepod/exec", host:          "localhost", method:        "POST", expectAccept:  false, }, { name:          "test24", acceptPaths:   DefaultPathAcceptRE, rejectPaths:   "", acceptHosts:   DefaultHostAcceptRE, rejectMethods: DefaultMethodRejectRE, path:          "/api/v1/namespaces/default/pods/somepod/exec", host:          "localhost", method:        "POST", expectAccept:  true, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {
Change:
Setting a negative value in currently makes kubelet crash with a stack trace. The function raises an error when the value is negative, but the comment on  says that setting a negative value disables log rotation. At the moment there’s no way to disable log rotation and I believe removing lines 141 to 143 from , would allow this.
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 node (I guess)
/area kubelet can you show the stack trace?
The stack trace is 5000 lines long and apart from the following message, I don’t think it is relevant:
/assign
You can try to quote the value with double quotation when the value is negative, like the following: syncFrequency: 0s volumeStatsAggPeriod: 0s containerLogMaxSize: "-1"
I tried "-1", but still error
volumeStatsAggPeriod: -1s means disable
Which Kubernetes version have you installed? As if on my v1.19.4 system,no errors occured after I quoted the value with double quotation.
v1.20.2
I’m on v1.20.4. That’s already the case. Also, can only be set as a string in kubelet’s configuration, trying to set an integer will raise a parsing error (see ). The problem is not with the configuration, I’ve linked to the exact line in the code that checks for a negative value and raises the error.
Maybe you can try to disable this featureGate
Seems to work, I don’t know why I didn’t find this feature gate before.

Discussion:
if !ok { return 0, fmt.Errorf("invalid max log size") } <del> if maxSize < 0 { return 0, fmt.Errorf("negative max log size %d", maxSize) } </del> return maxSize, nil }

if err != nil { return nil, fmt.Errorf("failed to parse container log max size %q: %v", maxSize, err) } <ins> // Negative number means to disable container log rotation if parsedMaxSize < 0 { return NewStubContainerLogManager(), nil } </ins> // policy LogRotatePolicy return &containerLogManager{ osInterface:    osInterface,
Change:
<!-- 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 --Attempting to remove a status condition from an already empty slice panics. An empty slice should be removed (i.e. removed idempotently) and without panicking. Originally found with , reproduced with ( at the time of writing) Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): Pop!OS 20.04 LTS Kernel (e.g. ): Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig api-machinery
cc
/assign
/triage accepted

Discussion:
// RemoveStatusCondition removes the corresponding conditionType from conditions. // conditions must be non-nil. func RemoveStatusCondition(conditions *[]metav1.Condition, conditionType string) { <del> if conditions == nil { </del> <ins> if conditions == nil || len(*conditions) == 0 { </ins> return } newConditions := make([]metav1.Condition, 0, len(*conditions)-1)

{Type: "third"}, }, }, <ins> { name:          "empty_conditions", conditions:    []metav1.Condition{}, conditionType: "Foo", expected:      []metav1.Condition{}, }, </ins> } for _, test := range tests {
Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --pull-kubernetes-unit : (PR with no go code changes, should not have failed any unit tests) links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/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
/assigne
/assign
/assign tried to fix it in

Discussion:
}, } <ins> // deep copy before reconciler runs to avoid data race. pvWithSize := pv.DeepCopy() </ins> volumePluginMgr, fakePlugin := volumetesting.GetTestKubeletVolumePluginMgr(t) dsw := cache.NewDesiredStateOfWorld(volumePluginMgr) asw := cache.NewActualStateOfWorld(nodeName, volumePluginMgr)

// Start the reconciler to fill ASW. stopChan, stoppedChan := make(chan struct{}), make(chan struct{}) go func() { <ins> defer close(stoppedChan) </ins> reconciler.Run(stopChan) <del> close(stoppedChan) </del> }() waitForMount(t, fakePlugin, volumeName, asw) // Stop the reconciler.

<-stoppedChan // Simulate what DSOWP does <del> pv.Spec.Capacity[v1.ResourceStorage] = tc.newPVSize volumeSpec = &volume.Spec{PersistentVolume: pv} </del> <ins> pvWithSize.Spec.Capacity[v1.ResourceStorage] = tc.newPVSize volumeSpec = &volume.Spec{PersistentVolume: pvWithSize} </ins> dsw.AddPodToVolume(podName, pod, volumeSpec, volumeSpec.Name(), "" /* volumeGidValue */) // mark volume as resize required asw.MarkFSResizeRequired(volumeName, podName)

// 1. Add a volume to DSW and wait until it's mounted volumeSpec := &volume.Spec{Volume: &pod.Spec.Volumes[0]} <ins> // copy before reconciler runs to avoid data race. volumeSpecCopy := &volume.Spec{Volume: &pod.Spec.Volumes[0]} </ins> podName := util.GetUniquePodName(pod) generatedVolumeName, err := dsw.AddPodToVolume( podName, pod, volumeSpec, volumeSpec.Name(), "" /* volumeGidValue */)

// 3. While a volume is being unmounted, add it back to the desired state of world t.Logf("UnmountDevice called") generatedVolumeName, err = dsw.AddPodToVolume( <del> podName, pod, volumeSpec, volumeSpec.Name(), "" /* volumeGidValue */) </del> <ins> podName, pod, volumeSpecCopy, volumeSpec.Name(), "" /* volumeGidValue */) </ins> dsw.MarkVolumesReportedInUse([]v1.UniqueVolumeName{generatedVolumeName}) return nil }
Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --pull-kubernetes-unit Two new tests were just in that take significant amounts of time in CI: ~These tests also appear to be flaking regularly: /assign
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
Related: At some point we should probably adjust the timeout. I'd like to get CI to a point where it uses whatever the default is in make test.
yes.
This loops each type 50 times, I'll drop that down to say, 3 times. We honestly don't need to fuzz these that hard, they typically catch problems quick.
The failures I see in gubernator shouldn't happen now that the PR is merged. Before myPR to add this test was merged, other PRs that fields (NamespaceSelector) would cause myPR's unit tests to fail and I would need to rebase it and run . Now that it is merged, will be run by the PR author that adds a field to a type to keep code in sync.
ah, so these failures on other PRs mean they needed to regen?
Yeah, the first one adds and the fuzzer detected the apply config builder had not been regenerated by . The others have field changes too.
ok, so it's noise for PRs in progress but not flakes. looks like the runtime/timeout issue is the only flake, which you can drop iterations significantly to solve
50-3 seems like it should get us to 10-15s total for both new tests

Discussion:
} t.Run(gvk.String(), func(t *testing.T) { <del> for i := 0; i < 50; i++ { </del> <ins> for i := 0; i < 3; i++ { </ins> item := fuzzObject(t, gvk) builder := applyconfigurations.ForKind(gvk) unstructuredRoundTripApplyConfiguration(t, item, builder)

} t.Run(gvk.String(), func(t *testing.T) { <del> for i := 0; i < 50; i++ { </del> <ins> for i := 0; i < 3; i++ { </ins> item := fuzzObject(t, gvk) builder := applyconfigurations.ForKind(gvk) jsonRoundTripApplyConfiguration(t, item, builder)
Change:
<!-- 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 --- 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:
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 network
/sig windows

Discussion:
} for _, ingress := range service.Status.LoadBalancer.Ingress { <del> info.loadBalancerIngressIPs = append(info.loadBalancerIngressIPs, &loadBalancerIngressInfo{ip: ingress.IP}) </del> <ins> if net.ParseIP(ingress.IP) != nil { info.loadBalancerIngressIPs = append(info.loadBalancerIngressIPs, &loadBalancerIngressInfo{ip: ingress.IP}) } </ins> } return info }
Change:
will be used as a preparation for relaxing CSI Node id length limitation, in 1.22, we need to make sure the AllowLongNodeID is set correctly according to the comment /sig storage /assign /cc
/milestone 1.22
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone 1.22 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
Can you make a better title - I almost jumped out of my skin :)
Oops, sorry about that lol
/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]:

Discussion:
func (csiNodeStrategy) Validate(ctx context.Context, obj runtime.Object) field.ErrorList { csiNode := obj.(*storage.CSINode) <del> // in 1.22, on create, set AllowLongNodeID=false // in 1.23, on create, set AllowLongNodeID=true </del> validateOptions := validation.CSINodeValidationOptions{ <del> AllowLongNodeID: false, </del> <ins> AllowLongNodeID: true, </ins> } errs := validation.ValidateCSINode(csiNode, validateOptions)

func (csiNodeStrategy) ValidateUpdate(ctx context.Context, obj, old runtime.Object) field.ErrorList { newCSINodeObj := obj.(*storage.CSINode) oldCSINodeObj := old.(*storage.CSINode) <del> // in 1.22 on update, set AllowLongNodeID to true only if the old object already has a long node ID // in 1.23 on update, set AllowLongNodeID=true allowLongNodeID := false for _, nodeDriver := range oldCSINodeObj.Spec.Drivers { if validation.CSINodeLongerID(nodeDriver.NodeID) { allowLongNodeID = true } } </del> validateOptions := validation.CSINodeValidationOptions{ <del> AllowLongNodeID: allowLongNodeID, </del> <ins> AllowLongNodeID: true, </ins> } errorList := validation.ValidateCSINode(newCSINodeObj, validateOptions)
Change:
<!-- 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 --The memory manager fails to set the when used with the docker shim The memory manager should succeed to set the when used with the docker shim. Run memory manager e2e test on the environment with more than one NUMA node. Kubernetes version (use ): master 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:
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 node

Discussion:
CPUQuota:   rOpts.CpuQuota, CPUPeriod:  rOpts.CpuPeriod, CpusetCpus: rOpts.CpusetCpus, <ins> CpusetMems: rOpts.CpusetMems, </ins> } createConfig.HostConfig.OomScoreAdj = int(rOpts.OomScoreAdj) }
Change:
I ran conformance tests on a cluster that had a controller enabled that syncs a configmap across all clusters. It failed: Appears to be due to a 2 configmap limit: These clusters should pass conformance. This is a very common pattern (even Kubernetes itself does it!). I didn't run it myself, but apparently just install Istio and run the conformance suite. See for details Kubernetes version (use ): v1.20.2
/assign
my guess is the CA configmap created by default in 1.20 exacerbated this issue. I agree the conformance test should make fewer assumptions about the cluster it is running in and should accomodate default configmaps. left a comment on the PR in flight for this. I'd like to see the change picked to 1.20 as well.
/triage accepted /priority important-soon

Discussion:
ginkgo.By("Creating a ResourceQuota") quotaName := "test-quota" resourceQuota := newTestResourceQuota(quotaName) <ins> resourceQuota.Spec.Hard[v1.ResourceConfigMaps] = resource.MustParse(hardConfigMaps) </ins> _, err = createResourceQuota(f.ClientSet, f.Namespace.Name, resourceQuota) framework.ExpectNoError(err)

ginkgo.By("Ensuring resource quota status captures configMap creation") usedResources = v1.ResourceList{} usedResources[v1.ResourceQuotas] = resource.MustParse(strconv.Itoa(c + 1)) <del> // we expect there to be two configmaps because each namespace will receive // a ca.crt configmap by default. // ref:https://github.com/kubernetes/kubernetes/pull/68812 </del> usedResources[v1.ResourceConfigMaps] = resource.MustParse(hardConfigMaps) err = waitForResourceQuota(f.ClientSet, f.Namespace.Name, quotaName, usedResources) framework.ExpectNoError(err)

hard[v1.ResourceQuotas] = resource.MustParse("1") hard[v1.ResourceCPU] = resource.MustParse("1") hard[v1.ResourceMemory] = resource.MustParse("500Mi") <del> hard[v1.ResourceConfigMaps] = resource.MustParse("2") </del> <ins> hard[v1.ResourceConfigMaps] = resource.MustParse("10") </ins> hard[v1.ResourceSecrets] = resource.MustParse("10") hard[v1.ResourcePersistentVolumeClaims] = resource.MustParse("10") hard[v1.ResourceRequestsStorage] = resource.MustParse("10Gi")
Change:
In VMware Tanzu Supervisor Cluster k8s setup, we observed that the AdmissionWebhook tests fail intermittently while updating the namespace with the error: "the object has been modified; please apply your changes to the latest version and try again". This is because the update conflicts with an update being performed by another controller. The test could use Patch while adding labels via types.StrategicMergePatchType to prevent the conflict. /sig testing /sig api-machinery
(sig testing owns e.g. the frameworks but API Machinery own their test cases)
/triage accepted

Discussion:
import ( "context" <ins> "encoding/json" </ins> "fmt" "reflect" "strings"

client := f.ClientSet // Add a unique label to the namespace <del> ns, err := client.CoreV1().Namespaces().Get(context.TODO(), namespace, metav1.GetOptions{}) framework.ExpectNoError(err, "error getting namespace %s", namespace) if ns.Labels == nil { ns.Labels = map[string]string{} } ns.Labels[f.UniqueName] = "true" _, err = client.CoreV1().Namespaces().Update(context.TODO(), ns, metav1.UpdateOptions{}) </del> <ins> nsPatch, err := json.Marshal(map[string]interface{}{ "metadata": map[string]interface{}{ "labels": map[string]string{f.UniqueName: "true"}, }, }) framework.ExpectNoError(err, "error marshaling namespace %s", namespace) _, err = client.CoreV1().Namespaces().Patch(context.TODO(), namespace, types.StrategicMergePatchType, nsPatch, metav1.PatchOptions{}) </ins> framework.ExpectNoError(err, "error labeling namespace %s", namespace) }
Change:
Looks like we have 2 images: Here: Should these be moved to community owned repositories? Are there already there and we just need to fix up the locations?
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
for there are some PRs in progress to move the registry: and requested to copy the exiting image to the new community registry. for I will work on that next. :)
thanks !
discovered that the is available here: will open a PR to update to use this image
Where are the sources for these images? Will we be able to continue to publish new images? cc xref: None of these images seem to have version tags? If we're not actually publishing these, then we should probably either: consume them from somewhere that is publishing them and maintaining them set up mirroring them
copying from Also as much as I would like to see this sorted out I don't think or counts as a test-only issue to be resolving in this part of the release cycle. This seems like something we should do early in 1.22 and focus on actual test coverage improvements and functionality fixes right now.
/sig testing
/wg k8s-infra /milestone v1.22
Was CSI moved?
yes Ben ( was moved)
gcp-compute-persistent-disk-csi-driver is moved and nvidia-gpu-device-plugin have a good slack and the image was move in k/k with this PR I think we can close this issue. will close, if I did wrong we can reopen /close

Discussion:
hostPath: path: /dev containers: <del> - image: "gcr.io/gke-release/nvidia-gpu-device-plugin@sha256:a75ec0caa9e3038bd9886b3f36641a624574ff34b064974de6ee45048de3372b" </del> <ins> - image: "k8s.gcr.io/nvidia-gpu-device-plugin@sha256:4b036e8844920336fa48f36edeb7d4398f426d6a934ba022848deed2edbf09aa" </ins> command: ["/usr/bin/nvidia-gpu-device-plugin", "-logtostderr"] name: nvidia-gpu-device-plugin resources:
Change:
I ran and it panicked: no panic The panic was introduced by . I submitted as an attempt to fix this, but review led to the realization that there were further bugs and I don't know what the right fix is cc
/assign
/sig testing /sig cloud-provider
/triage accepted

Discussion:
var _ pflag.Value = &StringSlice{} func (s *StringSlice) String() string { <ins> if s == nil || s.value == nil { return "" } </ins> return strings.Join(*s.value, " ") } func (s *StringSlice) Set(val string) error { if s.value == nil || !s.changed { <del> *s.value = make([]string, 0) </del> <ins> v := make([]string, 0) s.value = &v </ins> } *s.value = append(*s.value, val) s.changed = true

} else if err != nil { t.Errorf("%d: expected nil error, got %v", i, err) } <del> if !reflect.DeepEqual(s, test.expected) { t.Errorf("%d: expected %+v, got %+v", i, test.expected, s) </del> <ins> if !reflect.DeepEqual(*v.value, test.expected) { t.Errorf("%d: expected %+v, got %+v", i, test.expected, *v.value) </ins> } if v.changed != test.changed { t.Errorf("%d: expected %t got %t", i, test.changed, v.changed)