jiebi/CodeConvo huggingface dataset:
Change:
type AuthInfo struct { // LocationOfOrigin indicates where this object came from.  It is used for round tripping config post-merge, but never serialized. // +k8s:conversion-gen=false <del> LocationOfOrigin string </del> <ins> LocationOfOrigin string `json:"-"` </ins> // ClientCertificate is the path to a client cert file for TLS. // +optional ClientCertificate string `json:"client-certificate,omitempty"`

Discussion:
yaml.Marshal a kubeconfig, as done in the example tests here LocationOfOrigin is not seen in output, as comment says "never serialized." Click "run example" doesn't suffer from this as it does some conversion <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
/assign /triage accepted
is what's known as internal type. It is not intended to be serialized by code. The serialization version is in and does not have this field. I could get behind removing all json tags from the internal version, but I wouldn't refine tags that shouldn't be used.
Change:
"k8s.io/component-base/configz" "k8s.io/component-base/logs" logsapi "k8s.io/component-base/logs/api/v1" <ins> "k8s.io/component-base/metrics/features" </ins> "k8s.io/component-base/metrics/legacyregistry" <ins> "k8s.io/component-base/metrics/prometheus/slis" </ins> "k8s.io/component-base/term" "k8s.io/component-base/version" "k8s.io/component-base/version/verflag"

Discussion:
As per, , wire up metrics/slis for KCM
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
/sig instrumentation
Change:
"Metric": gstruct.Ignore(), "Value":  gomega.And(gomega.BeNumerically(">=", lower), gomega.BeNumerically("<=", upper)), "Timestamp": gomega.WithTransform(func(t model.Time) time.Time { <ins> if t.Unix() <= 0 { return time.Now() } </ins> // model.Time is in Milliseconds since epoch return time.Unix(0, int64(t)*int64(time.Millisecond)) },

Discussion:
When scrape kubelet resource metrics provided by /metrics/resource, got response like this The metric containerstarttimeseconds's timestamp should not equals to container start time As above No response v1.24.7 Volc Engine No response No response No response No response_
I would like to take this up, after triage/accepted I just wanted to know then what time should be needed to be set there? /assign
the metric should not have a timestamp
If not timestamp, then what value and data type should I assign for the containerstarttime_seconds metric?
check
no need to change the value and data type, just remove the timestamp for the metric datapoint
Sure got it, raising a PR for the same!
If you have already done it, then why the PR is blocked and why I am redoing it again? Just curious to know!
Why do you think it's blocked and why are you redoing it before figuring this out?
/sig node
/triage accepted /priority important-longterm
/assign (since you sent a PR)
Change:
}, }, update: networking.NetworkPolicy{ <del> ObjectMeta: metav1.ObjectMeta{Name: "baz", Namespace: "bar"}, </del> <ins> ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: "bar"}, </ins> Spec: networking.NetworkPolicySpec{ <del> PodSelector: metav1.LabelSelector{}, Ingress:     []networking.NetworkPolicyIngressRule{}, </del> <ins> PodSelector: metav1.LabelSelector{ MatchLabels: map[string]string{"a": "b"}, }, Ingress: []networking.NetworkPolicyIngressRule{}, </ins> }, }, }, <del> "change spec": { </del> <ins> } for testName, successCase := range successCases { successCase.old.ObjectMeta.ResourceVersion = "1" successCase.update.ObjectMeta.ResourceVersion = "1" if errs := ValidateNetworkPolicyUpdate(&successCase.update, &successCase.old); len(errs) != 0 { t.Errorf("expected success (%s): %v", testName, errs) } } errorCases := map[string]npUpdateTest{ "change name": { </ins> old: networking.NetworkPolicy{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: "bar"}, Spec: networking.NetworkPolicySpec{

Discussion:
I tried to update the NetworkPolicy Spec field with more ingress rules but got It seems NetworkPolicy does not allow update on Spec This means if I want to have more ingress rules, I will have to add those in a new networkpolicy in the same namespace. Any reason why I should not add those in the existing one(update the existing networkpolicy)? Thanks!
This is as designed for now. The expectation is that updates to the spec will be allowed when the NetworkPolicy API moves from v1beta1 to GA.
(And that is planned for Kubernetes 1.6 release.)
good to know, thanks!
Note that the PR to move NetworkPolicy to v1 did not make it into v1.6, but is now planned for 1.7:
Oh, I didn't know about this bug and that didn't get changed in but we can do it as another PR after. (I'm trying to not make any more changes there so we can get it merged.)
Change:
} const ( <del> kubeReservedCgroup   = "kube_reserved" systemReservedCgroup = "system_reserved" </del> <ins> kubeReservedCgroup   = "kube-reserved" systemReservedCgroup = "system-reserved" </ins> ) func createIfNotExists(cm cm.CgroupManager, cgroupConfig *cm.CgroupConfig) error {

Discussion:
/kind failing-test /sig node , , Failure: is the likely culprit. /assign cc
/kind e2e-test-failure
I'll take a look... Thanks!
Change:
} } <del> func buildEnv(hasParams bool, hasAuthorizer bool, types typeOverwrite) (*cel.Env, error) { </del> <ins> func buildEnvSet(hasParams bool, hasAuthorizer bool, types typeOverwrite) (*environment.EnvSet, error) { </ins> baseEnv := environment.MustBaseEnvSet(environment.DefaultCompatibilityVersion()) requestType := plugincel.BuildRequestType() namespaceType := plugincel.BuildNamespaceType()

Discussion:
When I load a policy definition like this The object is updated with the following status While this error is reported, the policy does seem to be fully functioning This is similar to the documented examples No error reported on a valid spec Create a a policy that uses variables Observe the status of the newly created policy No response <details</details<detailsn/a </details<details</details<detailskind </details<details</details<details</details
/sig api-machinery
/assign Oops. Good find. Thank you. /triage accepted
Change:
} if _, err := iptClient.EnsureRule(utiliptables.Append, utiliptables.TableNAT, KubePostroutingChain, masqRule...); err != nil { klog.Errorf("Failed to ensure SNAT rule for packets marked by %v in %v chain %v: %v", KubeMarkMasqChain, utiliptables.TableNAT, KubePostroutingChain, err) <del> return </del> <ins> return false </ins> } <ins> return true </ins> } // getIPTablesMark returns the fwmark given the bit

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-features Which test(s) are failing: Networking should recreate its iptables rules if they are deleted [Disruptive] Since when has it been failing: Commit Testgrid link: Reason for failure: Anything else we need to know: Possibly related to this? It's listed in the git diff /sig network
/assign /cc Thanks for detecting it so quicklly
most probably is related to
/unassign /assign he has already submitted a fix
/triage accepted
Reviewed. Marking as resolved on the CI Signal Board. Once was merged, failures stopped and they have not re-occurred in the last 8 days (Oct 10th)
Yay
Change:
return exist, nil } <ins> func (runner *runner) DeleteRule(table Table, chain Chain, args ...string) error { exist := true fullArgs := makeFullArgs(table, opListChain, chain, fullMac) out, err := runner.exec.Command(cmdebtables, fullArgs...).CombinedOutput() if err != nil { exist = false } else { exist = checkIfRuleExists(string(out), args...) } if !exist { return nil } fullArgs = makeFullArgs(table, opDeleteRule, chain, args...) out, err = runner.exec.Command(cmdebtables, fullArgs...).CombinedOutput() if err != nil { return fmt.Errorf("Failed to delete rule: %v, output: %s", err, out) } return nil } </ins> func (runner *runner) EnsureChain(table Table, chain Chain) (bool, error) { exist := true

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The ebtables utility in is missing 3 useful features: method in its Interface table chain Why is this needed: The missing features are useful to allow for: rule deletion as there is a way to add (ensure) a rule but not removing it currently. manipulating the broute table and brouting chain The first feature would also align ebtables with iptables, as a DeleteRule method is available there.
/sig network
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Is there some feature/bugfix you're working on in kubernetes that needs this?
Yes, in kubernetes/dns (node-cache) actually. That PR is working, but it's only in my fork of kubernetes/dns at the moment as it depends on this. It solves this: Adding this code to ebtables would help me avoid re-inventing the wheel there.
... not sure if you've seen that ... but I have created a PR to solve this issue already:
Yes, I saw the PR first. So, kubernetes/kubernetes isn't really intended to be vendored into other repos and kubernetes/dns is being bad here. It's dubious to add methods to that kubernetes itself isn't using because someone else might just end up removing them later when they notice that they're not being used... OTOH the PR needs access to the internals of the ebtables code so you couldn't just add it to kubernetes/dns directly without forking all of ...
Thanks for your comments. I saw iptables used that way in node-cache and I thought it would be good for consistency to go down the same route with ebtables. To be honest I am not very keen on forking the entire package, for obvious reasons, but I can understand your reservations about this change.
/assign
Hi Did you manage to discuss this?
yes, sorry, didn't get a chance to get back to this on Friday. (I /lgtm'ed the PR) /remove-triage unresolved
Thanks!
Change:
// DescribeLimitRanges merges a set of limit range items into a single tabular description func DescribeLimitRanges(limitRanges *corev1.LimitRangeList, w PrefixWriter) { if len(limitRanges.Items) == 0 { <del> w.Write(LEVEL_0, "No resource limits.n") </del> <ins> w.Write(LEVEL_0, "No LimitRange resource.n") </ins> return } w.Write(LEVEL_0, "Resource Limitsn TypetResourcetMintMaxtDefault RequesttDefault LimittMax Limit/Request Ration")

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : If I have a that has a resource and I describe the namespace, I see that CPU and Memory limits/requests are present for the namespace, but a confusing "No resource limits." message is present at the bottom. Ex. I would like to see this "No resource limits." message replaced with something that makes it more clear to the user what is missing or not in use (since it's not apparently cpu or memory limits). From poking around the source code, the message stems from and seems to be intended to describe whether a resource is present or not. But from how it reads, it seems to be very vague and a user could easily assume that it refers to cpu and memory for the namespace instead. Why is this needed: Users using kubectl to inspect their namespace can be easily confused and either think that their namespace is missing a ResourceQuota or that conflicting information about CPU and memory resource limits for the namespace is being presented.
/sig cli
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:
"fmt" "reflect" "sort" <ins> "strings" </ins> "sync" jsonpatch "github.com/evanphx/json-patch"

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:
glog.Fatal(err) } <ins> if kubeletFlags.ContainerRuntime == "remote" && cleanFlagSet.Changed("pod-infra-container-image") { glog.Warning("Warning: For remote container runtime, --pod-infra-container-image is ignored in kubelet, which should be set in that remote runtime instead") } </ins> // load kubelet config file, if provided if configFile := kubeletFlags.KubeletConfigFile; len(configFile) > 0 { kubeletConfig, err = loadConfigFile(configFile)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When use remote container runtime, the remote can't get any PodSandboxImage config set by kubelet What you expected to happen: We want the all container runtime should know what's right PodSandboxImage How to reproduce it (as minimally and precisely as possible): in new node with into k8s cluster kubelet with options expect frakti can create sandbox container with , but get default (k8s version: v1.8.2) Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: bootstrap by kubeadm v1.8.2 OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch) Kernel (e.g. ): SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x8664 GNU/Linux Install tools: kubeadm Others:
/sig node
good news! thanks!
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Actually we do a no-op when the container runtime is . This is why config can not be set by flag for . In your case, the correct place to change the default sandbox image is in .
Change:
Spec: jobSpec(), }, }, <del> deltaTimeForQueue:    0 * time.Second, roundOffTimeDuration: 500*time.Millisecond + nextScheduleDelta, </del> <ins> deltaTimeForQueue: 0 * time.Second, </ins> }, { name: "spec.schedule changed", fields: fields{ <del> queue:          workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "test-update-cronjob"), </del> <ins> queue:          &fakeQueue{RateLimitingInterface: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "test-update-cronjob")}, </ins> recorder:       record.NewFakeRecorder(10), jobControl:     jc, cronJobControl: cjc,

