jiebi/CodeConvo huggingface dataset:
Change:
package kubelet import ( <ins> "fmt" </ins> "net" "reflect" "strings" "testing" "k8s.io/kubernetes/pkg/api/v1" <ins> "k8s.io/kubernetes/pkg/client/record" </ins> "k8s.io/kubernetes/pkg/util/bandwidth" )

Discussion:
Kubernetes version v1.3.0 Kubelet concatenates host and cluster domain entries for my pod, resulting in an invalid config (too many entries with duplicates). The max is only 6 search domains. Any more and DNS resolution breaks when trying to leverage search domains. The example below has only cluster DNS entries, but illustrates the issue: Host search nameserver 10.233.0.2 nameserver 10.90.0.1 options timeout:2 options attempts:2 Container kubectl run -i --tty busybox --image=busybox -- sh (skip waiting text) / # cat search nameserver 10.233.0.2 options attempts:2 options ndots:5 I should be enable cluster DNS config in my host DNS settings and still have functional pod DNS. Kubelet should be intelligent enough to filter out duplicate search domain entries (or drop search domains beyond the 6th entry)
I think some sane checks needs to be too. libc limits search field to 6 records and 255(?) characters. This limitation should be checked before creation.
Hey guys, I'm working on it.
Dup of
Change:
token, err := GetServicePrincipalToken(config, env) assert.NoError(t, err) <del> oauthConfig, err := adal.NewOAuthConfig(env.ActiveDirectoryEndpoint, config.TenantID) </del> <ins> oauthConfig, err := adal.NewOAuthConfigWithAPIVersion(env.ActiveDirectoryEndpoint, config.TenantID, nil) </ins> assert.NoError(t, err) spt, err := adal.NewServicePrincipalToken(*oauthConfig, config.AADClientID, config.AADClientSecret, env.ServiceManagementEndpoint)

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: Due to the adal SDK implementation, the AAD token obtained by cloud provider from AzureAD token endpoint would have audience prefix. There is an extensive documentation in . The original contains fixes to kubectl as well as cloud provider. This issue will be targeted just to azure cloud provider. This wouldn't have the same impact as What you expected to happen: Change the SDK usage so that the AAD token's audience claim does not have prefix 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:
/area provider/azure /sig cloud-provider
/cc
Change:
} } <ins> func resourcePodSpecWithoutNodeName(memory, cpu string) v1.PodSpec { return v1.PodSpec{ Containers: []v1.Container{{ Resources: v1.ResourceRequirements{ Requests: allocatableResources(memory, cpu), }, }}, } } </ins> func allocatableResources(memory, cpu string) v1.ResourceList { return v1.ResourceList{ v1.ResourceMemory: resource.MustParse(memory),

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.): DaemonSet FailedPlacement Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): OL7.3 Kernel (e.g. ): 4.1.12-94.2.1.el7uek.x86_64 Install tools: Others: What happened: I have a DaemonSet that is only deployed to a subset of nodes in the cluster based on a . I'm seeing events fired with reason for the daemonset pods on nodes that do not fit the selector. What you expected to happen: These events should never fire because they do not meet the node selectors in the pod spec. How to reproduce it (as minimally and precisely as possible): Create a cluster with different sized nodes. E.g. smaller masters than workers. Then deploy the daemonset only to the workers. You will see events triggered for the master nodes that don't meet the requirements. Anything else we need to know:
DaemonSet controller will run predicates to check if node should run daemon pod. In the progress of predicates, it will check if pod fits resources first before other predicates such as PodSelectorMatches. /cc
I think this bug appeared when critical pods were introduced and order of checking predicates changed. The event is useless for daemonsets in current situation :/ I'm not sure if there is a clean way to fix it.
I feel like a clean solution would be to look at the predicate reasons twice. The first time you look at the reasons and keep track if any are not intentional. If all of the reasons are intentional then skip checking the reasons.
actually just changing the order of checks in GeneralPredicates may just work. I'm testing the fix now.
Ok, GeneralPredicates returns all reasons. Error that pod doesn't match the node is also returned but because it's "intentional" there is no event for it.

