jiebi/CodeConvo huggingface dataset:
Change:
podName := "busybox-scheduling-" + string(uuid.NewUUID()) /* <del> Release : v1.9 </del> <ins> Release : v1.13 </ins> Testname: Kubelet, log output, default Description: By default the stdout and stderr from the process being executed in a pod MUST be sent to the pod's logs. */ <del> It("should print the output to logs [NodeConformance]", func() { </del> <ins> framework.ConformanceIt("should print the output to logs [NodeConformance]", func() { </ins> podClient.CreateSync(&v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: podName,

Discussion:
What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. To my eyes they may meet the criteria for conformance. There's definitely nothing about them that is node specific. They should be running as part of our regular CI, and they should probably be running as presubmits. Porting them to test/e2e/common would cause this to happen. /kind cleanup /sig node /area test /assign
GitHub didn't allow me to assign the following users: mkurylec. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : What happened: These tests are errantly listed as (ref: ) but aren't actually run as part of Conformance. They need to be moved to test/e2e/common to be included. /sig node /area test /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:
Program            cel.Program Error              *apiservercel.Error ExpressionAccessor ExpressionAccessor <ins> OutputType         *cel.Type </ins> } // Compiler provides a CEL expression compiler configured with the desired admission related CEL variables and

Discussion:
Variables field is to ValidatingAdmissionPolicy in 1.28. Currently the usage of variables would expect a operator associated. e.g. (thanks to Mariam Fahmy for raising the issue) Above will fail with error: Meanwhile the will pass. The reason is when variables be evaluated to non dyn type(like bool or string), it will require special handling(like casting) since we use dyn type everywhere. It might confuse user.
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
/triage accepted /sig api-machinery /cc
Tests I'd expect to see verify this behavior: PASS: A variable is of type bool, an expression returns the variable PASS: A variable is of type string, a messageExpression returns the variable PASS: A variable is of type dyn, at runtime the dyn is a bool, an expression returns the variable PASS: A variable is of typedyn, at runtime the dyn is a string, an messageExpression returns the variable PASS: A expression is of type dyn, at runtime the dyn is of type bool PASS: A messageExpression is of type dyn, at runtime the dyn is of type string COMPILE ERROR: A variable is of type bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should resultsin a compile error COMPILE ERROR: A variable is of type string, an expression tries to perform a non-string (e.g. less than) operation on the variable, this should result in a compile error RUNTIME ERROR: A variable is of type dyn, at runtime the dyn is a bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should result in a runtime error I'd also expect to see some cases covering variables of other types (maps, lists, duration, quantity, ...) to make sure we're over-fitting for bool and string.
/retitle ValidatingAdmissionPolicy: variable expression type not recognized as return type in expression that evaluates the variable
/assign
Change:
return *node, nil } <ins> func (nm *NodeManager) getNodes() map[string]*v1.Node { nm.registeredNodesLock.RLock() defer nm.registeredNodesLock.RUnlock() registeredNodes := make(map[string]*v1.Node, len(nm.registeredNodes)) for nodeName, node := range nm.registeredNodes { registeredNodes[nodeName] = node } return registeredNodes } </ins> func (nm *NodeManager) addNode(node *v1.Node) { nm.registeredNodesLock.Lock() nm.registeredNodes[node.ObjectMeta.Name] = node

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: Quote I took goroutine dump of controller-managers that were stuck in volume provisioning and I think we have a deadlock in code: I think we have a problem introduced when we merged - and what is happening is, when in is called it acquires a lock on , but same function ends up calling which acquires another lock on object . Now the problem is, function gets called in a loop and it will try to acquire lock for each node it processes and hence two operations could result in deadlock. This results into inability to provision a with a default StorageClass. The volume does not get to call the API endpoint, just hangs after call, which is clear in the goroutine dump. What you expected to happen: 1) Provision a from successfully. 2) Don't be blocked by credentials secret change. How to reproduce it (as minimally and precisely as possible): 1) Provision a vSphere cluster with credentials secret set 2) Create volume 3) Wait... Anything else we need to know?: Environment: Kubernetes version (use ): v1.19.0-rc.2+-dirty Cloud provider or hardware configuration: vSphere OS (e.g: ): Linux Kernel (e.g. ): GNU/Linux Install tools: openshift-install (kubeadm) Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/vmware
This should be a blocker bug for 1.19 at least as far as vsphere cloudprovider integration is concerned, because it breaks cloudprovider integration/volume provisioning. cc
cc:
/milestone v1.19
Something makes me think this issue existed before, and just escalated to a larger scope after adding informers, demanding refresh for all objects. This is used within plugin in and it is mounting the volume if it is required, calling - it is locking on all the nodes at once. If the pod was just restarted (say just changed, or the health probes demanded a restart), it would process all existing at the same time as trying to mount/create the volume.

And both threads will clang on the same lock, as the would probably not be populated at that moment, so will go the path of - same which is used in . So we get lost volume data, pending etc... And the links I'm sharing are from Kubernetes, where issues with similar footprint randomly arose.
Change:
} r := &Reflector{ <del> name:                   "test-reflector", listerWatcher:          lw, store:                  NewFIFO(MetaNamespaceKeyFunc), initConnBackoffManager: bm, clock:                  clock, watchErrorHandler:      WatchErrorHandler(DefaultWatchErrorHandler), </del> <ins> name:              "test-reflector", listerWatcher:     lw, store:             NewFIFO(MetaNamespaceKeyFunc), backoffManager:    bm, clock:             clock, watchErrorHandler: WatchErrorHandler(DefaultWatchErrorHandler), </ins> } stopCh := make(chan struct{})

Discussion:
Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted
Change:
counts: map[string]int64{ "events.foo.bar": 799, }, <del> seatsExpected: 5, </del> <ins> seatsExpected: 8, }, { name:       "request verb is list, resource version match is Exact", requestURI: "http://server/apis/foo.bar/v1/events?resourceVersion=foo&resourceVersionMatch=Exact&limit=399", requestInfo: &apirequest.RequestInfo{ Verb:     "list", APIGroup: "foo.bar", Resource: "events", }, counts: map[string]int64{ "events.foo.bar": 699, }, seatsExpected: 8, </ins> }, { name:       "request verb is list, resource version match is NotOlderThan, limit not specified",

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 --I noticed that does not make sense to me. Looking at how LIST requests are served (which is NOT easy, there is so much dependency injection), I concluded that the worst case number of objects touched in the apiserver equals the pagination limit only if all of the following are true. The LIST request is served from etcd rather than the watch cache. The pagination FeatureGate is enabled. The request has a specified limit and it is no greater than the number of objects in etcd (restricted by namespace if relevant). The request does not have a label selector or field selector. I expected the list work estimator to use the pagination limit only under the conditions listed above. 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:
I commented on the PR.
Thank you both Mike and Wojciech! /triage accepted
Change:
# Force delete a pod on a dead node kubectl delete pod foo --grace-period=0 --force <del> # Delete a pod with UID 1234-56-7890-234234-456456. kubectl delete pod 1234-56-7890-234234-456456 </del> # Delete all pods kubectl delete pods --all`) )

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.): delete pod delete pod uid Is this a BUG REPORT or FEATURE REQUEST? (choose one): maybe a bug report: the "kubectl delete pod [uid]" doesn't work. Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-10T00:30:53Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-10T00:26:06Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} What happened: First, use "kubectl get pod [podname] -o yaml" to get the details of the pod, obtaining the uid under Then use "kubectl delete pod [uid]" to delete the pod, but failed finally. the info showed like this: Error from server (NotFound): pods "-dbf8-11e6-818c-" not found. Did I get the wrong uid? What you expected to happen: It should delete pod successfully just like using podname. How to reproduce it (as minimally and precisely as possible): just do like mentioned in "What happened"
I don't think we provide pod deletion by UID... /cc
If you type "kubectl delete pod -h", there is a piece of specifications describing like this: "# Delete a pod with UID 1234-56-7890--. kubectl delete pod 1234-56-7890--" So is this a mistake?
I don't know. It could be a feature that I am not aware of. Folks from the will know better.

