jiebi/CodeConvo huggingface dataset:
Change:
func (c *gitRepoVolumeUnmounter) TearDownAt(dir string) error { // Wrap EmptyDir, let it do the teardown. <del> wrapped, err := c.plugin.host.NewWrapperUnmounter(c.volName, wrappedVolumeSpec, c.podUID) </del> <ins> wrapped, err := c.plugin.host.NewWrapperUnmounter(c.volName, wrappedVolumeSpec(), c.podUID) </ins> if err != nil { return err }

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
func (v *visitor) comment(x *ast.BasicLit) string { for _, comm := range v.cMap.Comments() { testOffset := int(x.Pos()-comm.End()) - len("framework.ConformanceIt("") <del> if 0 < testOffset && testOffset < 3 { return comm.Text() </del> <ins> //Cannot assume the offset is within three or four tabs from the test block itself. //It is better to trim the newlines, tabs, etc and then we if the comment is followed //by the test block itself so that we can associate the comment with it properly. if 0 <= testOffset && testOffset <= 10 { b1 := make([]byte, x.Pos()-comm.End()) //if we fail to open the file to compare the content we just assume the //proximity of the comment and apply it. myf, err := os.Open(v.FileSet.File(x.Pos()).Name()) if err == nil { if _, err := myf.Seek(int64(comm.End()), 0); err == nil { if _, err := myf.Read(b1); err == nil { if strings.Compare(strings.Trim(string(b1), "t rn"), "framework.ConformanceIt("") == 0 { return comm.Text() } } } } else { //comment section's end is noticed within 10 characters from framework.ConformanceIt block return comm.Text() } </ins> } } return ""

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!--What happened: When the comment section associated with the conformance test is separated with more that four spaces/tabs etc then the comment is ignored. What you expected to happen: Comment associated with the conformance test should be used instead of ginkgo comments. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Received output (due to extra tabs) Expected output: Release : v1.13 If the restart policy is set to ‘Always’, Pod MUST be restarted when terminated, If restart policy is ‘OnFailure’, Pod MUST be started only if it is terminated with non-zero exit code. If the restart policy is ‘Never’, Pod MUST never be restarted. All these three test cases MUST verify the restart counts accordingly. Environment: Kubernetes version (use ): 1.13 /kind bug
/area conformance /sig architecture thanks for the report and the fix!
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Change:
# TODO(pjh): move the logging agent code below into a separate # module; it was put here temporarily to avoid disrupting the file layout in # the K8s release machinery. <del> $LOGGINGAGENT_VERSION = '1.6.0' </del> <ins> $LOGGINGAGENT_VERSION = '1.7.3' </ins> $LOGGINGAGENT_ROOT = 'C:fluent-bit' $LOGGINGAGENT_SERVICE = 'fluent-bit' $LOGGINGAGENT_CMDLINE = '*fluent-bit.exe*' <del> $LOGGINGEXPORTER_VERSION = 'v0.10.3' </del> <ins> $LOGGINGEXPORTER_VERSION = 'v0.16.2' </ins> $LOGGINGEXPORTER_ROOT = 'C:flb-exporter' $LOGGINGEXPORTER_SERVICE = 'flb-exporter' $LOGGINGEXPORTER_CMDLINE = '*flb-exporter.exe*'

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 --The default fluent-bit configuration for GCE Windows nodes produces unparsed JSON logs and does not forward container logs. Container log output is produced. fluent-bit on a given windows image. a GCE Windows e2e cluster and view the stackdriver output for pods. Kubernetes version (use ): 1.20+ Cloud provider or hardware configuration: GKE/GCE OS (e.g: ): Windows Kernel (e.g. ): Any version Install tools: fluent-bit 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 windows
Change:
case "docker": streamingConfig := getStreamingConfig(kubeCfg, kubeDeps) // Use the new CRI shim for docker. <del> ds, err := dockershim.NewDockerService(klet.dockerClient, kubeCfg.SeccompProfileRoot, kubeCfg.PodInfraContainerImage, streamingConfig, &pluginSettings, kubeCfg.RuntimeCgroups) </del> <ins> ds, err := dockershim.NewDockerService(klet.dockerClient, kubeCfg.SeccompProfileRoot, kubeCfg.PodInfraContainerImage, streamingConfig, &pluginSettings, kubeCfg.RuntimeCgroups, kubeCfg.CgroupDriver) </ins> if err != nil { return nil, err }

Discussion:
Kubernetes version (use ): v1.5.0-alpha.1.2189+-dirty docker: 1.12.3 Environment: fedora24 docker-engine-1.12.3-1.fc24.x86_64 What happened: if docker Cgroup Driver=cgroupfs, and set --cgroup-driver=systemd in kubelet, then enable --experimental-cgroups-per-qos=true; The container cgroup some is not correct. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: 1) docker Cgroup Driver=cgroupfs and --cgroup-driver=cgroupfs in kubelet works well 2) docker Cgroup Driver=systemd and --cgroup-driver=systemd in kubelet works well
help check, thanks.
In Kubernetes 1.6, we can work to detect this case and return an error. IMHO its a configuration error to have docker running with a cgroupfs driver paired with the kubelet running the systemd cgroup driver. /cc
We can also document the compatibility matrix for now.
Change:
"type": "object" }, "io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.CustomResourceDefinition": { <del> "description": "CustomResourceDefinition represents a resource that should be exposed on the API server.  Its name MUST be in the format <.spec.name>.<.spec.group>. Deprecated in v1.16, planned for removal in v1.19. Use apiextensions.k8s.io/v1 CustomResourceDefinition instead.", </del> <ins> "description": "CustomResourceDefinition represents a resource that should be exposed on the API server.  Its name MUST be in the format <.spec.name>.<.spec.group>. Deprecated in v1.16, planned for removal in v1.22. Use apiextensions.k8s.io/v1 CustomResourceDefinition instead.", </ins> "properties": { "apiVersion": { "description": "APIVersion 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: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources",

Discussion:
The following code snippet is very confusing: Is v1beta1 deprecated in 1.16 or 1.19? Is it to be removed in 1.19 or 1.22? Please clarify the exact versions so the many users of CRD v1beta1 APIs know what to do.
/sig api-machinery
/kind deprecation
/unkind feature
Deprecated in 1.16. Planned to be removed in 1.22. We'll update the docs to be consistent before 1.19 is released.
/assign
Change:
case "v1beta1", "v1beta2": return "DesiredState.Host" default: <del> return "Status.Host" </del> <ins> return "status.host" </ins> } }

Discussion:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.
Change:
plugins.Filter = appendToPluginSet(plugins.Filter, interpodaffinity.Name, nil) return }) <ins> registry.RegisterPredicate(predicates.EvenPodsSpreadPred, func(_ ConfigProducerArgs) (plugins config.Plugins, pluginConfig []config.PluginConfig) { plugins.Filter = appendToPluginSet(plugins.Filter, podtopologyspread.Name, nil) return }) // Register Priorities. </ins> registry.RegisterPriority(priorities.TaintTolerationPriority, func(args ConfigProducerArgs) (plugins config.Plugins, pluginConfig []config.PluginConfig) { plugins.Score = appendToPluginSet(plugins.Score, tainttoleration.Name, &args.Weight) return }) registry.RegisterPriority(priorities.NodeAffinityPriority, func(args ConfigProducerArgs) (plugins config.Plugins, pluginConfig []config.PluginConfig) { plugins.Score = appendToPluginSet(plugins.Score, nodeaffinity.Name, &args.Weight) return }) registry.RegisterPriority(priorities.ImageLocalityPriority, func(args ConfigProducerArgs) (plugins config.Plugins, pluginConfig []config.PluginConfig) { plugins.Score = appendToPluginSet(plugins.Score, imagelocality.Name, &args.Weight) return }) registry.RegisterPriority(priorities.NodePreferAvoidPodsPriority, func(args ConfigProducerArgs) (plugins config.Plugins, pluginConfig []config.PluginConfig) { plugins.Score = appendToPluginSet(plugins.Score, nodepreferavoidpods.Name, &args.Weight)

Discussion:
What would you like to be : Add a filter plugin that calls into EvenPodsSpread predicate, example Why is this needed: Part of /sig scheduling /help /priority important-soon
/assign
/remove-help
/retitle: [migration phase 1] EvenPodsSpread as filter plugin
/retitle [migration phase 1] EvenPodsSpread as filter plugin
/assign /unassign
May I take over this?
is going to take this over after the offline discussion, and he is familiar with EvenPodsSpread
IC, thanks a lot.
Change:
tt.action(f) <del> collectAndCompare(t, tt.wantExtensionPoint, tt.wantStatus) </del> <ins> collectAndCompareFrameworkMetrics(t, tt.wantExtensionPoint, tt.wantStatus) }) } } func TestPermitWaitingMetric(t *testing.T) { tests := []struct { name    string inject  injectedResult wantRes string }{ { name: "Permit - Success", }, { name:    "Permit - Wait Timeout", inject:  injectedResult{PermitStatus: int(Wait)}, wantRes: "Unschedulable", }, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { plugin := &TestPlugin{name: testPlugin, inj: tt.inject} r := make(Registry) r.Register(testPlugin, func(_ *runtime.Unknown, fh FrameworkHandle) (Plugin, error) { return plugin, nil }) plugins := &config.Plugins{ Permit: &config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin, Weight: 1}}}, } f, err := NewFramework(r, plugins, emptyArgs) if err != nil { t.Fatalf("Failed to create framework for testing: %v", err) } metrics.Register() metrics.PermitWaitDuration.Reset() f.RunPermitPlugins(context.TODO(), nil, pod, "") collectAndComparePermitWaitDuration(t, tt.wantRes) </ins> }) } }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : metric name Description -- -- permitwaitduration_seconds Duration of permit extension point finishes waiting. Why is this needed: In permit extension point, if the status is "Wait", we block until the pod is scheduled or timeout: Blocking is an important behavior that we should monitor. /sig scheduling
/assign
Change:
// timeout of the HTTP request, including reading the response body. const defaultRequestTimeout = 30 * time.Second <ins> // GenericWebhook defines a generic client for webhooks with commonly used capabilities, // such as retry requests. </ins> type GenericWebhook struct { RestClient     *rest.RESTClient InitialBackoff time.Duration <ins> ShouldRetry    func(error) bool } // DefaultShouldRetry is a default implementation for the GenericWebhook ShouldRetry function property. // If the error reason is one of: networking (connection reset) or http (InternalServerError (500), GatewayTimeout (504), TooManyRequests (429)), // or apierrors.SuggestsClientDelay() returns true, then the function advises a retry. // Otherwise it returns false for an immediate fail. func DefaultShouldRetry(err error) bool { // these errors indicate a transient error that should be retried. if net.IsConnectionReset(err) || apierrors.IsInternalError(err) || apierrors.IsTimeout(err) || apierrors.IsTooManyRequests(err) { return true } // if the error sends the Retry-After header, we respect it as an explicit confirmation we should retry. if _, shouldRetry := apierrors.SuggestsClientDelay(err); shouldRetry { return true } return false </ins> } // NewGenericWebhook creates a new GenericWebhook from the provided kubeconfig file.

