jiebi/CodeConvo huggingface dataset:
Change:
maxStartAge = time.Hour * 24 * 365 // 1 year maxStatsAge = time.Minute ) <del> fsCapacityBounds := bounded(100*framework.Mb, 100*framework.Gb) </del> <ins> // fetch node so we can know proper node memory bounds for unconstrained cgroups node := getLocalNode(f) memoryCapacity := node.Status.Capacity["memory"] memoryLimit := memoryCapacity.Value() fsCapacityBounds := bounded(100*framework.Mb, 10*framework.Tb) </ins> // Expectations for system containers. sysContExpectations := func() types.GomegaMatcher { return gstruct.MatchAllFields(gstruct.Fields{

Discussion:
/kind bug What happened: e2e node summary test fails on machines with more than 10Gb of ram. What you expected to happen: memory limit bounds to look at node capacity rather than hardcode an upper bound. How to reproduce it (as minimally and precisely as possible): have more ram on a box and run e2e-node FOCUS=Summary Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig node
Change:
return printer, nil } <del> // ClientMapperForCommand returns a ClientMapper for the given command and factory. func (f *Factory) ClientMapperForCommand(cmd *cobra.Command) resource.ClientMapper { </del> <ins> // ClientMapperForCommand returns a ClientMapper for the factory. func (f *Factory) ClientMapperForCommand() resource.ClientMapper { </ins> return resource.ClientMapperFunc(func(mapping *meta.RESTMapping) (resource.RESTClient, error) { return f.RESTClient(mapping) })

Discussion:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR
Change:
// kubelet on Fedora CoreOS distribution func setKubeletSELinuxLabels(host, workspace string) error { cmd := getSSHCommand(" && ", <del> fmt.Sprintf("/usr/bin/chcon -u system_u -r object_r -t bin_t %s", filepath.Join(workspace, "kubelet")), </del> <ins> fmt.Sprintf("/usr/bin/chcon -u system_u -r object_r -t kubelet_exec_t %s", filepath.Join(workspace, "kubelet")), </ins> fmt.Sprintf("/usr/bin/chcon -u system_u -r object_r -t bin_t %s", filepath.Join(workspace, "e2e_node.test")), fmt.Sprintf("/usr/bin/chcon -u system_u -r object_r -t bin_t %s", filepath.Join(workspace, "ginkgo")), fmt.Sprintf("/usr/bin/chcon -u system_u -r object_r -t bin_t %s", filepath.Join(workspace, "mounter")),

Discussion:
Yesterday Not yet available. Jobs fail to start due to kubelet startup issues. /sig
/sig testing node
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
We identified as a potential fix. These labels are what we actually want. But the tests actually started to pass before this merge. It still isn't clear to us what happenend to make these tests fail. and I were able to reproduce the test failures on FCOS but it seems to have resolved itself. Writing this here for record but it was an odd one thats for sure!
Change:
// ScaleNamespaceListerExpansion allows custom methods to be added to // ScaleNamespaceLister. type ScaleNamespaceListerExpansion interface{} <del> // StatefulSetListerExpansion allows custom methods to be added to // StatefulSetLister. type StatefulSetListerExpansion interface{} // StatefulSetNamespaceListerExpansion allows custom methods to be added to // StatefulSetNamespaceLister. type StatefulSetNamespaceListerExpansion interface{} </del>

Discussion:
As a prerequisite of moving the , , , and controllers to use the apps/v1beta2 APIs, we need to add list expansions for , , , and to .
/assign
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
/sig apps
Change:
request, retry.DoExponentialBackoffRetry(&sendBackoff), ) <ins> if response == nil && err == nil { return response, retry.NewError(false, fmt.Errorf("Empty response and no HTTP code")) } </ins> return response, retry.GetError(response, err) }