kubectl delete pod 1234-56-7890-- It seems this help message exists even in v1.0. Do we support this before?
AFAIK, apiserver doesn't support operations using the UID as the key. Unless kubectl implement additional logic to map the UID to a (name, namespace) tuple, it'd not be able to do that.
Delete by UID is no longer supported, this is an issue with the help text that needs to be adjusted.
Change:
}, ExpectedTaints: []*v1.Taint{notReadyTaint}, }, <ins> { Name: "Ready is unknown", Node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Name:              "node0", CreationTimestamp: metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), Labels: map[string]string{ kubeletapis.LabelZoneRegion:        "region1", kubeletapis.LabelZoneFailureDomain: "zone1", }, }, Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ { Type:               v1.NodeReady, Status:             v1.ConditionUnknown, LastHeartbeatTime:  metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), LastTransitionTime: metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC), }, }, }, }, ExpectedTaints: []*v1.Taint{unreachableTaint}, }, </ins> } for _, test := range tests {

Discussion:
In autoscaling tests, we verify that when a node suddenly disappears from the cluster, Cluster Autoscaler will add another one to replace it. With TaintNodesByCondition (enabled by default in ), this is now failing: https://k8s- Every time a node disappears, a subset of pods become NodeLost and aren't rescheduled on a new node. /cc /sig node
I can work on this.
just got merged. Let's check result of autoscaling testings tomorrow: https://k8s-
latest autoscaling testing is green. I think we can close this issue.
Thanks for fixing this!
Change:
Subsystem:         KubeletSubsystem, Name:              AssignedConfigKey, Help:              "The node's understanding of intended config. The count is always 1.", <del> DeprecatedVersion: "1.23.0", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, []string{ConfigSourceLabelKey, ConfigUIDLabelKey, ConfigResourceVersionLabelKey, KubeletConfigKeyLabelKey},

Discussion:
This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
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
/cc
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]:
/remove-lifecycle stale
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon
Change:
framework.ExpectEqual(endpointSubsetOnePorts.Port, int32(8080), "failed to patch Endpoint") ginkgo.By("deleting the Endpoint by Collection") <del> err = f.ClientSet.CoreV1().Endpoints(ns).DeleteCollection(context.TODO(), metav1.DeleteOptions{}, metav1.ListOptions{LabelSelector: "testendpoint-static=true"}) </del> <ins> err = f.ClientSet.CoreV1().Endpoints(testNamespaceName).DeleteCollection(context.TODO(), metav1.DeleteOptions{}, metav1.ListOptions{LabelSelector: "test-endpoint-static=true"}) </ins> framework.ExpectNoError(err, "failed to delete Endpoint by Collection") ginkgo.By("waiting for Endpoint deletion") <del> for watchEvent := range endpointWatchChan { if watchEvent.Type == "DELETED" { break </del> <ins> ctx, cancel = context.WithTimeout(context.Background(), 30*time.Second) defer cancel() _, err = watchtools.Until(ctx, endpoints.ResourceVersion, w, func(event watch.Event) (bool, error) { switch event.Type { case watch.Deleted: if endpoints, ok := event.Object.(*v1.Endpoints); ok { found := endpoints.ObjectMeta.Name == endpoints.Name && endpoints.Labels["test-endpoint-static"] == "true" return found, nil } default: framework.Logf("observed event type %v", event.Type) </ins> } <del> } </del> <ins> return false, nil }) framework.ExpectNoError(err, "failed to see %v event", watch.Deleted) ginkgo.By("fetching the Endpoint") _, err = f.ClientSet.CoreV1().Endpoints(testNamespaceName).Get(context.TODO(), testEndpointName, metav1.GetOptions{}) framework.ExpectError(err, "should not be able to fetch Endpoint") </ins> }) })

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: This issue is created to allow edit by /wip /hold This issue proposes the writing of a new test for the API endponts , , , with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this APIsnoop query, there are still some remaining Endpoints endpoints which are untested. a Service in a namespace all Endpoints in all Namespaces find the created Service(1) /update the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) the Namespaced Endpoint for the Service(1) Namespaced Endpoint(1) via a Collection with a LabelSelector Discover useragents: If a test with these calls gets merged, Conformance coverage will go up by 4 points* /sig testing /sig architecture /area conformance
/reopen Wait for Promotion PR to Merge.
Reopened this issue. <detailsIn response to : /reopen Wait for Promotion PR to Merge. 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:
{kubeNodePortSetTCP, string(KubeNodePortChain), string(KubeMarkMasqChain), "dst", utilipset.ProtocolTCP}, {kubeNodePortLocalSetUDP, string(KubeNodePortChain), "RETURN", "dst", utilipset.ProtocolUDP}, {kubeNodePortSetUDP, string(KubeNodePortChain), string(KubeMarkMasqChain), "dst", utilipset.ProtocolUDP}, <del> {kubeNodePortSetSCTP, string(KubeNodePortChain), string(KubeMarkMasqChain), "dst,dst", utilipset.ProtocolSCTP}, </del> {kubeNodePortLocalSetSCTP, string(KubeNodePortChain), "RETURN", "dst,dst", utilipset.ProtocolSCTP}, <ins> {kubeNodePortSetSCTP, string(KubeNodePortChain), string(KubeMarkMasqChain), "dst,dst", utilipset.ProtocolSCTP}, </ins> } // In IPVS proxy mode, the following flags need to be set

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 --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.0 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:
/sig network /assign
/triage accepted
Change:
Do() found := 0 <del> r.IgnoreErrors(errors.IsNotFound).Visit(func(r *resource.Info) error { </del> <ins> err := r.IgnoreErrors(errors.IsNotFound).Visit(func(r *resource.Info) error { </ins> found++ if err := resource.NewHelper(r.Client, r.Mapping).Delete(r.Namespace, r.Name); err != nil { return err

Discussion:
We should support multiple objects on the command line, but, failing that, some kind of error message would be useful. /cc
Fixing, just fixed the equiv in create
Change:
v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/types" <ins> schedulerapi "k8s.io/kubernetes/pkg/scheduler/api" </ins> internalcache "k8s.io/kubernetes/pkg/scheduler/internal/cache" )

Discussion:
What would you like to be : a default normalize score function in the scheduling framework. the plugin and log an error when the normalizing phase returns an invalid range of scores. Why is this needed: Per discussion in , we should enforce the range of score returned by the scoring plugin. /sig scheduling /priority important-soon /assign
Change:
expectedToFail: false, config:         goodConflictPlugins2, }, <ins> "bad-plugins-config": { expectedToFail: true, config:         deprecatedPluginsConfig, errorString:    "profiles[0].pluginConfig[1]: Invalid value: "NodeResourcesLeastAllocated": was removed in version "kubescheduler.config.k8s.io/v1beta2" (KubeSchedulerConfiguration is version "kubescheduler.config.k8s.io/v1beta2")", }, </ins> } for name, scenario := range scenarios {

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 --Have a legacy scheduler config, upgrade to v1beta2 since we are at v1beta2 now, scheduler failed to start with some unreadable raw data, accurate and readable error message. config scheduler config like what has been said above. Kubernetes version (use ): latest. Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig scheduling /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