jiebi/CodeConvo huggingface dataset:
Code change:
// Test that a handler associated with an APIService gets pinged after the // APIService has been marked as dirty func TestDirty(t *testing.T) { <del> pinged := false </del> <ins> var pinged atomic.Bool service := discoveryendpoint.NewResourceManager() aggregatedResourceManager := discoveryendpoint.NewResourceManager() aggregatedManager := newDiscoveryManager(aggregatedResourceManager) aggregatedManager.AddAPIService(&apiregistrationv1.APIService{ ObjectMeta: metav1.ObjectMeta{ Name: "v1.stable.example.com", }, Spec: apiregistrationv1.APIServiceSpec{ Group:   "stable.example.com", Version: "v1", Service: &apiregistrationv1.ServiceReference{ Name: "test-service", }, }, }, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { pinged.Store(true) service.ServeHTTP(w, r) })) testCtx, cancel := context.WithCancel(context.Background()) defer cancel() go aggregatedManager.Run(testCtx.Done()) require.True(t, waitForQueueComplete(testCtx.Done(), aggregatedManager)) // immediately check for ping, since Run() should block for local services if !pinged.Load() { t.Errorf("service handler never pinged") } } // Shows that waitForQueueComplete also waits for syncing to // complete by artificially making the sync handler take a long time func TestWaitForSync(t *testing.T) { pinged := atomic.Bool{} </ins> service := discoveryendpoint.NewResourceManager() aggregatedResourceManager := discoveryendpoint.NewResourceManager()

Related discussion:
text: pull-kubernetes-unit sometimes fails with data race. TestDirty I think the test was 3 months ago with the flaking state. There are two issues. First, updating and reading a bool-type variable is not thread-safe. and there is also another problem checking the state before completely syncing it. No response /sig api-machinery
/assign
/triage accepted
Code change:
### Setup <del> By default, the Vagrant setup will create a single kubernetes-master and 3 kubernetes-minions.  You can control the number of minions that are instantiated via an environment variable on your host machine.  If you plan to work with replicas, we strongly encourage you to work with enough minions to satisfy your largest intended replica size.  If you do not plan to work with replicas, you can save some system resources by running with a single minion. ``` export KUBERNETES_NUM_MINIONS=3 ``` To start your local cluster, open a terminal window and run: </del> <ins> By default, the Vagrant setup will create a single kubernetes-master and 3 kubernetes-minions. Each VM will take 512 MB, so make sure you have at least 2 GB of free memory. To start your local cluster, open a shell and run: </ins> ``` cd kubernetes

Related discussion:
text: Which jobs are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /priority important-soon /cc /cc /milestone v1.18 /sig release
/assign
This is failing because a 1.18 release for CRI tools doesn't exist yet. I can tweak the test job arguments to skip this later.
(As a note, this job is important, but not ) /remove-priority critical-urgent /priority important-soon
Do we need to remove the job from dashboard?
-- No. I'll work on fixing the job later today.
I've started to investigate, but I haven't yet reproduced the new error locally: This is likely related to a recent refactor of the package that handles interpreting deb/rpm package versions. As is not currently in use, I'm moving this to the milestone. /milestone v1.19
the version issue is fixed via The test is now failing because it tries to download cri-tools v1.18.0: which I think is related to this code part:
Updating testgrid link here: Any updates here /retitle [Flaky Test] build-packages-debs (ci-release-build-packages-debs) /kind flaky-test
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Updating testgrid link here: /kind flaky-test 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
/kind flake
I was assuming that is working on this issue. I can jump in if you want and do not find the time to work on it. :)
/assign /unassign Sascha -- Can you take this? I thought I was going to have time to look at this, but it's been a while.
Sure, the reason for the failing test seems to have changed, I'm on it.
Fix is incoming in
Code change:
} return buf.String(), nil } <ins> type conditionalTransport struct { oauthTransport *oauth2.Transport } func (t *conditionalTransport) RoundTrip(req *http.Request) (*http.Response, error) { if len(req.Header.Get("Authorization")) != 0 { return t.oauthTransport.Base.RoundTrip(req) } return t.oauthTransport.RoundTrip(req) } </ins>

Related discussion:
text: What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubectl token BUG REPORT Kubernetes version (use ): kubectl version Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-03-28T16:36:33Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-04-03T20:33:27Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): macOS Sierra 10.12.4 Kernel (e.g. ): uname -a Darwin jacobsimpson- 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASEX8664 x8664 Install tools: Others: What happened: I set up a second user, then I use to authenticate as the second user. The parameter is ignored and the authentication token from the file is used instead, so I'm authenticated as the user configured in the config file, not as the user set on the command line parameters. I further verified this by commenting out the section in the config file with the authentication token and then the parameter starts to work as expected. What you expected to happen: I expect the command line parameters, when present, to override the config file settings. How to reproduce it (as minimally and precisely as possible): At this point, the error message should be indicating kubectl tried to authenticate with the account. Something like this: Now edit , search for the section for your cluster and comment out the whole section for the test cluster. Now it should be possible to run these two commands. The one using the user_token will fail with the error message indicating the user name.
Code change:
} return buf.String(), nil } <ins> type conditionalTransport struct { oauthTransport *oauth2.Transport } func (t *conditionalTransport) RoundTrip(req *http.Request) (*http.Response, error) { if len(req.Header.Get("Authorization")) != 0 { return t.oauthTransport.Base.RoundTrip(req) } return t.oauthTransport.RoundTrip(req) } </ins>

Related discussion:
text: Anything else we need to know:
The token arg on the command line overrides the bearer token field in the config file, but I'm not sure the precedence of the token arg and the auth provider in the config file. cc
All auth providers currently override the "Authorization" header even if it's set. Should be an easy-ish check to add. Long term we probably want to have the auth provider stop wrapping the transport and just act like a token source , that way some central code would handle the HTTP headers and we wouldn't have to enforce this on a per plugin basis.
So the tokens from command line should be used, right? if so I can send a pr to fix this.
the client auth plugins shouldn't override the "Authorization" headers. Yeah feel free to send a PR.
Is this a regression or why 1.7?
bug is pretty self contained in the GCP client auth plugin and the fix is short Not strictly a regression, but something that popped up over this cycle as a bug impacting users. Is that reason enough to get it in during the 1.7 freeze?
Code change:
} func (cm *containerManagerImpl) GetAllocateResourcesPodAdmitHandler() lifecycle.PodAdmitHandler { <del> return nil </del> <ins> return &noopWindowsResourceAllocator{} </ins> } func (cm *containerManagerImpl) UpdateAllocatedDevices() {

Related discussion:
text: <!-- 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: Pods will not start on Windows nodes, even though nodes are ready and pods are scheduled to nodes. Kubelet logs are filled with this: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Build K8s from master, create any pod on Windows node. Anything else we need to know?: I strongly believe this commit is responsible: What happened is that now, with the commit mentioned above, a nil podAdmitHandler is registered, that when called will result in a panic. More specifically here: For Windows, returns : Environment: All K8s built from master. This affects all sig-windows master tests.
/sig windows
/sig node
/reopen Is this resolved? The jobs still failing because of this. ref Can you check?
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
The issue is fixed, you can look here: . I don't know what's happening with gce tests, but all other windows tests ( based on aks ) are working. PS: Maybe I should add aks job to master release informing as well :)
Since this affected the Kubelet starting, I think we can safely close this issue based on just aks test results.
Thanks, /close
Closing this issue. <detailsIn response to : Thanks, /close 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
Thanks
can you take a look at the Windows GCE test passes? It looks like they are still unhealthy and there are a few issues being tracked by the release team and
Code change:
glog.V(4).Infof("EnsureLoadBalancer(%v, %v, %v, %v, %v, %v, %v)", clusterName, apiService.Namespace, apiService.Name, apiService.Spec.LoadBalancerIP, apiService.Spec.Ports, hosts, apiService.Annotations) ports := apiService.Spec.Ports <del> if len(ports) > 1 { return nil, fmt.Errorf("multiple ports are not yet supported in openstack load balancers") } else if len(ports) == 0 { </del> <ins> if len(ports) == 0 { </ins> return nil, fmt.Errorf("no ports provided to openstack load balancer") } <del> // The service controller verified all the protocols match on the ports, just check and use the first one </del> <ins> // Check for TCP protocol on each port </ins> // TODO: Convert all error messages to use an event recorder <del> if ports[0].Protocol != api.ProtocolTCP { return nil, fmt.Errorf("Only TCP LoadBalancer is supported for openstack load balancers") </del> <ins> for _, port := range ports { if port.Protocol != api.ProtocolTCP { return nil, fmt.Errorf("Only TCP LoadBalancer is supported for openstack load balancers") } </ins> } affinity := api.ServiceAffinityNone //apiService.Spec.SessionAffinity

Related discussion:
text: LBaaS implementation (v1 or v2) will not support services that require to load balancer more than one port.
Fixed for LBaaS v2 by I suspect LBaaS v1 can't support multiple ports (not sure if reusing the VIP across multiple loadbalancers is a universally supported thing). I also believe LBaaS v1 is also mostly gone in favour of v2 in deployments so trying to address this in v1 is extremely low priority unless someone steps forward to ask for it. So: I think we can close this bug now, but I lack the powers to do that directly.
thank you for the update.
Code change:
} pod.Spec.Priority = &priority <del> if utilfeature.DefaultFeatureGate.Enabled(features.NonPreemptingPriority) { </del> <ins> if p.nonPreemptingPriority { </ins> var corePolicy core.PreemptionPolicy if preemptionPolicy != nil { corePolicy = core.PreemptionPolicy(*preemptionPolicy)

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Following the documentation at the , I tried enabling quota for a namespace other than but I was still not able to create a pod with priorityClass in my namespace with following error: Error from server (Forbidden): error when creating "": pods "memory-demo" is forbidden: pods with system-cluster-critical priorityClass is not permitted in my-namespace namespace What you expected to happen: Expected pod to be created with namespace where I allowed quota. I can see that both ResourceQuota and Priority Plugins are enabled from logs. I0408 17:15:08. ] Loaded 8 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition,Priority,DefaultTolerationSeconds,DefaultStorageClass,MutatingAdmissionWebhook. I0408 17:15:08. ] Loaded 6 validating admission controller(s) successfully in the following order: LimitRanger,ServiceAccount,Priority,PersistentVolumeClaimResize,ValidatingAdmissionWebhook,ResourceQuota. How to reproduce it (as minimally and precisely as possible): Follow the steps at Anything else we need to know?: I think, the issue is with priorityPlugin where we are rejecting instead of letting resourceQuota plugin to handle the admission when is enabled. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig scheduling /cc
Same happens to me. Correction, it does not allow to use the default permissions outside of kube-system
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
See also:
/remove-lifecycle stale
/assign Per offline discussion with
Same issue here.
Code change:
} pod.Spec.Priority = &priority <del> if utilfeature.DefaultFeatureGate.Enabled(features.NonPreemptingPriority) { </del> <ins> if p.nonPreemptingPriority { </ins> var corePolicy core.PreemptionPolicy if preemptionPolicy != nil { corePolicy = core.PreemptionPolicy(*preemptionPolicy)

Related discussion:
text: We are using namespaces other than kube-system for system pods as it is getting too crowded, therefore we would like to run cluster-node-critical pods in other namespaces.
Waiting for this to be available myself. No reason my Node Exporter dataset has to run in the namespace instead of my namespace.
Code change:
master_ip | (Optional) The IP address that the apiserver will bind against node_ip | (Optional) The IP address to use to address this node minion_ip | (Optional) Mapped to the kubelet hostname_override, K8S TODO - change this name <ins> network_mode | (Optional) Networking model to use among nodes: *openvswitch* </ins> roles | (Required) 1. **kubernetes-master** means this machine is the master in the kubernetes cluster.  2. **kubernetes-pool** means this machine is a kubernetes-minion.  Depending on the role, the Salt scripts will provision different resources on the machine. These keys may be leveraged by the Salt sls files to branch behavior.

Related discussion:
text: The salt configs assume that anything under "os_family = RedHat" will use the ovs mechanisms that are only set up for vagrant. This means that we can't use Fedora on GCE.
I can clean this up today.
Code change:
"k8s.io/kubernetes/pkg/kubelet/nodeshutdown/systemd" ) <ins> // lock is to prevent systemDbus from being modified in the case of concurrency. var lock sync.Mutex </ins> type fakeDbus struct { currentInhibitDelay        time.Duration overrideSystemInhibitDelay time.Duration

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
/sig node
I find the reason for it, but I don't know the solution is suitable, correct me if not.
/triage accepted /assign
Code change:
t.Fatal("ServerVersion should return expected error, returned different error instead") } } <ins> func TestFakingServerResourcesForGroupVersionWithError(t *testing.T) { expectedError := errors.New("an error occurred") fakeClient := fakeclientset.NewClientset() fakeClient.Discovery().(*fakediscovery.FakeDiscovery).PrependReactor("*", "*", func(action kubetesting.Action) (handled bool, ret runtime.Object, err error) { return true, nil, expectedError }) result, err := fakeClient.Discovery().ServerResourcesForGroupVersion("dummy.group.io/v1beta2") if result != nil { t.Errorf(`expect result to be nil but got "%v" instead`, result) } if !errors.Is(err, expectedError) { t.Errorf(`expect error to be "%v" but got "%v" instead`, expectedError, err) } } func TestFakingServerGroupsWithError(t *testing.T) { expectedError := errors.New("an error occurred") fakeClient := fakeclientset.NewClientset() fakeClient.Discovery().(*fakediscovery.FakeDiscovery).PrependReactor("*", "*", func(action kubetesting.Action) (handled bool, ret runtime.Object, err error) { return true, nil, expectedError }) result, err := fakeClient.Discovery().ServerGroups() if result != nil { t.Errorf(`expect result to be nil but got "%v" instead`, result) } if !errors.Is(err, expectedError) { t.Errorf(`expect error to be "%v" but got "%v" instead`, expectedError, err) } } func TestFakingServerGroupsAndResourcesWithError(t *testing.T) { expectedError := errors.New("an error occurred") fakeClient := fakeclientset.NewClientset() fakeClient.Discovery().(*fakediscovery.FakeDiscovery).PrependReactor("get", "resource", func(action kubetesting.Action) (handled bool, ret runtime.Object, err error) { return true, nil, expectedError }) _, _, err := fakeClient.Discovery().ServerGroupsAndResources() if !errors.Is(err, expectedError) { t.Errorf(`expect error to be "%v" but got "%v" instead`, expectedError, err) } } </ins>