The event "Node didn't have enough resource" should be sent only when there are no other "intentional" reasons.
Yes, I think maybe we need to check reason list twice: check is in tail of predicate list.
/cc
any PR for this? If not, I can help
I will have some time to work on it next week. If you have a spare time you can create a PR.
/assign
Change:
violatingVictims, nonViolatingVictims := filterPodsWithPDBViolation(potentialVictims.Items, pdbs) reprievePod := func(p *v1.Pod) bool { addPod(p) <del> fits, _, _ := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, nil, queue, false) </del> <ins> fits, _, _ := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, nil, queue, false, nil) </ins> if !fits { removePod(p) victims = append(victims, p)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc
Change:
testInfo := getTestInfo(spec) if testInfo != nil { testInfos = append(testInfos, testInfo) <del> } if err := validateTestName(testInfo.CodeName); err != nil { log.Fatal(err) </del> <ins> if err := validateTestName(testInfo.CodeName); err != nil { log.Fatal(err) } </ins> } } }

Discussion:
script result to a nil pointer dereference exception e.g. show the below exception, no exception found when the script got called. a test binary (which are a little behind the master) the spec on the latest master branch, the spec to yaml: No response <details</details<details</detailsN/A <details</details<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
/assign
/sig apps /area conformance
Change:
setEntrypointAndCommand(container, &dockerOpts) <ins> glog.V(3).Infof("Container %v/%v/%v: setting entrypoint "%v" and command "%v"", pod.Namespace, pod.Name, container.Name, dockerOpts.Config.Entrypoint, dockerOpts.Config.Cmd) </ins> dockerContainer, err := r.Client.CreateContainer(dockerOpts) if err != nil { if ref != nil {

Discussion:
Forked from downward, this test has been failing since go/k8s-test/kubernetes-e2e-gce/4042, which lines up well with . Assigning to to fix, though a revert may be in order soon (we've had too much noise).
The issue is that I didn't change the networking e2e to set 'Args' instead of 'Command'.
Clients shouldn't be using the internal representation.
hmmmm ... is this really fixed? not working for me atm.
What behaviors are you seeing?
This is a recent run of our Jenkins server:
Re-closing (that was a success I pasted).
This might be the test failure you mentioned over hangout. The detail information can be found at: The issue is fixed this morning. Thanks!
Change:
// IsUnexpectedObjectError determines if err is due to an unexpected object from the master. // It supports wrapped errors and returns false when the error is nil. func IsUnexpectedObjectError(err error) bool { <del> uoe := &UnexpectedObjectError{} return err != nil && errors.As(err, &uoe) </del> <ins> uoe, ok := err.(*UnexpectedObjectError) return err != nil && (ok || errors.As(err, &uoe)) </ins> } // SuggestsClientDelay returns true if this error suggests a client delay as well as the

Discussion:
I have a controller that creates objects. It uses to notice when create fails due to a deleting namespace. This check was working well until I moved it away from each call. In some cases, the error is wrapped using causing the function to always return false. I expected to work on both wrapped and unwrapped errors, like the functions do. This short program shows the issue: I am able to work around it by first calling . This type assertion should be replaced with a call to : /sig api-machinery v1.22.5, but I also see the affected code in master. <details</detailsn/a n/a k3s n/a n/a
/cc /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Change:
ExpectedListenerAddress: "127.0.0.1", }, { <del> Hostname:                "[::1]", </del> <ins> Hostname:                "::1", </ins> Protocol:                "tcp6", ShouldRaiseError:        false, ExpectedListenerAddress: "::1", }, { <del> Hostname:         "[::1]", </del> <ins> Hostname:         "::1", </ins> Protocol:         "tcp4", ShouldRaiseError: true, },

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT What happened: When using IPv6 addresses, the kubelet passes the address to client-go, which does not correctly format the address for use in API requests. For example: Failed to list v1.Pod: Get https://2001:129::136:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dnode136&resourceVersi on=0: dial tcp: too many colons in address 2001:129::136:6443 What you expected to happen: The URI should have https://[2001:129::136]:6443, so that SplitHostPort() will correctly be able to separate the host and port components. How to reproduce it (as minimally and precisely as possible): Create cluster using IPv6 address (e.g. kubeadm init --apiserver-advertise-address=2001:129::136). When the kubelet starts up, it'll log this error. Anything else we need to know?: This is being handled as part of effort to support IPv6 in Kubernetes. Was found by a co-worker, I'll work on a commit to fix. Environment: Kubernetes version (use ): Using latest, via KubeAdm Cloud provider or hardware configuration*: bare-metal OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-81-generic Install tools: Using KubeAdm Others:
/area client-libraries /area kubelet /area ipv6
/assign
The point of failure is here: SplitHostPort will accept IPv4 and IPv6 addresses, but the latter must have square brackets around the IPv6 address.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig api-machinery because client-go
Should we open this on the repository?

I see in the client-go repo read me that it states: Does that confirm that I should do a PR here?
One thing that I was wonder, was whether or not the hostname/address provided in the call to getListener, has been validated. If so, and it can only be a hostname, IPv4, or IPv6 address as a string, we could just check if there is a ":" in the name to determine IPv6. Otherwise, I could use net.ParseIP(), and net.To4() to determine if IPv6. I'll start working with the latter assumption, but please let me know, if the former could be used.
Also, I'm making the assumption that we'd want to make client-go be able to handle IPv6 addresses, rather than having each user of client-go (e.g. kubelet) from ensuring that the IP address is of the right form. IOW, have client-go add the needed [] around IPv6 addresses, rather than have kubelet do that. My thought is that there may be cases where we want just the IP address and not the modified IP. Does that sound OK?
Change:
addRunFlags(cmd, o) cmdutil.AddApplyAnnotationFlags(cmd) cmdutil.AddPodRunningTimeoutFlag(cmd, defaultPodAttachTimeout) <ins> // Deprecate the cascade flag. If set, it has no practical effect since the created pod has no dependents. // TODO: Remove the cascade flag from the run command in kubectl 1.29 cmd.Flags().MarkDeprecated("cascade", "because it is not relevant for this command. It will be removed in version 1.29.") // Deprecate and hide unused flags. // These flags are being added to the run command by DeleteFlags to support pod deletion after attach, // but they are not used if set, so they effectively do nothing. // TODO: Remove these flags from the run command in kubectl 1.29 cmd.Flags().MarkDeprecated("filename", "because it is not used by this command. It will be removed in version 1.29.") cmd.Flags().MarkDeprecated("force", "because it is not used by this command. It will be removed in version 1.29.") cmd.Flags().MarkDeprecated("grace-period", "because it is not used by this command. It will be removed in version 1.29.") cmd.Flags().MarkDeprecated("kustomize", "because it is not used by this command. It will be removed in version 1.29.") cmd.Flags().MarkDeprecated("recursive", "because it is not used by this command. It will be removed in version 1.29.") cmd.Flags().MarkDeprecated("timeout", "because it is not used by this command. It will be removed in version 1.29.") cmd.Flags().MarkDeprecated("wait", "because it is not used by this command. It will be removed in version 1.29.") </ins> return cmd }

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Change:
} func (m *effectiveVersion) BinaryVersion() *version.Version { <ins> if m.useDefaultBuildBinaryVersion.Load() { return defaultBuildBinaryVersion() } </ins> return m.binaryVersion.Load() }

Discussion:
Starting in 1.31, --version no longer works to modify the build ID of the running components. /kind regression /priority important-soon Running kube-apiserver v1.31.0 with ignores the modified build ID and reports In 1.28, 1.29, and 1.30 (since ), this allowed modifying the build ID of the running server. /sig api-machinery /assign Run v1.31.0 with No response 31.0 n/a <details</details<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
I think this broke in DefaultBuildEffectiveVersion() is grabbed in NewAPIServerCommand(), before the flag is parsed, so the GitVersion propagated into the snapshot effectiveVersion doesn't honor
cc
Change:
} client := fake.NewSimpleClientset(csr) <del> informerFactory := informers.NewSharedInformerFactory(client, controller.NoResyncPeriodFunc()) </del> <ins> informerFactory := informers.NewSharedInformerFactory(fake.NewSimpleClientset(csr), controller.NoResyncPeriodFunc()) </ins> handler := func(csr *certificates.CertificateSigningRequest) error { csr.Status.Conditions = append(csr.Status.Conditions, certificates.CertificateSigningRequestCondition{

Discussion:
Seen in happy to send a fix but didn't know if this might have been address with your current refactors. Output:
This looks new. I'd happily review a fix. Thanks.
Dupe of
Change:
return nil, errors.New("unable to open query through DLL call") } <del> ret = win_pdh.PdhValidatePath(counter) if ret != win_pdh.ERROR_SUCCESS { return nil, fmt.Errorf("unable to valid path to counter. Error code is %x", ret) } </del> ret = win_pdh.PdhAddEnglishCounter(queryHandle, counter, 0, &counterHandle) if ret != win_pdh.ERROR_SUCCESS { return nil, fmt.Errorf("unable to add process counter. Error code is %x", ret)

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: Im trying to setup node on window server 2019, but kubelet fails with error "F0217 17:36:06. 3200 ] failed to run Kubelet: unable to valid path to counter. Error code is " What you expected to happen: kubelet runs successfully How to reproduce it (as minimally and precisely as possible): install windows server 2019 with ru_RU locale run kubelet Anything else we need to know?: Problem appearances on any non English windows os. Its caused by hard-coded performance counter names in PdhValidatePath expects localized counter name. Environment: Kubernetes version (use ): 13.3 Cloud provider or hardware configuration: n/a OS (e.g. from /etc/os-release): windows server 2019 Kernel (e.g. ): n/a Install tools: n/a Others: n/a
/sig windows
Same problem with German Windows. We even tried replacing the english counters with the german equivalents - no success.
Hey, this is still an issue in version 1.15.0. Will this ever be fixed? Are there any workarounds available?
Hi to fix error you need to comment out lines 53-56 in and rebuild. I have tested it on 1.13 and after commenting out that lines everything works.
It's been over 6 months since this issue was opened. Is there a PR or anything for this yet? I'm hitting this error in Windows Server 2019 as well.
/assign
opened an issue the same day as my comment above. Note: I was using the English version.
I have reproduced this problem in the French environment, but the English environment is normal, has your windows installed other languages? I looked at the example of npd on Microsoft's official website and found that it may be a problem with kubernetes code. I am following up with the community on slack. The microsoft offical example is : They dont call this function
It seems like that removing does not fix this issue.

also returns the same error Error logs in 1.18.2:
very interesting, can you please open a new issue and investigate our options if you can?
I remember the last time I modified it and passed the test on the French and Russian Windows operating systems, can you describe your environment information in detail?
Change:
value: 100m - name: MEMORY_REQUEST value: 200Mi <ins> - name: CPU_LIMIT value: 300m </ins> - name: MEMORY_LIMIT <del> value: 300Mi </del> <ins> value: 500Mi </ins>

Discussion:
Currently CPU consumption is not capped, which can be problematic in some setups
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 This is still relevant. If k8s back plane cluster components on the nodes are not resource constrained, user workload deployed to those nodes have zero guarantees and can make no assumptions regarding available resources while they are executing. Mick's ticket is definitely something that warrants fixing, since we've been affected by this precise limitation ourselves in production.
GitHub didn't allow me to assign the following users: frapposelli. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign 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:
if err := g.snapshot(); err != nil { return result, err } <ins> trace.Step("Snapshoting scheduler cache and node infos done") </ins> <del> trace.Step("Basic checks done") </del> startPredicateEvalTime := time.Now() filteredNodes, failedPredicateMap, filteredNodesStatuses, err := g.findNodesThatFit(state, pod) if err != nil { return result, err } <ins> trace.Step("Computing predicates done") </ins> // Run "postfilter" plugins. postfilterStatus := g.framework.RunPostFilterPlugins(state, pod, filteredNodes, filteredNodesStatuses)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We have enabled in genericscheduler. However, the steps being traced seem outdated. In particular, the "snapshot" is expensive and should be traced. Other steps can be traced as well wherever appropriate, e.g., PreFilter. Why is this needed: Improve granularity of tracing. /sig scheduling
/assign
Change:
- name: 50-network-config.conf content: | [Service] <ins> Environment=ETCDCTL_PEERS=http://<master-private-ip>:4001 </ins> ExecStartPre=/bin/bash -c "until curl http://<master-private-ip>:4001/v2/machines; do sleep 2; done" ExecStartPre=/usr/bin/etcdctl set /coreos.com/network/config '{"Network":"10.244.0.0/16", "Backend": {"Type": "vxlan"}}' - name: docker.service

Discussion:
Tried to run through this guide: On VMware, there is no eth1, so the flannel configuration dies. Once you get past that, there is also an issue where etcdctl doesn't properly update the flannel network settings because the etcd server isn't set to the master.