jiebi/CodeConvo huggingface dataset:
Change:
import ( "context" "github.com/onsi/ginkgo" v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in
Change:
currState, ok := cache.podStates[key] if ok && currState.pod.Spec.NodeName != pod.Spec.NodeName { <del> return fmt.Errorf("pod %v state was assumed on a different node", key) </del> <ins> return fmt.Errorf("pod %v was assumed on %v but assigned to %v", key, pod.Spec.NodeName, currState.pod.Spec.NodeName) </ins> } switch {

Discussion:
/kind bug There are several error messages in the scheduler cache that are confusing to read, at least one of these surfaced up to end users via Events. I noticed these two in particular but there may be others: Whether or not these should actually be surfacing as events, the messages should be cleaned up.
cc
Seems that these are internal or implement details in scheduler, do our end users can fully understand what the events really mean? I think it is depend on our own implement. idea?
I believe, the problem is with in the message but I am not able to reproduce it, can you please share steps to reproduce this.
No unfortunately, one of our users reported seeing it when there system was in a bad state, not in a reproducible way. The point of the issue is just that the grammar in those messages is bad, which should be fixable even if you can't get them to fire.
Change:
// Invalidate the cache right after updating defer as.cloud.vmCache.Delete(vmName) <del> _, err = as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM, "attach_disk") </del> <ins> _, err = as.VirtualMachinesClient.Update(ctx, nodeResourceGroup, vmName, newVM, "attach_disk") </ins> if err != nil { klog.Errorf("azureDisk - attach disk(%s, %s) failed, err: %v", diskName, diskURI, err) detail := err.Error()

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Instead of using the VM CreateOrUpdate () function of the Azure Go SDK, use the VM Update function () in the azureclient () Why is this needed: Currently, the Azure Cloud Provider is using the VM CreateOrUpdate call when e.g. detach/attaching disks to a VM. In some scenarios, this will re-create a VM that was deleted by an external application. This can lead to orphaned VMs or blocked resources. The Update function will only update an existing VM and will fail if the VM does not exist.
/sig azure
/assign
/sig cloud-provider
Could you describe more about the scenarios? Have you noticed such issues? I wonder adding etags to the API call could help to prevent this?
If you have an application that maintains your K8s clusters, e.g. takes care of OS update/patching. If the application wants to patch the OS of a worker node, it would drain the node first. If draining times out, it will go ahead and delete the VM anyway. But K8s might still be detaching disks. These detach operations, because they use CreateOrUpdate, will recreate the VM. Is there a reason why you would want to create a VM i.e. why CreateOrUpdate is required and Update would not work? AFAIK, Azure Compute RP does not support etags.
that sounds reasonable, thanks change to use function would be safer since it's only detach/attach disk operation. I will do that.
thanks for the information. Reasonable enough. /assign
/milestone v1.16
BTW, the reason why we only use func in the beginning is that Azure Compute go sdk did not provide a func at that time...
Great. Thanks!
Change:
"io" "net" "net/url" <del> "os" </del> "regexp" "strconv" "strings"

Discussion:
I am having trouble on my AWS 1.3.0beta0 cluster to attach EBS with the controller-manager based attacher. There problem is here: This is failing as the kube-controller-manager is running in a pod via kubelet manifests. I think if you have a cluster with different instance types mixed you ran into trouble as well, as the device names will be either (sdX or xvdX) and the cluster will do it based on the state of the master (controller-manager). My work around for now is to enable a host mount of for the controller manager. But this need to be addressed at some point. Is there any way we get the correct name from the AWS api? I think it's depending on the kernel version if it is xvdX or sdX. Am I right on this? A more ugly solution could be to annotate the node during registration, if it's has or device names maybe you can help me get a proper solution for this. I am happy to contribute a PR
I have just found , I think we could get this information from AWS:
That code is supposed to check, but it is quite possible I got it backwards looking at it. Also I agree that the logic is going to be problematic anyway with mixed instance types etc if we've moved attachment to KCM. What AMI are you using? I may have just been "lucky" so far in the AMIs I've used, in that the heuristics have worked correctly. Also, if you have time, would be great to know: /dev/ looks like on one of the problematic nodes (i.e. in particular we have /dev/sda and/or /dev/xvda)? is the output of the describe-images command for that AMI (particularly if it is private)? I like the describe-images approach!

I'm marking this as 1.3 P1 (sorry as for now my working hypothesis is that this was introduced when we moved disk attachment to KCM (I believe previously the kubelet did it, but want to double-check)
I tried to get a such environments with CoreOS amis: (all eu-west1) vtype is PV vtype is HVM The describe instances returns different rootdevicenames: But if I ssh into the two instances, the devices are called the same for both: I think we have to somehow signal the devicename from the Kubelet to the KCM to solve this properly. My understanding is to get the sdX names we have to use an pretty old kernel. Maybe it'a good idea to change the default behaviour, see PR . So fallback to '/dev/xvdX'
I don't see any indication that this is a regression. I am kicking it out of milestone 1.3. Explain how it is a regression or otherwise super-important to get it back on the milestone.
It is a regression: volume mounting is broken on AWS. My believe is that it happens because we have moved volume mounting to KCM, and/or KCM runs in a container. Between those two, volume mounting just doesn't work right now.
Change:
"fmt" "io" "net" <ins> "net/http" </ins> "os" "os/exec"

Discussion:
Environment: VMware CentOS Linux release 7.2.1511 (Core) kernel: 3.10.0-327.36.1.el7.x8664 Installed packages: kubeadm.x8664 1.5.0-0.alpha.0.1534.gcf7301f kubectl.x8664 1.4.0-0 kubelet.x8664 1.4.0-0 kubernetes-cni.x8664 0.3.0.1-0. docker-engine.x8664 1.11.2- docker-engine- 1.12.1- What happened: kubeadm init hangs indefintely after: kubeadm init <master/tokensgenerated token: "." <master/pkicreated keys and certificates in "/etc/kubernetes/pki" <util/kubeconfigcreated "" <util/kubeconfigcreated "" <master/apiclientcreated API client configuration <master/apiclientcreated API client, waiting for the control plane to become readykubeadm init What you expected to happen: Master node initialize Anything else do we need to know: Only the kubeadm and kublet processes are running. When I do docker ps no containers are running. If i type docker images the only image that has been downloaded are: I've also tried: kubeadm init --api-advertise-addresses but with the same outcome (followed the clean-up at ) Im behind a firewall so I'm using proxy settings for docker. I have confirmed I can reach images on docker hub and google cloud registry
will download the required binaries viz etcd. When you are behind firewall kubeadm will hang/wait forever to download the binaries. I dont know whether it is addressed correctly in kubeadm implementation. I am also facing the same issue and waiting for the resolution.
Thx, I suspected it to be some firewall issue. Do you know if there's a way to add httpsproxy & httpproxy settings to kubeadm?
Kubeadm doesn't seem to pick proxy environment variables. I am looking at recompiling with proxy support may work. But I dont know how to do that. Waiting for updates about proxy
This issue same as Lets join there. The solution mentioned there may work.

You can try kubeadm with patch applied from PR : It works at least in my environment behind restrictive proxy.
thanks, I will look into it
Change:
func (detacher *azureDiskDetacher) UnmountDevice(deviceMountPath string) error { err := util.UnmountPath(deviceMountPath, detacher.plugin.host.GetMounter(detacher.plugin.GetPluginName())) if err == nil { <del> glog.V(4).Infof("azureDisk - Device %s was unmounted", deviceMountPath) </del> <ins> glog.V(2).Infof("azureDisk - Device %s was unmounted", deviceMountPath) </ins> } else { <del> glog.Infof("azureDisk - Device %s failed to unmount with error: %s", deviceMountPath, err.Error()) </del> <ins> glog.Warningf("azureDisk - Device %s failed to unmount with error: %s", deviceMountPath, err.Error()) </ins> } return err }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Current logging is not enough for azure disk diagnostics, change some log level from 4 to 2 What you expected to happen: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
var _ = framework.KubeDescribe("Summary API", func() { f := framework.NewDefaultFramework("summary-test") Context("when querying /stats/summary", func() { <ins> AfterEach(func() { if CurrentGinkgoTestDescription().Failed && framework.TestContext.DumpLogsOnFailure { framework.LogFailedContainers(f.ClientSet, f.Namespace.Name, framework.Logf) } }) </ins> It("should report resource usage through the stats api", func() { const pod0 = "stats-busybox-0" const pod1 = "stats-busybox-1"

Discussion:
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
The test failed because the busybox container was crash-looping, but I'm not sure why.
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
- Any ideas what changed in the past week that would cause the Kubelet usage/working set memory usage to suddenly increase? It may be a non-issue, but it's concerning that this seems to have recently changed. - This is only happening on GCI. Did we change the GCI image being tested recently?
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
Last image version update for testing was 11 days ago () though we are soon going to update it again ().
Since we increased the bound on (), we should also increase the bound on ( is usage - total inactive file). I think this may be the cause of this flake.
I agree that the bounds should match, but the cause of both flakes (why usage & workingset suddenly increased) is still unknown.
Usage workingset so it may not be necessary to bump both ;) I think this may be the caused by the gci mounter.

/cc
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
https://k8s- Failed: [] Summary API when querying /stats/summary should report resource usage through the stats api {E2eNode Suite}
I checked the log from the last failure, didn't see anything related to gci mounter. The test failed on trusty node which mounter should not be used at all.
Yes, the latest failures are just a flake introduced by The bounds need to be adjusted for the misc container. I'll send a PR soon.
Change:
} } <ins> func TestPrintNodeExternalIP(t *testing.T) { printer := NewHumanReadablePrinter(PrintOptions{ ColumnLabels: []string{}, Wide:         true, }) table := []struct { node       api.Node externalIP string }{ { node: api.Node{ ObjectMeta: api.ObjectMeta{Name: "foo1"}, Status:     api.NodeStatus{Addresses: []api.NodeAddress{{Type: api.NodeExternalIP, Address: "1.1.1.1"}}}, }, externalIP: "1.1.1.1", }, { node: api.Node{ ObjectMeta: api.ObjectMeta{Name: "foo2"}, Status:     api.NodeStatus{Addresses: []api.NodeAddress{{Type: api.NodeInternalIP, Address: "1.1.1.1"}}}, }, externalIP: "<none>", }, { node: api.Node{ ObjectMeta: api.ObjectMeta{Name: "foo3"}, Status: api.NodeStatus{Addresses: []api.NodeAddress{ {Type: api.NodeLegacyHostIP, Address: "1.1.1.1"}, {Type: api.NodeExternalIP, Address: "2.2.2.2"}, {Type: api.NodeInternalIP, Address: "3.3.3.3"}, {Type: api.NodeExternalIP, Address: "4.4.4.4"}, }}, }, externalIP: "2.2.2.2", }, } for _, test := range table { buffer := &bytes.Buffer{} err := printer.PrintObj(&test.node, buffer) if err != nil { t.Fatalf("An error occurred printing Node: %#v", err) } if !contains(strings.Fields(buffer.String()), test.externalIP) { t.Fatalf("Expect printing node %s with external ip %#v, got: %#v", test.node.Name, test.externalIP, buffer.String()) } } } </ins> func contains(fields []string, field string) bool { for _, v := range fields { if v == field {

Discussion:
Nice to have for nodePort service debugging, creating manual firewalls, hitting hostNetwork or hostPort pods etc. Currently I need to either -o yaml, --template, or switch to gcloud.
This should be quite easy, should be good for contribution.
I could take a look at this. What information exactly that is available in yaml output should be shown? This is example yaml from my node: There should be an additional address with type , right? Should all types be supported or only external when is used?
-o wide should just dump what we get from the api-server right? What changes should be in kubectl?
-o yaml dumps apiserver outout, -o wide appends useful information at the cost of overflowing 80 chars. I'm asking that -o wide does for nodes what it already does for pods. I currently have such a function in my bash rc: I use it pretty often. That's a signal that more people are probably doing the same.
thanks!
Change:
close(heartbeat.closer) t.Errorf("unexpected heartbeat timeout") } <ins> wg.Wait() </ins> } func TestWebSocketClient_StreamsAndExpectedErrors(t *testing.T) {

Discussion:
FAIL: TestWebSocketClientHeartbeatSucceeds also flake in ci-kubernetes-unit use of closed network connection /cc /sig api-machinery network cli
/cc /triage accepted
seems it got better since
The new flake in this test is like I also see the failure in some PR: for instance.
yeah, it is racing somewhere , at least we have a different symptom now
/help someone want a great challenge and make a very useful contribution?
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
something odd is with the test, the panic is because it logs on the goroutine, but I'm not completely sure the test is working as expected
my apologies, I found the problem and I'm submitting a patch /assign /unassign you can help me with the review if you want
Change:
} defer os.Remove(f.Name()) <ins> if _, err := serviceaccount.ReadPublicKeys(f.Name()); err == nil { t.Fatalf("Expected error reading keys from empty file, got none") } </ins> if err := ioutil.WriteFile(f.Name(), []byte(rsaPublicKey), os.FileMode(0600)); err != nil { t.Fatalf("error writing public key to tmpfile: %v", err) }

Discussion:
Kubernetes version Serverversion 1.5.2 (running Hyperkube v1.5.2coreos.1 ()) Environment: Bare-Metal Coreos 1235.6.0 (Kernel 4.7.3-coreos-r2) What happened: kube-controller-manager with ecdsa key fails to start F0127 09:59:04. 1 ] error running controllers: Error reading key for service account token controller: error reading private key file data does not contain a valid RSA or ECDSA private key The key is valid (and works with e.g. the api-server) Command used to create the key:
the issue is the block. removing that (invoke openssl with to omit it from the start) will allow the key to be consumed. will fix in 1.6 to ignore that block when reading the private key block
Change:
allErrs = append(allErrs, field.Required(projPath.Child("path"), "")) } <del> allErrs = append(allErrs, validateLocalNonReservedPath(source.ClusterTrustBundle.Path, projPath.Child("path"))...) </del> <ins> allErrs = append(allErrs, ValidateLocalNonReservedPath(source.ClusterTrustBundle.Path, projPath.Child("path"))...) </ins> curPath := source.ClusterTrustBundle.Path if !allPaths.Has(curPath) {

Discussion:
Originally posted by in
Hello, I'm new here. Can I try solving this? it seems like a good first issue
sure, context is the change is needed here: We have to tolerate existing pods / pod specs that fail this validation, so we should only do this additional validation on create or if the existing object passes this validation. To do this: an field to , initialize that field to false, and then conditionally override it to if is non-nil and has a projected token volume path that fails (will have to export the function to check this) , if is false, call the validation on the path:
Hi, I'd like to work on this if there is no one is proceeding on. /assign
Change:
} cfg.Profiles = completedProfiles <ins> if len(fileName) > 0 { // Since the default component config lists all the default plugins as enabled // without disabling them, we must explicitly disable all the plugins for each // extension point using the "*" expression to ensure that the generated config // file is usable disabledPlugins := []config.Plugin{{Name: "*"}} for i := range cfg.Profiles { if cfg.Profiles[i].Plugins == nil { continue } cfg.Profiles[i].Plugins.QueueSort.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreFilter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Filter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PostFilter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreScore.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Score.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Reserve.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Permit.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreBind.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Bind.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PostBind.Disabled = disabledPlugins } } </ins> buf, err := encodeConfig(cfg) if err != nil { return err

Discussion:
--write-to-config flag in the scheduler writes to a file the default component config; however this config if passed back to the scheduler is not usable because it lists all default plugins as enabled without disabling them. To make the configuration usable as an input config while at the same time useful for debugging, the output should disable all plugins for each extension point using the "*" expression. /help /sig scheduling /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : --write-to-config flag in the scheduler writes to a file the default component config; however this config if passed back to the scheduler is not usable because it lists all default plugins as enabled without disabling them. /help /sig scheduling /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue 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