Discussion:
pull-kubernetes-unit TestController2updateCronJob/spec.schedulechanged TestController2_updateCronJob /sig apps /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
This is important to resolve before promotion to v1
looks like the cause was
This function should be related.
Another one:
When the flake happen, there are messages like When the system is overloaded, it would happen. is trying to replace the current queue in tests with a mock.
Yeah, I spoke with to make sure we use a mock of the queue so we only get the most important bit of information ignoring the remaining parts
Change:
// if we're given paths as inputs, generate .pb.go files based on those paths for _, file := range request.FileToGenerate { if strings.Contains(file, "/") { <del> param := "paths=source_relative" request.Parameter = &param </del> <ins> if request.Parameter != nil { *request.Parameter += ",paths=source_relative" } else { param := "paths=source_relative" request.Parameter = &param } </ins> break } }

Discussion:
We tried to run command to generate file. But the option in the command seems to have not been effective. Perhaps it was commit that caused the issue. used to replace all params. If the file path contains '/', other options should also take effect. Run command like which contains request parameter and proto file path. No response_ <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/area code-generation
/assign
/assign /triage accepted
GitHub didn't allow me to assign the following users: dinhxuanvu. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /triage accepted 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
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
is this issue still affecting you on the current release?
Yes, but I have no time to fix it.
Thanks Fulvio for taking this :) /triage accepted
Hi I'll implement this as agreed at the bi-weekly meeting
Change:
// createTargetedProbeCommand returns a command line that performs a DNS lookup for a specific record type func createTargetedProbeCommand(nameToResolve string, lookup string, fileNamePrefix string) (string, string) { fileName := fmt.Sprintf("%s_udp@%s", fileNamePrefix, nameToResolve) <del> probeCmd := fmt.Sprintf("dig +short +tries=12 +norecurse %s %s > /results/%s", nameToResolve, lookup, fileName) </del> <ins> probeCmd := fmt.Sprintf("dig +short +tries=12 %s %s > /results/%s", nameToResolve, lookup, fileName) </ins> return probeCmd, fileName }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: dns test failure when using kube-dns with dnsmasq 2.79 dnsmasq 2.79 introduced a change to respond to all norecurse queries with ServFail. This is to prevent cache snooping where an adversary can figure out if a particular hostname has been looked up or not. We need to change the test to drop that flag, likely the intention was to not send the query upstream(outside of kubedns), but the flag will restrict the query to just dnsmasq. One instance of the test failure: https://k8s- What you expected to happen: The test should be fixed to drop the no recursion flag. How to reproduce it (as minimally and precisely as possible): Run kube-dns with dnsmasq 2.79. dig +norecurse <any hostnameAnything 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 networking
/sig network
/sig network
Change:
{ name:     "Unsorted Nested Pod", err:      false, <del> expected: sets.NewString("nested", "nested2"), </del> <ins> expected: sets.NewString("nested", "nested2", "nested-vol", "nested.vol"), </ins> volname:  "vol1", pod: v1.Pod{ ObjectMeta: metav1.ObjectMeta{

Discussion:
to have all the mount points sorted and grouped. For example, the following strings are sorted in this exact order: With the current implementation, test, we would get: This is worse on Windows, where paths usually have backslashes instead (with no test changes): [1] ` should group mount points correctly. /kind bug /sig windows Kubernetes master, Kubernetes v1.25 and older. N/A N/A <details</details<details</details<details</details
/triage accepted /milestone v1.26
Change:
closeFn, cjc, jc, informerSet, clientSet := setup(ctx, t) defer closeFn() <ins> // When shutting down, cancel must be called before closeFn. // We simply call it multiple times. defer cancel() </ins> cronJobName := "foo" namespaceName := "simple-cronjob-test"

Discussion:
integration-master TestCronJobLaunchesPodAndCleansUp test increased from ~30 seconds to ~90 seconds Since merging This was reported in /sig apps /wg structured-logging
/milestone v1.27
/sig apps /wg structured-logging
It's caused by reordering the context cancellation in the test. I have a fix. /assign
/triage accepted
Change:
return list, false } <ins> func findConditionByType(list []batch.JobCondition, cType batch.JobConditionType) *batch.JobCondition { for i := range list { if list[i].Type == cType { return &list[i] } } return nil } </ins> func recordJobPodFinished(job *batch.Job, oldCounters batch.JobStatus) { completionMode := completionModeStr(job) diff := job.Status.Succeeded - oldCounters.Succeeded

Discussion:
If the user update , duplicate condition: ! Only one Failed condition Create Job and wait it marked as Failed Update the Failed condition to False No response <details</details<details</details<details</details<details</details<details</details<details</details
It's not a bug. The is a list, so it can contain many conditions with different probe timestamps. Also, we should not update the fields.
But should we avoid the duplicate Type's conditionIn my opinionthis will confuse the user. According to kubelet, it will rewrite the 'Ready' condition in pod, and take is as managed only by kubelet. Should we did this for job Failed condition? Refer:
/sig apps
It is a bug. We should only have one condition for each type. /triage accepted
/assign
/assign
/assign
I have reproduced the issue locally and intend work on the fix
/priority backlog Since the user is manually modifying the status, this is not an inherent bug in the controller. Still worth avoiding duplicates.
Change:
Pid:                 1000, ProcessName:         "fakeProcess", TimeOfDeath:         time.Now(), <del> ContainerName:       recordEventContainerName, VictimContainerName: "some-container", </del> <ins> ContainerName:       recordEventContainerName + "some-container", VictimContainerName: recordEventContainerName, </ins> }, } numExpectedOomEvents := len(oomInstancesToStream)

Discussion:
What happened: A SystemOOM event was not reported even when the memory limit hit was the root cgroup memory limit. What you expected to happen: A SystemOOM event should have been reported. How to reproduce it (as minimally and precisely as possible): Do not set or , and set to disable memory eviction on the kubelet. Run a pod without memory limits which slowly consumes memory, such as with from Use arguments -mem-alloc-size", "100Mi", "-mem-alloc-sleep", "10s". This should trigger an OOM on the root cgroup, but no event will be generated. Anything else we need to know?: cAdvisor populates ContainerName and VictimContainerName from matching the regexp: instead in the kubelet. cc
/sig node /priority important-soon