Discussion:
What happened: We're seeing legacy-cloud-providers/azure/clients (in our case, the synchronised copy used by latest cluster-autoscaler (1.19)) segfaulting under heavy pressure and ARM throttling: In that specific case the cluster-autoscaler triggered the issue, but it can likely affect other ARM clients using that code, including in-tree kubelet or controller-manager. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.8 Cloud provider or hardware configuration: Azure OS (e.g: ): Ubuntu 20.04.1 LTS Kernel (e.g. ): 5.4.0-1022-azure -Ubuntu SMP Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure
/milestone v1.20
Change:
registry = "k8s.gcr.io/build-image", repository = "debian-iptables", # Ensure the digests above are updated to match a new tag <del> tag = "buster-v1.3.0",  # ignored, but kept here for documentation </del> <ins> tag = "buster-v1.4.0",  # ignored, but kept here for documentation </ins> ) def etcd_tarballs():

Discussion:
What happened: The latest release of the debian-base image, v2.1.3, contains a vulnerable version of the apt package. CVE-2020- impacts apt version 1.8.2.1. What you expected to happen: Image should be updated to use at least apt 1.8.2.2 to clear the vulnerability. How to reproduce it (as minimally and precisely as possible):
/sig release
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
kube-proxy is using debain as base image. /assign Let me check other components
checked the base image in and I seems that no new debian or ubuntu official image is built for this CVE ?
That is correct, the purpose of this issue is to get a new image built and released, one which contains a resolution for the CVE.
per comments of @ tianon in Will update it once debain releases it.
Change:
ginkgo.It(t.name, func(ctx context.Context) { m.init(ctx, testParameters{ registerDriver: test.deployClusterRegistrar, <del> podInfo:        test.podInfoOnMount}) </del> <ins> podInfo:        &test.podInfoOnMount}) </ins> ginkgo.DeferCleanup(m.cleanup) <del> waitUntilPodInfoInLog(ctx, m, test.expectPodInfo, test.expectEphemeral, 1) </del> <ins> waitUntilPodInfoInLog(ctx, m, test.expectPodInfo, test.expectEphemeral) </ins> }) } }) ginkgo.Context("CSI PodInfoOnMount Update", func() { <del> var ( podInfoTrue  = true podInfoFalse = false ) </del> tests := []struct { name              string <del> oldPodInfoOnMount *bool newPodInfoOnMount *bool </del> <ins> oldPodInfoOnMount bool newPodInfoOnMount bool </ins> }{ { name:              "should not be passed when update from true to false", <del> oldPodInfoOnMount: &podInfoTrue, newPodInfoOnMount: &podInfoFalse, }, { name:              "should not be passed when update from true to nil", oldPodInfoOnMount: &podInfoTrue, newPodInfoOnMount: nil, </del> <ins> oldPodInfoOnMount: true, newPodInfoOnMount: false, </ins> }, { name:              "should be passed when update from false to true", <del> oldPodInfoOnMount: &podInfoFalse, newPodInfoOnMount: &podInfoTrue, }, { name:              "should be passed when update from nil to true", oldPodInfoOnMount: nil, newPodInfoOnMount: &podInfoTrue, </del> <ins> oldPodInfoOnMount: false, newPodInfoOnMount: true, </ins> }, } for _, t := range tests {

Discussion:
1 ci-kubernetes-e2e-gci-gce 1 ci-cos-containerd-e2e-cos-gce in the master blocking test grid 1 ci-kubernetes-e2e-gci-gce-network-proxy-grpc 1 ci-kubernetes-e2e-gci-gce-proto Kubernetes e2e suite.[It] [sig-storage] CSI Mock workload info CSI PodInfoOnMount Update should be passed when update from false to true 12/14 code thaw after 1.29.0 release was merged at the time and is related to PodInfoOnMount. /cc /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
/assign
testCase: podInfoOnMount should be passed when update from false to true kubelet log: csi-mockplugin-0-mock log: the function in the test case is not working as expected. expect log at Line 2, but actual log is at Line 3.
is called twice for the same volume sometime even though the volume is already published successfully. Not only this issue, but also other issues like I wonder if it is a potential bug or a normal behavior. cc what do you think?
good catch. I think that any test that depends on exact index of NodePublish call will be flaky, sometimes Kubelet has to retry NodePublish. It would be better to check for NodePublish parameter changes. For example, test should check there were 1 or more NodePublish calls with no pod info and then 1 or more NodePublish calls with pod info afterwards.
Change:
: ${KUBE_GCE_INSTANCE_PREFIX:="e2e-autoscaling"} : ${PROJECT:="k8s-jnks-e2e-gce-autoscaling"} : ${FAIL_ON_GCP_RESOURCE_LEAK:="true"} <ins> : ${ENABLE_DEPLOYMENTS:=true} </ins> # Override GCE default for cluster size autoscaling purposes. ENABLE_CLUSTER_MONITORING="googleinfluxdb" ADMISSION_CONTROL="NamespaceLifecycle,InitialResources,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"

Discussion:
We need to write e2e tests which combines horizontal pod autoscaling with deployments (scale sub-resourcer should point to a deployment object). The tests should be similar to The library from should be extended and allow creation of a resource consumer as a deployment (currently it is always replication controller). The new tests should create a deployment resource consumer and pass a scale-sub-resource to the deployment to autoscaler.
part of
/cc
/cc FYI requests have been made to verify behavior at scale on *this.
Yeah that sounds like a good test to run re: scale out to n node cc also
Change:
} } podStatus.Conditions = append(podStatus.Conditions, getPodReadyCondition(spec, podStatus.ContainerStatuses)...) hostIP, err := kl.GetHostIP() if err != nil { glog.Errorf("Cannot get host IP: %v", err)

Discussion:
Currently kubelet reports current status only. If pod's restart policy is not never, the last terminated container status will be override by the latest status, and lost. We should report last terminated container status. I am going to update our v1beta3 api first, but will hold the implementation until we have
did you have a chance to start working on it? IIUC, to support this we need to change the api (), which IIUC from what wrote in some other thread should be done this week. I'm happy to help with it if you want me to help.
Only breaking changes have a deadline. Additive changes can be done at any time.
I am working on this. PR should be ready today or tomorrow.
Also agree with This is not part of API breakage.
Thanks for answers & clarifications and
Change:
"github.com/spf13/pflag" "k8s.io/kubernetes/contrib/mesos/pkg/executor/service" "k8s.io/kubernetes/contrib/mesos/pkg/hyperkube" <del> "k8s.io/kubernetes/pkg/util" </del> "k8s.io/kubernetes/pkg/util/flag" "k8s.io/kubernetes/pkg/util/logs" "k8s.io/kubernetes/pkg/version/verflag"

Discussion:
When I tried to use the following command to build kubernetes: I encountered the following errors: I'm using Ubuntu 14.04 and the code from master branch. will submit a patch then to fix this problem.
whoa, I just landed in the exact same place, I am trying to build k8s on a CentOS7 box. Tried with removing the unused utils and works like a charm !
Change:
// in, ensuring the appropriate nested handler method is invoked. An object // that starts passing the filter after an update is considered an add, and an // object that stops passing the filter after an update is considered a delete. <ins> // Like the handlers, the filter MUST NOT modify the objects it is given. </ins> type FilteringResourceEventHandler struct { FilterFunc func(obj interface{}) bool Handler    ResourceEventHandler

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 discovered colleagues writing informer clients that modify objects delivered by informers. I went looking for where it says they should not do that, and I could not find it. What you expected to happen: I expected this critical restriction to be prominently documented. How to reproduce it (as minimally and precisely as possible): Try to find where it says that a client of an informer must not modify an object delivered by the informer. Anything else we need to know?: 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:
Documentation aside, I would suggest adding to your CI infra to make it harder for people to make this mistake.
/assign Thank you for fixing docs!
Change:
return } if status, ok := obj.(*metav1.Status); ok { <del> ae.ResponseStatus = status </del> <ins> // selectively copy the bounded fields. ae.ResponseStatus = &metav1.Status{ Status: status.Status, Reason: status.Reason, Code:   status.Code, } </ins> } if ae.Level.Less(auditinternal.LevelRequestResponse) {

Discussion:
We the into the field of audit events. This was done to capture the response status even when the response is omitted, but results in (potentially large) duplicate data being sent. In some examples, the status message is repeated in the status details, resulting in a long message being duplicated 4 times. I suggest that rather than copying the whole ResponseStatus, we selectively copy the bounded fields, specifically: status reason code Note that this is a breaking change, and if there is agreement should be done before graduating audit to stable. /kind bug /sig auth /priority important-soon
/cc
Could you go ahead and add "approved-for-milestone" label to this, as well as status? That will help it stay in the milestone if this is a 1.10 blocker. Thanks!
Moving it to 1.11, together with graduating audit logging API to stable
/sig auth /kind bug /milestone v1.11 /priority important-soon /status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : 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
No one is working on this? Mind if I assign it?
status check? This has maybe gone dormant. Is it still targeting 1.11?
Yes.
Change:
if _, err := io.Copy(w, r); err != nil { return fmt.Errorf("failed to compress %q to %q: %v", log, tmpLog, err) } <ins> // The archive needs to be closed before renaming, otherwise an error will occur on Windows. w.Close() f.Close() </ins> compressedLog := log + compressSuffix if err := c.osInterface.Rename(tmpLog, compressedLog); err != nil { return fmt.Errorf("failed to rename %q to %q: %v", tmpLog, compressedLog, err) } // Remove old log file. <ins> r.Close() </ins> if err := c.osInterface.Remove(log); err != nil { return fmt.Errorf("failed to remove log %q after compress: %v", log, err) }

Discussion:
Currently, when kubelet will try to compress the logs to a .gz file, it will attempt to rename the archive before closing its file handles, which results in an error on Windows. An error should not occur while compressing the logs. This error can easily be reproduced by running the unit tests on Windows: /sig windows Kubernetes v1.22. N/A Any Windows OS. <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
Change:
} zone := cloudprovider.Zone{ <del> FailureDomain: failureDomain, Region:        to.String(vm.Location), </del> <ins> FailureDomain: strings.ToLower(failureDomain), Region:        strings.ToLower(to.String(vm.Location)), </ins> } return zone, nil }

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: Azure cloud provider gets the availability zone from IMDS directly and the zone is usually in lower cases in most regions. But there're chances this is not true in some regions, hence customer's workloads depend on availability zone may not work. What you expected to happen: The availability zone is always in lower cases. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: 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: /kind bug /sig cloud-provider /area provider/azure
/assign
Fixed by .
Change:
"fmt" "math" "reflect" <ins> "sync" </ins> "testing" <del> "k8s.io/utils/pointer" </del> <ins> "github.com/google/go-cmp/cmp" </ins> dto "github.com/prometheus/client_model/go" <ins> "k8s.io/component-base/metrics" "k8s.io/component-base/metrics/legacyregistry" "k8s.io/utils/pointer" </ins> ) func samples2Histogram(samples []float64, upperBounds []float64) Histogram {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : run got the below error message, We should provide the metric data for different extension points from the metric of "schedulerframeworkextensionpointdurationseconds" Why is this needed: Those metrics have been removed by this commit - Those metrics are deprecated cause it is suggested to use - , but simply remove those metrics definitely is not a nice way to address the issue. /sig scheduling
/triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /triage accept 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
/triage accepted
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-contributor-experience at . /lifecycle stale
/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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
path, err := ioutil.TempDir("", "FileStore") assert.NoError(t, err) defer cleanUpTestPath(t, path) <del> store := &FileStore{path: path} </del> <ins> store, err := NewFileStore(path) assert.NoError(t, err) </ins> Checkpoints := []struct { key       string

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Using to start a cluster with only one node and found that there are some error logs in kubelet as following: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
cc
/cc
Seems caused by my env due to I cannot access gcr due to the proxy failed, will continue to check...
We should create the checkpoint directory when creating the checkpoint store, or else the list failed error will be quite spammy before a container is created.
Will push a fix soon.