jiebi/CodeConvo huggingface dataset:
Change:
} volumeAttachedMap[volume] = attached } <del> nodeVolumesAttachMap[vm] = volumeAttachedMap </del> <ins> disksAttached[vm] = volumeAttachedMap </ins> } return disksAttached, 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: Following issue was observed while running the e2e test cases for CSI migration testing. <pre•! Panic [50.165 seconds] [sig-storage] vcp-performance [Feature:vsphere] vcp performance tests [It] Test Panicked assignment to entry in nil map Full Stack Trace (0x0, 0x0, 0x0) +0x105 panic(0x4b3a0e0, 0x5c329d0) +0x166 (0xc0032a3140, 0x0, 0x0, 0x0) </preWhat you expected to happen: Tests util methods should not panic How to reproduce it (as minimally and precisely as possible): Execute test suite which can be found here - Anything else we need to know?: The vsphere util method - is used by multiple test suites (Scale tests, performance tests) Environment: Kubernetes version (use ): <preClient Version: version.Info{Major:"1", Minor:"19+", GitVersion:"v1.19.0-alpha.3.1808+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2020-07-04T03:10:03Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"19+", GitVersion:"v1.19.0-alpha.3.1808+", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-07-02T20:49:42Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"linux/amd64"} </pre- Cloud provider or hardware configuration: vSphere Cloud Provider
/sig storage
Change:
// Complete completes all the required options. func (o *Options) Complete() error { if len(o.ConfigFile) == 0 && len(o.WriteConfigTo) == 0 { <del> klog.InfoS("Warning, all flags other than --config, --write-config-to, and --cleanup are deprecated, please begin using a config file ASAP") </del> o.config.HealthzBindAddress = addressFromDeprecatedFlags(o.config.HealthzBindAddress, o.healthzPort) o.config.MetricsBindAddress = addressFromDeprecatedFlags(o.config.MetricsBindAddress, o.metricsPort) }

Discussion:
remove log warning about not using config file Currently, kube-proxy can be configured via both CLI flags and config file. and config file can override flags. In the future, all flags will be deprecated and use the config file instead. But now the config file is still at the alpha level, so we shouldn't be warning people to stop using flags if there is no config file present. refer to
/kind cleanup /sig network
just append this "... if there is no config file present"
/assign
We talked about this one on the SIG Network meeting today: We agree we should move forward with it: /triage accepted /unassign We are looking for someone from the community with a strong interest to champion it and move it forward, please do comment if you'd like to take this one on and we'd be happy to help facilitate! /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : We talked about this one on the SIG Network meeting today: We agree we should move forward with it: /unassign 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
Ah looks like has already started, thank you! /assign
Change:
path /var/lib/docker/containers/*/*-json.log pos_file /var/lib/docker/containers/containers.log.pos time_format %Y-%m-%dT%H:%M:%S <del> tag docker.container.* </del> <ins> tag docker.* read_from_head true </ins> </source> <del> <match docker.container.**> </del> <ins> <match docker.**> </ins> type google_cloud flush_interval 5s # Never wait longer than 5 minutes between retries.

Discussion:
As Satnam mentioned in PR , our Fluentd pod tends to not collect the first chunk of logs from each container. I've noticed that it seems to miss different amounts of logs depending on how quickly the container generates them, so it may be a timing issue. cc
See
Change:
if opts.StripValueValidation { schema = schema.StripValueValidations() } <ins> if opts.StripNullable { schema = schema.StripNullable() } </ins> schema = schema.Unfold() }

Discussion:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately 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:
var BindingSaturationReportInterval = 1 * time.Second var ( <del> E2eSchedulingLatency = prometheus.NewSummary( prometheus.SummaryOpts{ </del> <ins> E2eSchedulingLatency = prometheus.NewHistogram( prometheus.HistogramOpts{ </ins> Subsystem: schedulerSubsystem, Name:      "e2e_scheduling_latency_microseconds", Help:      "E2e scheduling latency (scheduling algorithm + binding)", <del> MaxAge:    time.Hour, </del> <ins> Buckets:   prometheus.ExponentialBuckets(1000, 2, 15), </ins> }, ) <del> SchedulingAlgorithmLatency = prometheus.NewSummary( prometheus.SummaryOpts{ </del> <ins> SchedulingAlgorithmLatency = prometheus.NewHistogram( prometheus.HistogramOpts{ </ins> Subsystem: schedulerSubsystem, Name:      "scheduling_algorithm_latency_microseconds", Help:      "Scheduling algorithm latency", <del> MaxAge:    time.Hour, </del> <ins> Buckets:   prometheus.ExponentialBuckets(1000, 2, 15), </ins> }, ) <del> BindingLatency = prometheus.NewSummary( prometheus.SummaryOpts{ </del> <ins> BindingLatency = prometheus.NewHistogram( prometheus.HistogramOpts{ </ins> Subsystem: schedulerSubsystem, Name:      "binding_latency_microseconds", Help:      "Binding latency", <del> MaxAge:    time.Hour, </del> <ins> Buckets:   prometheus.ExponentialBuckets(1000, 2, 15), </ins> }, ) BindingRateLimiterSaturation = prometheus.NewGauge(

Discussion:
Currently scheduler latency are observed regardless of failure. For example, binding latency is like: This could be a potential confusion if latency spikes happen because of failure. We should better handle it like separating error case from normal
/cc
I completely agree - are you going to change this?
Yes. I will do it.
Change:
"Name":      gstruct.Ignore(), "StartTime": recent(maxStartAge), "CPU": ptrMatchAllFields(gstruct.Fields{ <del> "Time":                 recent(maxStatsAge), "UsageNanoCores":       bounded(10000, 2e9), </del> <ins> "Time": recent(maxStatsAge), // CRI stats provider tries to estimate the value of UsageNanoCores. This value can be // either 0 or between 10000 and 2e9. // Please refer, https://github.com/kubernetes/kubernetes/pull/95345#discussion_r501630942 // for more information. "UsageNanoCores":       gomega.SatisfyAny(gomega.BeZero(), bounded(10000, 2e9)), </ins> "UsageCoreNanoSeconds": bounded(10000000, 1e15), }), "Memory": ptrMatchAllFields(gstruct.Fields{

Discussion:
<!-- 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 --Which jobs are flaking: Which test(s) are flaking: Testgrid link: https://k8s- Reason for failure: Based on the execution conditions sometimes the value of could be 0 instead of expected Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
/sig node
This particular test also fails on CRIO with Fedora CoreOS platform because the return value of is slightly different on that platform.
thank you for opening this issue. Just to have more visibility in the future, and avoid duplicated work, could you please share issues like this one in #sig-node or with the mailist list for CI improvements ? I also see you opened so will assign you this issue /assign /triage accepted /priority important-longterm /cc
thank you for opening and working on this issue. You can check the for issues logged against tests that are producing non-deterministic results. And also it is worth noting that that logged has a for this problem along with the following specific failures
sorry I wasn't aware of CI Signal project board. Thanks for the link.
sorry my bad, I didn't realize there was already an issue for this.
More failures around not having NetworkStats and MemoryStats,
From the kubelet logs of one of the failed jobs. Open the failed job's and look for
helped me to get rid of errors related fsinfo not available. I do some more testing. It's just a temporary patch which looks for because that's what I am using. If it really works, I could make it more generic.
Change:
event := recorder.makeEvent(ref, annotations, eventtype, reason, message) event.Source = recorder.source <ins> event.ReportingInstance = recorder.source.Host event.ReportingController = recorder.source.Component </ins> // NOTE: events should be a non-blocking operation, but we also need to not // put this in a goroutine, otherwise we'll race to write to a closed channel // when we go to shut down this broadcaster.  Just drop events if we get overloaded,

Discussion:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted
Change:
"//pkg/util/metrics:go_default_library", "//vendor/github.com/golang/glog:go_default_library", "//vendor/k8s.io/api/core/v1:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/api/equality:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/labels:go_default_library",

Discussion:
Currently, endpoints objects containing no subsets are decoded by the go client as subsets:[] (when requested individually) or as subsets:null (when requested in a list of endpoints). Because the endpoints controller is fed via a lister/watcher, it gets the subsets:null version fed to it. The subsets computation then returns an empty slice, which fails reflect.DeepEqual, which triggers a write attempt
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Change:
} // write good config with different webhook <del> if err := os.WriteFile(configFileName, []byte(` </del> <ins> if err := atomicWriteFile(configFileName, []byte(` </ins> apiVersion: apiserver.config.k8s.io/v1beta1 kind: AuthorizationConfiguration authorizers:

Discussion:
ci-kubernetes-integration-master --- FAIL: TestMultiWebhookAuthzConfig (9.23s) (03-20) I cannot search for previous flake. updated recently /sig auth /cc
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
Updated the description, the actual cause of the flake is an unexpected change in the file reload timestamp metric
interestingly, doesn't show any failures of this test for this reason (there are a few failures on a PR that broke a bunch of integration tests for a different reason)
Fix open in , switched the file write to an atomic write
No flake after 03-29. Thanks.
Change:
ENABLE_NODE_MONITORING="${KUBE_ENABLE_NODE_MONITORING:-true}" # Optional: When set to true, heapster will be setup as part of the cluster bring up. <del> ENABLE_CLUSTER_MONITORING="${KUBE_ENABLE_CLUSTER_MONITORING:-false}" </del> <ins> ENABLE_CLUSTER_MONITORING="${KUBE_ENABLE_CLUSTER_MONITORING:-true}" </ins> # Optional: Enable node logging. ENABLE_NODE_LOGGING="${KUBE_ENABLE_NODE_LOGGING:-true}"

Discussion:
Due to changes in field selectors (see ) heapster was almost certainly busted, but continues to pass. This seems incorrect.
Change:
// Iterate through all pods in desired state of world, and remove if they no // longer exist func (dswp *desiredStateOfWorldPopulator) findAndRemoveDeletedPods() { <ins> podsFromCache := make(map[volumetypes.UniquePodName]struct{}) </ins> for _, volumeToMount := range dswp.desiredStateOfWorld.GetVolumesToMount() { <ins> podsFromCache[volumetypes.UniquePodName(volumeToMount.Pod.UID)] = struct{}{} </ins> pod, podExists := dswp.podManager.GetPodByUID(volumeToMount.Pod.UID) if podExists {

Discussion:
If a pod is created and then deleted an entry in processedPods map remains forever (sometimes, it's racy). The problem comes from the fact that calls volume_manager asynchronously. If the last call happens after populator cleaned up resources, an entry is to processedPods and will never be seen. An entry in processedPods map must be deleted if pod doesn't exist and pod runtime should removed according to . To verify that the issue really exists I applaied a simple printing resources in map. Here is a reproducer: brand-new fresh k8s cluster with entries in : a pod, check its uid: that this uid is accurately reported: the pod, wait for a few mins, check for again: The entry will be kept forever because kubelet doesn't know anything about this pod anymore: so no more events will ever come to populater for this uid, and the loop in won't find it because it was already deleted from . n/a <details</details<detailsany </details<details</details<details</details<details</details<details</details
/sig storage
/triage accepted
/priority impoerant-soon
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority impoerant-soon Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority important-soon
/assign
PR () fixed this issue. It is ready to merge since Mar 21.
/assign
Change:
KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. V1_PATH="$PWD/${KUBE_ROOT}/docs/api-reference/v1/" V1BETA1_PATH="$PWD/${KUBE_ROOT}/docs/api-reference/extensions/v1beta1" <ins> SWAGGER_PATH="$PWD/${KUBE_ROOT}/api/swagger-spec/" </ins> mkdir -p $V1_PATH mkdir -p $V1BETA1_PATH <del> docker run -v $V1_PATH:/output gcr.io/google_containers/gen-swagger-docs:v2  </del> <ins> docker run -v $V1_PATH:/output -v ${SWAGGER_PATH}:/swagger-source gcr.io/google_containers/gen-swagger-docs:v3  </ins> v1  <del> https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/swagger-spec/v1.json  </del> https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/api/v1/register.go <del> docker run -v $V1BETA1_PATH:/output gcr.io/google_containers/gen-swagger-docs:v2  </del> <ins> docker run -v $V1BETA1_PATH:/output -v ${SWAGGER_PATH}:/swagger-source gcr.io/google_containers/gen-swagger-docs:v3  </ins> v1beta1  <del> https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/swagger-spec/v1beta1.json  </del> https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/apis/extensions/v1beta1/register.go

Discussion:
From gen-swagger-docs should read the local swagger spec rather than fetching it from That way it generates release api-reference when run-gen-swagger-docs is run in release branch and it generates api-reference for HEAD code, when the script is run on HEAD.
Assigning to as per discussion.
Blocks
Change:
}, }, }, <ins> SecurityContext: &v1.PodSecurityContext{ FSGroup: fsGroup, }, </ins> RestartPolicy: v1.RestartPolicyNever, Volumes: []v1.Volume{ {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (default fs)] volumes should be mountable Since when has it been failing: Testgrid link: Reason for failure: Volume of previous pod is not unmounted before the second pod is trying to mount its volume. Anything else we need to know:
/sig storage /assign
The problem is when client is deleting first pod, it is deleted immediately. This is because when pod status phase is , . But pod is set to before its volumes are unmounted and detached. pod object may be deleted from apiserver before its volumes are unmounted, so it may have conflicts in setting fsGroup for second pod `in-tree-client. If we want to wait for the pod to be deleted by kubelet instead of apiserver, we need to make it a long-running pod. Alternatively, we can make the two pods use the same fsgroup . cc What do you think?
cc is this expected? I thought kubelet is supposed to delete the pod object only after the volumes are unmounted. This also impacts the StorageProtection feature, which assumes that if the Pod object is deleted, then the volume has been unmounted. For a storage backend like nfs, it may result in unmount hanging. cc to fix the flakiness, the simplest thing may be to make the two pods use the same fsgroup. I don't see a strong use case for two pods using different fsgroups.
That is only during graceful deletion. If a pod is Succeeded, do we begin unmounting volumes? Or do we wait until the deletion timestamp is set? Would it be good enough to start unmounting when the pod is failed/succeeded? If we want to be 100% sure this isn't a problem, we would need to always do graceful deletion, even when the pod is failed/succeeded.
Yes, we do start unmounting when pod is . The API is setting grace period to 0 in the case of pod success or failed. Maybe that needs to be removed if we want to use Pod deletion as a signal that volumes are unmounted.

To always do graceful deletion even when the pod is failed/succeeded is simple, then we can assume that normally when pod objects are deleted (except forcefully), volumes are already unmounted by kubelet. But , and it helps to improve performance in deleting jobs in batch. For this flaky test only, what I need is to make sure volumes are unmounted before the second pod is going to mount them, but local volumes are not reported in or other fields of node status, I can't make sure of this by checking node status either. Possible workarounds: make the first a long-running pod (too hacky) wait for a while before starting the second pod (short period may be flaky too, long period increases test time) use same fsGroup for both pods (do not test that fsGroup can be changed) I'm going to use same fsGroup for both pods until we have a reliable way to detect volumes are unmounted or not.
Change:
if !verbCovers { return false } <del> resourceCovers := r.Resource == "*" || r.Resource == action.GetResource().Resource if !resourceCovers { return false } return true </del> <ins> return resourceCovers(r.Resource, action) </ins> } func (r *SimpleReactor) React(action Action) (bool, runtime.Object, error) {

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 -- Can't match "serviceaccounts/token", can only match "serviceaccounts" Can match "serviceaccounts/token"
/kind feature
/sig testing
/assign
/triage accepted
Change:
"k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/client/cache" client "k8s.io/kubernetes/pkg/client/unversioned" <del> controllerFramework "k8s.io/kubernetes/pkg/controller/framework" </del> <ins> controllerframework "k8s.io/kubernetes/pkg/controller/framework" </ins> "k8s.io/kubernetes/pkg/fields" "k8s.io/kubernetes/pkg/labels" "k8s.io/kubernetes/pkg/master/ports"

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done: