jiebi/CodeConvo huggingface dataset:
Change:
runtimeService internalapi.RuntimeService, containerManager cm.ContainerManager) *HollowKubelet { d := &kubelet.Dependencies{ <del> KubeClient:           client, HeartbeatClient:      heartbeatClient, ProbeManager:         probetest.FakeManager{}, RemoteRuntimeService: runtimeService, RemoteImageService:   imageService, CAdvisorInterface:    cadvisorInterface, Cloud:                nil, OSInterface:          &containertest.FakeOS{}, ContainerManager:     containerManager, VolumePlugins:        volumePlugins(), TLSOptions:           nil, OOMAdjuster:          oom.NewFakeOOMAdjuster(), Mounter:              &mount.FakeMounter{}, Subpather:            &subpath.FakeSubpath{}, HostUtil:             hostutil.NewFakeHostUtil(nil), </del> <ins> KubeClient:               client, HeartbeatClient:          heartbeatClient, ProbeManager:             probetest.FakeManager{}, RemoteRuntimeService:     runtimeService, RemoteImageService:       imageService, CAdvisorInterface:        cadvisorInterface, Cloud:                    nil, OSInterface:              &containertest.FakeOS{}, ContainerManager:         containerManager, VolumePlugins:            volumePlugins(), TLSOptions:               nil, OOMAdjuster:              oom.NewFakeOOMAdjuster(), Mounter:                  &mount.FakeMounter{}, Subpather:                &subpath.FakeSubpath{}, HostUtil:                 hostutil.NewFakeHostUtil(nil), PodStartupLatencyTracker: kubeletutil.NewPodStartupLatencyTracker(), </ins> } return &HollowKubelet{

Discussion:
All kubemark tests started failing around 11-04. https://k8s- https://k8s- The testing framework is not able to schedule pods. hollow kubelets has errors like: Finally (when the test already failed) it changes to Suspected commit range: ci-kubernetes-kubemark-500-gce.Overall 11-04 https://k8s- No response No response /sig scalability
/triage accepted
/assign
None of the commits in the range looks indeed suspicious (mostly some endpointslice and metrics changes).
I forgot that the commit in the testgrid doesn't match the tested version. The real suspected range is Probably is a suspect.
It helped !
Change:
func kubeconfigClientConfig(s *options.KubeletServer) (*restclient.Config, error) { return clientcmd.NewNonInteractiveDeferredLoadingClientConfig( <del> &clientcmd.ClientConfigLoadingRules{ExplicitPath: s.KubeConfig.Value()}, </del> <ins> &clientcmd.ClientConfigLoadingRules{ExplicitPath: s.KubeConfig}, </ins> &clientcmd.ConfigOverrides{}, ).ClientConfig() } // createClientConfig creates a client configuration from the command line arguments. <del> // If --kubeconfig is explicitly set, it will be used. If it is not set but // --require-kubeconfig=true, we attempt to load the default kubeconfig file. </del> <ins> // If --kubeconfig is explicitly set, it will be used. </ins> func createClientConfig(s *options.KubeletServer) (*restclient.Config, error) { <del> // If --kubeconfig was not provided, it will have a default path set in cmd/kubelet/app/options/options.go. // We only use that default path when --require-kubeconfig=true. The default path is temporary until --require-kubeconfig is removed. // TODO(#41161:v1.10.0): Remove the default kubeconfig path and --require-kubeconfig. if s.BootstrapKubeconfig != "" || s.KubeConfig.Provided() || s.RequireKubeConfig == true { </del> <ins> if s.BootstrapKubeconfig != "" || len(s.KubeConfig) > 0 { </ins> return kubeconfigClientConfig(s) } else { return nil, fmt.Errorf("createClientConfig called in standalone mode")

Discussion:
This will be the end of the deprecation period for --require-kubeconfig.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
ref
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
glog.V(5).Infof("Statfs_t of %v: %+v", path, buf) if buf.Type == linuxTmpfsMagic { return mediumMemory, !notMnt, nil <del> } else if buf.Type == linuxHugetlbfsMagic { </del> <ins> } else if int64(buf.Type) == linuxHugetlbfsMagic { </ins> return mediumHugepages, !notMnt, nil } return mediumUnknown, !notMnt, nil

Discussion:
https://k8s- https://k8s- cc: /kind bug /priority failing-test
Fix in progress in
Change:
case testpatterns.DynamicPV: By("Deleting pvc") // We only delete the PVC so that PV (and disk) can be cleaned up by dynamic provisioner <del> if r.pv.Spec.PersistentVolumeReclaimPolicy != v1.PersistentVolumeReclaimDelete { </del> <ins> if r.pv != nil && r.pv.Spec.PersistentVolumeReclaimPolicy != v1.PersistentVolumeReclaimDelete { </ins> framework.Failf("Test framework does not currently support Dynamically Provisioned Persistent Volume %v specified with reclaim policy that isnt %v", r.pv.Name, v1.PersistentVolumeReclaimDelete) } <del> err := framework.DeletePersistentVolumeClaim(f.ClientSet, r.pvc.Name, f.Namespace.Name) framework.ExpectNoError(err, "Failed to delete PVC %v", r.pvc.Name) err = framework.WaitForPersistentVolumeDeleted(f.ClientSet, r.pv.Name, 5*time.Second, 5*time.Minute) framework.ExpectNoError(err, "Persistent Volume %v not deleted by dynamic provisioner", r.pv.Name) </del> <ins> if r.pvc != nil { err := framework.DeletePersistentVolumeClaim(f.ClientSet, r.pvc.Name, f.Namespace.Name) framework.ExpectNoError(err, "Failed to delete PVC %v", r.pvc.Name) if r.pv != nil { err = framework.WaitForPersistentVolumeDeleted(f.ClientSet, r.pv.Name, 5*time.Second, 5*time.Minute) framework.ExpectNoError(err, "Persistent Volume %v not deleted by dynamic provisioner", r.pv.Name) } } </ins> default: framework.Failf("Found PVC (%v) or PV (%v) but not running Preprovisioned or Dynamic test pattern", r.pvc, r.pv) }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce Which test(s) are failing: I0221 20:48:18.462] [sig-storage] In-tree Volumes I0221 20:48:18.462] [[0m I0221 20:48:18.462] [Driver: gcepd] I0221 20:48:18.462] [[0m I0221 20:48:18.462] [Testpattern: Dynamic PV (filesystem volmode)] volumeMode I0221 20:48:18.463] [[0m I0221 20:48:18.463] should create sc, pod, pv, and pvc, read/write to the pv, and delete all created resources Since when has it been failing: unsure Testgrid link: Reason for failure: From the logs, it looks like it's deleting both PVC and PV objects at the same time, which is not correct. I0221 20:48:18.460] Feb 21 20:48:09.866: INFO: Deleting PersistentVolumeClaim "pvc-cjv2l" I0221 20:48:18.460] Feb 21 20:48:09.923: INFO: Deleting PersistentVolume "pvc--3619-11e9-b923-" should be changed to only delete PVC and wait for PV to be deleted by the driver. Can it just call which does it correctly? Anything else we need to know:
cc
It has been like that already before my recent code refactoring: Therefore I have to defer to - I myself don't really know what this test does or why it was written like that.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
/priority critical-urgent
Change:
"k8s.io/kubernetes/pkg/kubelet/pluginmanager/cache" "k8s.io/kubernetes/pkg/kubelet/stats/pidlimit" "k8s.io/kubernetes/pkg/kubelet/status" <ins> "k8s.io/kubernetes/pkg/kubelet/userns/inuserns" </ins> schedulerframework "k8s.io/kubernetes/pkg/scheduler/framework" "k8s.io/kubernetes/pkg/util/oom" )

Discussion:
is no longer compilable on macOS in the master branch. It was compilable with Kubernetes v1.29.0 and v1.30.0-alpha.0. It should be compilable. No response <detailsmaster () (This is just the latest commit, not the commit that introduced the regression) </details<detailsN/A </details<detailsmacOS 14.2.1 (Intel) </details<detailsN/A </details<detailsN/A </details<detailsN/A </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
/sig testing
Regression in:
Change:
} // Act <del> go reconciler.Run(wait.NeverStop) </del> <ins> ch := make(chan struct{}) go reconciler.Run(ch) defer close(ch) </ins> // Assert waitForNewAttacherCallCount(t, 1 /* expectedCallCount */, fakePlugin)

Discussion:
Looks like similar issue with
That's the PV controller this is the attach controller, thus separate issues.
Change:
runtime.HandleError(fmt.Errorf("error creating forwarding stream for port %d -> %d: %v", port.Local, port.Remote, err)) return } <ins> defer pf.streamConn.RemoveStreams(dataStream) </ins> localError := make(chan struct{}) remoteDone := make(chan struct{})

Discussion:
The port forwarding client leaks memory when a port forwarding session is reused over time. The port forwarder client should not leak memory. forwarding a port with kubectl. and close many connections to the forwarded port. The amount of memory leaked for each connection is quite small, so many connections are needed to observe the leak. This is related to , which was reported for the kubelet and fixed in . However, the same problem happens to the client. The client needs to call on the , otherwise the streams created by will be kept in memory until the port forwarder itself is closed, even if the streams themselves closed long before. <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
/cc
Change:
local targets=( vendor/github.com/onsi/ginkgo/ginkgo test/e2e/e2e.test <ins> cluster/images/conformance/go-runner </ins> cmd/kubectl ) echo "${targets[@]}"

Discussion:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Change:
github.com/json-iterator/go v1.1.6 github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024 github.com/karrick/godirwalk v1.7.5 // indirect <del> github.com/libopenstorage/openstorage v0.0.0-20170906232338-093a0c388875 </del> <ins> github.com/libopenstorage/openstorage v1.0.0 </ins> github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de github.com/lithammer/dedent v1.1.0 github.com/lpabon/godbc v0.1.1 // indirect

Discussion:
Found this when trying to see which vendored dependencies does not use a proper tag (and is using a random SHA). The dependency is very old and there have been a lot of updates to it: Looks like the However there does not seem to be anyone around to take care of the portworx plugin. Is it time to deprecate it? is anyone using it? /sig storage
cc ?
/area code-organization
Hello The portworx volume plugin is definitely in use. The portworx volume plugin doesn't need frequent updates since the plugin acts as a simple client to all provisioning calls. In the same view, the vendored openstorage package doesn't need to be updated too. The server side implementation in Portworx handles all the latest Portworx features.
cc:
in that case, can you please update the dependency to a specific tag instead of a random SHA?
/assign updated the title of the issue as well
my request is not for a new release or tag in libopenstorage/openstorage repository. Just to update the SHA we use in our k/k repository to one of the released versions ( ). This is not asking or demanding anything to be done in libopenstorage/openstorage, just that we should update what we use from there (and avoid a random SHA). We are trying to do this for all vendored libraries (one by one … slowly as part of the sig-arch code organization sub project, so it’s not a random request)
/assign
GitHub didn't allow me to assign the following users: lpabon. Note that only , 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 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
After a chat with - apparently this request is coming across the wrong way I am closing this out as it seems to add a over head /close
Closing this issue. <detailsIn response to : After a chat with - apparently this request is coming across the wrong way /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
Change:
func SetupSignalHandler() <-chan struct{} { close(onlyOneSignalHandler) // panics when called twice <ins> shutdownHandler = make(chan os.Signal, 2) </ins> stop := make(chan struct{}) <del> c := make(chan os.Signal, 2) signal.Notify(c, shutdownSignals...) </del> <ins> signal.Notify(shutdownHandler, shutdownSignals...) </ins> go func() { <del> <-c </del> <ins> <-shutdownHandler </ins> close(stop) <del> <-c </del> <ins> <-shutdownHandler </ins> os.Exit(1) // second signal. Exit directly. }() return stop } <ins> // RequestShutdown emulates a received event that is considered as shutdown signal (SIGTERM/SIGINT) // This returns whether a handler was notified func RequestShutdown() bool { if shutdownHandler != nil { select { case shutdownHandler <- shutdownSignals[0]: return true default: } } return false } </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: I configured Kubelet to run as a service on Windows, with a setting to restart on failure (). I noticed that it restarts even when I explicitly stop the service with , even though the documentation states the following (I left it at , the default): What you expected to happen: I expected the Kubelet to only restart when killed unexpectedly, per above docs. Anything else we need to know?: I think the problem might be due to this part of our service control integration, but I'm not really sure: It looks like we send and then , but the official golang example sends and just returns without exiting. (). Is this difference meaningful? Kubernetes version (use ): 1.13.2 Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Windows /cc /sig node /sig windows
The same should apply to kube-proxy as well.
i believe you implemented this functionality. can you please take a look? cc:
Change:
// to the API server. // // The caller must not modify the content after the call. <del> PublishResources(ctx context.Context, resources Resources) </del> <ins> // // Returns an error if KubeClient or NodeName options were not // set in Start() to create the DRAPlugin instance. PublishResources(ctx context.Context, resources Resources) error </ins> // This unexported method ensures that we can modify the interface // without causing an API break of the package

Discussion:
When calling draplugin.Start without supplying kubeclient no error is reported, while the kubeclient is vital for further announcement of resourceSlice. An error needs to be returned when nodeName or kubeclient parameters are not set. Do not supply kubeclient parameter when creating draplugin, for isntance here: No response master <details</details<details</details<details</details<details</details<details</details
/sig node /triage accepted /project 95
Change:
DomainNameLabel: &domainNameLabel, } } <del> pip.Tags = map[string]*string{"service": &serviceName} </del> <ins> pip.Tags = map[string]*string{ serviceTagKey:  &serviceName, clusterNameKey: &clusterName, } </ins> if az.useStandardLoadBalancer() { pip.Sku = &network.PublicIPAddressSku{ Name: network.PublicIPAddressSkuNameStandard,

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: We deployed two Kubernetes clusters to the same Azure Resource Group. Created services of load balancer type on both clusters. One of the services never received a public IP. Upon investigation, we noticed that the first Kubernetes cluster deleted the Azure Public IP that was created for the service by the other cluster. Apparently, all public IPs in the resource group are retrieved: then public IPs which don't match this criteria: are deleted. This logic besides the name of the kubernetes service should also consider the K8s cluster where the public IP originated from to avoid stepping on each other's toes when multiple clusters share the same resource group. What you expected to happen: In case multiple clusters run in the same resource group a cluster should delete only resources created by itself. How to reproduce it (as minimally and precisely as possible): Create two Kubernetes clusters (1.14) with different cluster names to the same resource group than create kubernetes services of load balancer type in each cluster. Anything else we need to know?: Environment: Kubernetes version (use ): 1.4 Cloud provider or hardware configuration: Azure OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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 for reporting the issue, this is the bug we should fix for sharing resource group. /sig azure /kind bug /assign
Change:
local dest_dir="${2}" export-windows-docker-event-log "${node}" <ins> export-windows-docker-images-list "${node}" </ins> local remote_files=() for file in ${windows_node_logfiles[@]}; do remote_files+=( "${WINDOWS_LOGS_DIR}${file}" )

Discussion:
When a test run completes it would be useful to have a list of all the test containers that were pulled onto the node - see for the motivation. Let's add a call to at - just after seems like it should work fine. We can dump the output to a file and gather it from each node just like we do for
/assign Yang, we should also consider adding to the log gathering that the GCE diagnostics tool does :)
/sig windows
/reopen in the of our on 03-22 I don't see in the artifacts for the Windows node. Can you check on this? Did we miss a step or is something failing?
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
Oh, missed to add the new log file to collector list.
Added the fix:
Change:
} // Compute a three way strategic merge patch to send to server. <del> patch, err := strategicpatch.CreateThreeWayMergePatch(original, modified, current, versionedObject, true) </del> <ins> patch, err := strategicpatch.CreateThreeWayMergePatch(original, modified, current, versionedObject, p.overwrite) </ins> if err != nil { format := "creating patch with:noriginal:n%snmodified:n%sncurrent:n%snfor:" return nil, cmdutil.AddSourceToErr(fmt.Sprintf(format, original, modified, current), source, err)

Discussion:
This issue tracks the implementation of the --overwrite flag in kubectl apply, per in .
Changed the title to address only the --overwrite flag, since deals with the --force flag.
progress on this issue is blocked waiting for to merge.
Change:
'roles:kubernetes-pool': - match: grain - docker <ins> {% if grains['cloud'] is defined and grains['cloud'] == 'azure' %} - openvpn-client {% else %} - sdn {% endif %} </ins> - kubelet - kube-proxy {% if pillar.get('enable_node_monitoring', '').lower() == 'true' %}

Discussion:
On latest pull, the Vagrant kube- scripts completes successfully, but the Salt setup in the minion keeps going forever. End result is a cluster that is not useable. Looking at '/var/log/salt/minion' on the minion box, see lots of entries like: 2015-03-04 20:09:11,952 [ ][INFO ] Starting a new job with PID 2015-03-04 20:09:11,954 [ ][INFO ] Returning information for job: 2015-03-04 20:09:12,027 [ ][DEBUG ] Decrypting the current master AES key 2015-03-04 20:09:12,028 [ ][DEBUG ] Loaded minion key: 2015-03-04 20:09:12,217 [ ][INFO ] User vagrant Executing command with jid 2015-03-04 20:09:12,217 [ ][DEBUG ] Command details {'tgt_type': 'glob', 'jid': '', 'tgt': '*', 'ret': '', 'user': 'vagrant', 'arg': [], 'fun': ''} No other help looking at the master's salt log. This is Vagrant 1.7.2, with VirtualBox 4.3.20 on Mac OSX (Yosemite).
Is this repeatable for you if kube-down and kube-up?
Yes, this is reproducible on my laptop. But, I was able to get it up by doing a kube-push after the failed kube-up. , Eric Tune wrote:
Self assigning and will try to reproduce. Sent from my iPhone
I was able to reproduce. It appears that the Kubelet fails to start properly on first start:
The push basically caused the Kubelet to restart, and then it does work. Without the push, systemd would have eventually restarted the Kubelet. We need more investigation as to what was causing the Kubelet to fail on initial startup.
Change:
return nil } <del> name := s.loadBalancerName(service) </del> <ins> name := cloudprovider.GetLoadBalancerName(service) </ins> err := s.balancer.UpdateTCPLoadBalancer(name, s.zone.Region, hosts) if err == nil { return nil

Discussion:
Since this PR got merged, the ELB e2e test, which was consistently succeeding, is now consistently failing: Revert now that is in, and fix the tests that were relying on it. (details) Commit by arob Revert now that is in, and fix the tests that were relying on it. The file was modified The file was modified The file was modified I'm going to roll it back to confirm.
Change:
} if o.Minify { <ins> if len(o.Context) > 0 { config.CurrentContext = o.Context } </ins> if err := clientcmdapi.MinifyConfig(config); err != nil { return err }

Discussion:
/kind bug What happened: Current context was set to cluster1. Ran and got back information about cluster1 instead. What you expected to happen: I expected the output to be the cluster2 information How to reproduce it (as minimally and precisely as possible): Have two contexts in your kube config, A and B Run to set A as current context Run Anything else we need to know?: I'd like to help contribute, so if this is an easy fix, someone point me in the right direction and I'll try to get it done. Environment: Kubernetes version (use ): 1.10.2 OS (e.g. from /etc/os-release): MacOS 10.11.6 Install tools: kubectl was installed via brew
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/assign Filed