jiebi/CodeConvo huggingface dataset:
Change:
pod := &api.BoundPod{Spec: api.PodSpec{Containers: []api.Container{ {Name: "foo"}, {Name: "bar"}, <ins> {Name: ""}, </ins> {Name: "baz"}, }}} table := map[string]struct {

Discussion:
Forked from ... The event generated from kubelet for BoundPod and displayed by kubectl should have Container(s) column ; otherwise, the user might think the entire pod is at the running state, but actually only one or some containers are running. When there are missing event(s) for failed containers, the thing gets worse. For example, in case, only net container is running. $ get events | grep testpd Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get events Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting created Created with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 Mon, 29 Dec 2014 20:58:38 +0000 testpd Pod Pending scheduled Successfully assigned testpd to kubernetes-minion- Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting pulled Successfully pulled image kubernetes/pause:latest Mon, 29 Dec 2014 20:58:39 +0000 testpd BoundPod running started Started with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004
Change:
importpath = "k8s.io/kubernetes/pkg/scheduler/framework/plugins/serviceaffinity", visibility = ["//visibility:public"], deps = [ <del> "//pkg/scheduler/algorithm/predicates:go_default_library", "//pkg/scheduler/framework/plugins/migration:go_default_library", </del> "//pkg/scheduler/framework/v1alpha1:go_default_library", "//pkg/scheduler/listers:go_default_library", "//pkg/scheduler/nodeinfo:go_default_library",

Discussion:
Part of See example /sig scheduling /kind cleanup /help /priority important-soon
/assign /remove-help
Change:
import ( "fmt" <ins> "time" </ins> "k8s.io/klog/v2"

Discussion:
Log statements and metrics indicating when the node authorizer graph has be updated for a pod. There is already a log statement for when the graph starts an update, but this is before the graph lock is obtained and doesn't tell when the graph update is completed. We are seeing node authorizer failures which prevent pods from starting for extended periods of time. It is believed that this is caused by a race between: the node authorizer graph being updated the node requesting the secret It is important to have logging that indicates when the graph finished updating in order to reflect lock contention on the graph.
/sig auth
/triage accepted Seems like a reasonable feature request.
Hi, folks I would like to work on this. /assign
Hi Fixed this issue here PTAL!
Change:
function find-master-pd { local name=${MASTER_NAME}-pd if [[ -z "${MASTER_DISK_ID}" ]]; then <ins> local zone_filter="Name=availability-zone,Values=${ZONE}" if [[ "${KUBE_USE_EXISTING_MASTER:-}" == "true" ]]; then # If we're reusing an existing master, it is likely to be in another zone # If running multizone, your cluster must be uniquely named across zones zone_filter="" fi </ins> MASTER_DISK_ID=`$AWS_CMD describe-volumes  <del> --filters Name=availability-zone,Values=${ZONE}  </del> <ins> --filters ${zone_filter}  </ins> Name=tag:Name,Values=${name}  Name=tag:KubernetesCluster,Values=${CLUSTER_ID}  --query Volumes[].VolumeId`

Discussion:
When we add nodes to an existing cluster, we need to reuse the existing configuration. In particular, we need to extract the kubelet cert & key, otherwise we get a cert error connecting to the master.
WIP fix in
Change:
"syscall" "os" <ins> "time" </ins> v1 "k8s.io/api/core/v1" utilfeature "k8s.io/apiserver/pkg/util/feature"

Discussion:
What happened: there are many kubelet warnings in the systemd logs I initialized the cluster with kubeadm init (no modifications) What you expected to happen: Not to have that many kubelet warnings in the system logs Anything else we need to know?: Environment: Kubernetes version (use kubectl version):Cloud provider or hardware configuration:OS (e.g: cat /etc/os-release):Kernel (e.g. uname -a):Install tools:
I have the same issue
should add a option or an annotationo to resolve this /sig node /area kubelet
Same issue kops, kubernetes 1.18.3, aws cloudprovider
Same issue on v1.17.4 installed with rancher
Same issue on v1.18.0 ~
Same issue on 1.17.6
Happens on v1.18.3 as well. This issue only occurs when container has some fsGroup set in its securityContext AND volume being mounted is either secret or a configmap. I guess they are being re-mounted every 70s or so. It's okay when the volume being mounted is a standard PV - log only appears once and doesn't get repeated.
I'm seeing the same issue. I'm willing to fix it.
I've digged into this a little bit further. I believe this is just a annoying warning message. AFAICS, it does not show any issue... I was reading the kubelet, its volume manager and the volume plugins source files. It seems that's the expected behavior. The desiredStateOfWorldPopulator sync loop always call the . The finds the volume plugin and check if the plugin requires mount. Secret plugin, wich is the plugin in discussion, always returns . Thus, the of the volume manager remounts the volume every time. I think the problem is in the which prints the warning message. It's more and I believe it does not take these plugins into account. The secret plugin is as it is now since . Is that make sense to you?
/assign
Change:
"//pkg/api/validation:go_default_library", "//pkg/apimachinery/registered:go_default_library", "//pkg/apis/apps:go_default_library", <ins> "//pkg/apis/batch:go_default_library", </ins> "//pkg/apis/componentconfig:go_default_library", "//pkg/apis/extensions:go_default_library", "//pkg/client/clientset_generated/internalclientset:go_default_library",

Discussion:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in . Previous issues for this test:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
Change:
Resources: resources, }, }, <ins> NodeName: node, </ins> }, } if critical {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
package apiserver import ( <ins> "crypto/tls" </ins> "io/ioutil" "net/http" "net/http/httptest" "net/http/httputil" <ins> "net/url" </ins> "reflect" "strings" "testing" <ins> "golang.org/x/net/websocket" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apiserver/pkg/authentication/user" genericapirequest "k8s.io/apiserver/pkg/endpoints/request" "k8s.io/kube-aggregator/pkg/apis/apiregistration" <del> "net/url" </del> ) type targetHTTPHandler struct {

Discussion:
an APIService that routes to an external API server (e.g. service catalog) via a service in namespace a caBundle in the APIService the external API server with a certificate signed for Result: Normal API requests (get/put/post) work as expected Normal watch requests work as expected Upgrade requests (e.g. websocket watch requests) return a 500 error with text like cc
Change:
for _, tc := range testCases { name := fmt.Sprintf("feature=%v,create=%v,update=%v", tc.featureGate, tc.create.flag, tc.update.flag) t.Run(name, func(t *testing.T) { <del> if testing.Short() && !tc.short { t.Skip("skipping expensive subtest") } </del> defer featuregatetesting.SetFeatureGateDuringTest(t, feature.DefaultFeatureGate, features.SuspendJob, tc.featureGate)() closeFn, restConfig, clientSet, ns := setup(t, "suspend")

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-integration-master I can't seem to find a match for beyond that? Most likely related to as it was merged during that set of commits Example Spyglass link: /cc /sig apps /priority critical-urgent /milestone v1.21
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
FYI: the error message is a red herring and isn't the real reason why this test is failing. When the integration tests are run with instead of , the mutation detector is also started, which catches a bug in the job controller where we modify the shared cache. This root cause isn't present in the logs, but you can reproduce this bug with the following command: Then apply the job controller patch in and re-run the test, you'll see that the test passes. You'll also notice that passes with/without the bug fix patch when run with . cc
Test is back on green. Thanks !
Change:
defer trace.LogIfLong(500 * time.Millisecond) if isDryRun(req.URL) && !utilfeature.DefaultFeatureGate.Enabled(features.DryRun) { <del> scope.err(errors.NewBadRequest("dryRun is not supported yet"), w, req) </del> <ins> scope.err(errors.NewBadRequest("the dryRun alpha feature is disabled"), w, req) </ins> return }

Discussion:
What happened: When a dry run request is made to a modifying endpoint, and the dry-run alpha feature is disabled, it returns the error message "dryRun is not supported yet" This was true in 1.11, but in 1.12, since the feature is in alpha now, the message should say something like "the dryRun alpha feature is disabled" /kind bug /sig api-machinery
Change:
op.result = result finished := time.Now() op.finished = &finished <del> close(op.notify) </del> <ins> op.notify <- true </ins> } // WaitFor waits for the specified duration, or until the operation finishes,

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When trying to mount an Azure File mount it fails, it looks as though its putting a new line between the name of the Azure Storage Account and the Azure storage domain. There are no new line characters in the secret that holds the account name. The following is the secret: The following is the declaration within the section of the Kubernetes yaml: The following is the error that's shown in `kubectl describe po/pod_name: 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: azure OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS Kernel (e.g. ): 4.13.0-1011-azure Install tools: Others:
/sig storage
/sig azure
It seems to me that does decode to , so it seems to be behaving correctly. Maybe it's a good idea to trim the return char for and fields after ?
is specified by user, so trim the is not a good idea in the code. Another simple way is to use kubectl create secret to create azure-secret, the accountname and key won't require base64 encoded, so you won't mess up with let me know if you have any question, thanks.
Thanks !
Bumped into this issue today too on our cluster. Can confirm command worked. Is there an easy way to time the /n off the end of the echo for before using base64? Thanks.
yes it's
Of course it is! Doh!
i think would've made better sense to trim the azurestorageaccountname value when receiving it... anyways the storage account name wont have n in them right? I think that just made better developer experience...
is not allowed in azure storage account name
so if azure storage account name does not allow in the name.. then why not just trim the name instead of error... Because devs would just and that would already have the n in the resulting base64-encoded string... right?
sounds reasonable /reopen
Reopened this issue.

<detailsIn response to : sounds reasonable /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
awesome. Thanks
so then this goes in to kube version 1.14.6 in AKS ? or how does this work?
It would only go into k8s v1.16.0 since it's not a critical bug, we don't want to do hot fix to the old release.
got it. thanks Andy.
Change:
{ Name:  name, Image: image, <del> Ports: []api.ContainerPort{{ContainerPort: 9376, HostPort: 8080}}, </del> <ins> Ports: []api.ContainerPort{{ContainerPort: 9376}}, </ins> }, }, },

Discussion:
Some of the e2e tests specify HostPort in their pod configurations. This can cause issues running those tests if the port is already in use.
We've been removing these over the last week and a half and I think that may be the only one left remaining.
We need to decide if HostPort is a supported use case for Kubernetes -- and if it's supported, then it needs e2e test coverage to ensure it remains functional. Note that supported and not-preferred are orthogonal. My understanding is that it's supported-but-not-preferred and that there are reasonable use cases for using it.
Change:
hostname       string nodeIP         net.IP portMapper     portOpener <ins> recorder       record.EventRecorder </ins> } type localPort struct {

Discussion:
When kube-proxy fails to open a nodeport, it gives up setting up the rest of the iptables rules for the service. Leaving the service not usable. Cannot even use it with clusterIP. Kube-proxy only logs this error in . No useful information can be retrieved with kubectl. Need to record a event at least.
Ideally would the changes be removed and then reported back? Is there a preferred log or place to return the error?
the event maybe a better solution; as other port maybe success.
Need to surface the problem somewhere. An event seems okay
, there's and in ; should we reuse it or create new recorders for ?
Just reuse it. After all, it is within the same component. Are you going to submit a PR?
sure, my pleasure.
Great! Thanks! Let me know when the PR is ready.
Change:
// Creates a name which can be reversed to identify both manifest id and container name. func manifestAndContainerToDockerName(manifest *api.ContainerManifest, container *api.Container) string { // Note, manifest.Id could be blank. <del> return fmt.Sprintf("%s--%s--%s--%x", containerNamePrefix, escapeDash(container.Name), escapeDash(manifest.Id), rand.Uint32()) </del> <ins> return fmt.Sprintf("%s--%s--%s--%08x", containerNamePrefix, escapeDash(container.Name), escapeDash(manifest.Id), rand.Uint32()) </ins> } // Upacks a container name, returning the manifest id and container name we would have used to

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /sig cluster-lifecycle /cc /priority critical-urgent /milestone v1.19
Change:
if found != nil { return found, nil } <del> return nil, fmt.Errorf("GCE persistent disk not found: %q", diskName) </del> <ins> return nil, fmt.Errorf("GCE persistent disk %q not found in managed zones (%s)", diskName, strings.Join(gce.managedZones, ",")) </ins> } // GetGCERegion returns region of the gce zone. Zone names

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-alpha.3.317+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-01T05:48:36Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-alpha.3.317+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-01T05:48:36Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64"} What happened: Dynamic provisioned volumes in different zones with master failed to deleted What you expected to happen: Since the volume can be dynamic provisioned when the zones differs from master, then it should be deleted after delete the PVC which created them. How to reproduce it (as minimally and precisely as possible): up an all-in-one cluster. The instance is created in zone us-central1-a. several storageClass. One in zone us-central1-a. Another in zone us-central1-b. several PVC. pvc1 using storageClass1(zone us-central1-a), pvc2 using storageClass2(zone us-central1-b). PV/volume were provisioned in proper size/mode/zone. PVCs. with volume in zone us-central1-b failed with error can not find the volume.

Anything else do we need to know: Name: pvc--70d1-11e6-b17e- Labels: failure- failure- Status: Failed Claim: default/pvc5 Reclaim Policy: Delete Access Modes: RWO Capacity: 4Gi Message: Delete of volume "pvc--70d1-11e6-b17e-" failed: GCE persistent disk not found: "kubernetes-dynamic-pvc--70d1-11e6-b17e-" Source: Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine) PDName: kubernetes-dynamic-pvc--70d1-11e6-b17e- FSType: Partition: 0 ReadOnly: false Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message 11m 11m 1 {persistentvolume-controller } Warning VolumeFailedDelete Delete of volume "pvc--70d1-11e6-b17e-" failed: GCE persistent disk not found: "kubernetes-dynamic-pvc--70d1-11e6-b17e-" creationTimestamp: '2016-09-01T22:49:26.439-07:00' description: '{"":"pvc--70d1-11e6-b17e-","":"pvc5","":"default"}' id: '' kind: compute#disk name: kubernetes-dynamic-pvc--70d1-11e6-b17e- selfLink: sizeGb: '4' status: READY type: zone:
Kubernetes can delete GCE PDs only in zones it manages. I.e. either in the same zone as the master or, when multizone is enabled in GCE config, in all zones in the same region. This should not be allowed in the first place. Kubernetes should not create disks outside zones it manages and report an error instead. So... please use following , it will be allow creation/deletion of disks in all zones in us-central1 region: And I'll fix Kubernetes to report an error when creating a disk in all other zones.
Change:
} } <del> // WithRunAllFilters sets the runAllFilters flag, which means RunFilterPlugins accumulates // all failure Statuses. func WithRunAllFilters(runAllFilters bool) Option { return func(o *frameworkOptions) { o.runAllFilters = runAllFilters } } </del> // WithPodNominator sets podNominator for the scheduling frameworkImpl. func WithPodNominator(nominator framework.PodNominator) Option { return func(o *frameworkOptions) {