Discussion:
What would you like to be : The api server should retry sending audit events to configured webhook sinks regardless of the type of HTTP error code it might receive from the webhooks. Why is this needed: While some components may live with failed data transmissions, this is a particularly sensitive topic for the audit area. The API server audit mechanisms must ensure that no other reasonable option exists before dropping an audit event that may be the only trace of malicious behavior in the cluster. It seems that the current implementation may be improved further in this direction. Currently, when the API server is configured for non-blocking sending of audit events to a webhook audit sink backend, it will retry up to 5 times with exponential backoff, should there be an error in communicating with the webhook, as implemented . However, not all errors will trigger a retry. Some are considered transient and yield retry. Others simply stop the retry cycle. For example, it retries on receiving HTTP code , but not on receiving . The list of error codes that will yield a retry is actually quite small - three HTTP errors and one network error. Any other error will not trigger a retry and the audit events will be lost. The code comments explain that the retry will consider only recoverable failures, which may make sense in other cases, but as far as sending audit events to an audit backend webhook is concerned, it is not sufficient policy. A more robust approach would be to consider any error and give the backend service a chance to recover instead of relying on the error codes semantics and the webhook implementations interpretation of it. That is more inline with having the transmission of audit events as top priority. /sig auth /sig api-machinery
Change:
<ins> apiVersion: v1 kind: Pod metadata: name: test spec: containers: - name: nginx image: nginx </ins>

Discussion:
What happened: I get a diff, when I specify a file directly, but on recursive mode, no diff is shown anymore: What you expected to happen: Recursive mode should work How to reproduce it (as minimally and precisely as possible): Have a bunch of YAML manifest, but with name collisions, e.g. Service , Deployment , etc Anything else we need to know?: I think the problem is that all objects have the same name, which should not be a problem per se. Only heapster-binding has a different name, and looking at the generated temp files, only and are present: Environment: Kubernetes version (use ): $ kubectl version --short Client Version: v1.13.0 Server Version: v1.13.0 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
I think the files are overwriting each other?
Yeah, good catch, I'll try to fix that asap
Thanks! By the way, very nice work with dry-run and diff. I was waiting for this.
Feel free to look at the PR and give your opinion!
Change:
"golang.org/x/sys/unix" "k8s.io/klog/v2" <ins> "k8s.io/kubernetes/pkg/util/selinux" </ins> "k8s.io/mount-utils" utilpath "k8s.io/utils/path" )

Discussion:
On a busy system, kubelet failed to tell the container runtime that a pod's CSI volume supports SELinux and should be relabeled with pod's SELinux label. The pod then can't access the volume. Kubelet correctly detects that the CSI volume supports SELinux and tells the container runtime to relabel it. Unknown. Get a busy system and try hard? CSI volume plugin tried to detect that the volume supports SELinux during SetupAt. This check failed: Current CSI volume plugin code silently consumes the error and assumes that the volume does not support SELinux at all: Therefore, the volume is marked as mounted and given to the container runtime without the right SELinux options and the runtime does not relabel volume. <details22.0 </details<detailsNone </details<details</details<details</details<detailsCRI-O, but I think it's not really relevant. </details<details</details
/sig storage /triage accepted
We've updated kubelet in our clusters to v1.20.13 (which contains the cherry picked fix), but still observe the issue
Change:
"description": "EndpointConditions represents the current condition of an endpoint.", "properties": { "ready": { <del> "description": "ready indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint. A nil value indicates an unknown state. In most cases consumers should interpret this unknown state as ready. For compatibility reasons, ready should never be "true" for terminating endpoints.", </del> <ins> "description": "ready indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint. A nil value indicates an unknown state. In most cases consumers should interpret this unknown state as ready. For compatibility reasons, ready should never be "true" for terminating endpoints, except when the normal readiness behavior is being explicitly overridden, for example when the associated Service has set the publishNotReadyAddresses flag.", </ins> "type": "boolean" }, "serving": {

Discussion:
The EndpointSlice API says and it works as expected in normal circumstances I delete the pod and the endpoints conditions are the expected However, if during this time I set we run into an incoherence with the API doc, but it seems that we already documented this edge case in the code I think that at this point is just to amend this information to the API, no? /kind bug /kind documentation
/sig network /assign
I would like to work on this. I just want a bit more clarification on what needs to be done!
I proposed a solution, that is clarify it in the doc ... once we reach an agreement in this issue we implement it ...
+1 to docs. I'd make it a little more vague, like: """ when the normal readiness behavior is being explicitly overridden, for example when the associated Service has set the publishNotReadyAddresses flag. """
so, the thing is to update the docs here with Tim's suggestion and here and do to update the generated code and submit a PR
/assign
I am not able to run command in windows, I am checking it. This error message is coming: *
/triage accepted
Is there a PR for this? Happy to review
I will raise the PR if my above problem gets solved. I am trying to make an update but the error mentioned above is coming.
What platform are you on? If the Makefile were really broken EVERYTHING would be failing.
he's on windows ... you will need a linux/macos. see
Let me know if you want someone to take it over.
I think in that case, you can assign this to someone else.
Change:
import ( "context" <ins> "fmt" "reflect" "k8s.io/apimachinery/pkg/conversion" </ins> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/watch" "k8s.io/apiserver/pkg/storage"

Discussion:
Apparently, the bug happens in 1.26.3 but not in 1.27.1 so maybe it's been fixed somewhere. Here are the steps to reproduce: Note that the metrics list is atomic, so the list should be entirely replaced every-time, not merged/appended. /wg api-expression /triage accepted /priority important-soon
I tried to add a printf of the json'd merged object right before leaving the ssa code, and the field isn't duplicated. So something else must be trying to merge somehow!?
I also checked that it's not kubectl doing anything crazy, the response from the server includes the duplicated field.
Checked both before and after admission, object seems to be properly merged.
Ah, something not mentioned in the bug, applying without dry-run doesn't trigger the same behavior.
storage version changed to v2 in 1.27 () HPA conversion is really weird (taking v2 fields and putting them in annotations in v1, then shipping annotations back into appended items when converting back to v2)... I'd suspect something in the storage → conversion path
Right, the exact conversions that we do are different in dry-run vs non-dry-run because we have to storage version. I'm still investigating the conversion path to see if anything seems shady and I've made progress on that.
OK, this is the trace that leads to the internal HorizontalPodAutoscaler object to have the metrics field duplicated is this one: So definitely in the path to dry-run. The following test reproduces the error, as it fails with two identical metrics. Problem is probably that 1. the "out" object isn't cleared before for dry-run. 2. conversion doesn't detect the duplication/remove previous entry from out. I'll check to see how the non-dry-run version clears the out object.
Did anyone find a workaround for this bug? Currently trying to compare equality between two objects after a dry-run to populate default fields.