Related discussion:
text: I'm writing a UT for the following function: The code branch where the server returns an error other than could not be tested using 's . This is because does not handle the error returned by and therefore could not return errors other than : Ref: Add a to so simulate errors other than . Run the following UT (should fail):
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 api-machinery
Same issue for some other methods of : -
I'll submit a PR shortly to address this issue. /assign
Code change:
}) } <ins> testDone := make(chan struct{}) defer close(testDone) </ins> ts := httptest.NewServer( WithHTTPLogging( withDeadline(

Related discussion:
text: Similar to and easily reproducible. The handler occasionally completes and sends a response before timing out. /kind failing-test /kind flake /sig api-machinery
/assign
/assign Thank you very much for fixing these tests.
/triage accepted
Code change:
} return nil, framework.AsStatus(err) } <ins> // Check if the returned victims are valid. for nodeName, victims := range nodeNameToVictims { if victims == nil || len(victims.Pods) == 0 { if extender.IsIgnorable() { delete(nodeNameToVictims, nodeName) klog.InfoS("Ignoring node without victims", "node", nodeName) continue } return nil, framework.AsStatus(fmt.Errorf("expected at least one victim pod on node %q", nodeName)) } } </ins> // Replace victimsMap with new result after preemption. So the // rest of extenders can continue use it as parameter. victimsMap = nodeNameToVictims

Related discussion:
text: <!-- 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 --Kubernetes 1.19 (confirmed with 1.19.7 and 1.19.10) kube-scheduler crashes and restarts with the following errors in . panic: runtime error: index out of range [0] with length 0 The problem code is line 389. When is nil or is empty, the error happens. If we skip when it's nil or empty, the error is gone. panic: runtime error: invalid memory address or nil poster dereference The problem is does not exist and returns nil sometimes. Simply skipping it won't solve the problem. The scheduler will reach either line 456 or 341. The scheduler works without failures. When there are preemptions in a cluster. Kubernetes version (use ): v1.19.10 or v1.19.7 Cloud provider or hardware configuration: bare metal OS (e.g: ): centos 7 Kernel (e.g. ): Linux 5.4.77-7.el7pie SMP Sat Nov 21 01:16:27 UTC 2020 x8664 x8664 x8664 GNU/Linux Install tools: 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 scheduling
/cc
/assign
Are you running the vanilla scheduler? or a customized one that leverages the utilities in
It's a custom scheduler with some internal out-of-tree plugins (just like ), but it doesn't have any custom postFilter plugins. Which utility functions are you referring to? Thanks.
are those custom plugins filter plugins? do they maintain state?