Discussion:
Since scheduler Policy API was total removed, we don't support any more. Remove unsupported configuration.
/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
/sig scheduling /cc
/sig scheduling (trying to tell the bots to remove )
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /remove-needs sig /remove-label needs-sig 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
It's true scheduler doesn't quite use this field anymore, but I'm wondering if some other project like ClusterAutoscaler or simulator still consumes this via .
There's no place we can config this field now by configure file(before we can apply the change by policy api, but now it's removed). So it seems like unless we support this feature with CC, or this field is useless. To other projects, it's the same. When they are using legacy policy api, they can configure this field, but once they synced with the latest kubernetes, with the policy api removed, they can not configure this anymore. In this situation, we should add support in CC. I don't quite understand the relationship between k/k with k/autoscaling or others, I think they sync with k/k periodic.
As I mentioned above, it's still accessible via a framework runtime programmatically, and thus may be still useful. For example, upon a scheduling failure, a ClusterAutoscaler's implementation may choose to dryrun through all filter plugins to ensure a new provisioned node can fit the pod, instead of resolving the failure while failing at another latter filter plugin.
Oh, I haven't thought of configuration via programmatically, that saved my concern. But a little strange.
That's exactly what I meant. Given it's a public option in framework, and there is no alternative if we disabled it, it'd be good to check with potential consumers.

For now I can think of CA ( and k-sigs/scheduler-simulator ( If they can confirm it's not needed in their usecases, I'm fine with removing .
To k/autoscaler, at least these codes are still there together with the legacy policy api. , looking forward to the response.
is not used in sigs/kube-scheduler-simulator. ‍
this isn't used by cluster autoscaler, we can remove it.