jiebi/CodeConvo huggingface dataset:
Change:
requests: cpu: 100m env: <del> - name: ELASTICSEARCH_URL </del> <ins> - name: ELASTICSEARCH_HOSTS </ins> value: http://elasticsearch-logging:9200 <ins> - name: SERVER_NAME value: kibana-logging </ins> - name: SERVER_BASEPATH value: /api/v1/namespaces/kube-system/services/kibana-logging/proxy <ins> - name: SERVER_REWRITEBASEPATH value: "false" </ins> ports: - containerPort: 5601 name: ui

Discussion:
What happened: On latest fluentd-elasticsearch, the elasticsearch replicas seems failed to form a valid cluster with the service discovery helper written in golang. What you expected to happen: Successfully boot up an elasticsearch cluster I guess. How to reproduce it (as minimally and precisely as possible): Just use the yamls in and the elasticsearch-logging pods will keep spamming warning messages. I think thats because options are deprecated in elasticsearch 7.x.x Anything else we need to know?: IMHO I think thats all. Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig instrumentation
Thanks
Change:
apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" <ins> utilrand "k8s.io/apimachinery/pkg/util/rand" </ins> "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" watch "k8s.io/apimachinery/pkg/watch" <ins> "k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/plugin/pkg/admission/serviceaccount" "k8s.io/kubernetes/test/e2e/framework" e2ekubectl "k8s.io/kubernetes/test/e2e/framework/kubectl"

Discussion:
[X] Test approval issue: [X] Test PR: 5 Oct 2022 [X] Two weeks soak end date: 19 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still three remaining LimitRange endpoints which are untested. replaceCoreV1NamespacedServiceAccount Using a number of existing e2e test practices a new has been created for one ServiceAccount endpoint. The e2e logs for this test are listed below. This query shows which ServiceAccount endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
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
Change:
func TestGetZone(t *testing.T) { cloud := &Cloud{ Config: Config{ <del> Location: "eastus", </del> <ins> Location:            "eastus", UseInstanceMetadata: true, </ins> }, } testcases := []struct {

Discussion:
What happened: Currently starting Kubectl failing on Azure Stack. What you expected to happen: Kubectl should start on Azure Stack environment. How to reproduce it (as minimally and precisely as possible): Try to deploy Kubernets on Azure Stack environment.. Anything else we need to know?: Environment: Kubernetes version (use kubectl version): master Cloud provider or hardware configuration: OS (e.g: cat /etc/os-release): Kernel (e.g. uname -a): Install tools: Others: /sig azure /assign
is it ? is a tool ...
my bad its kubelet. I update the title.
then could you provide the kubelet log? I am not sure kubelet on Azure stack is running as a container or process, you could get the logs by: And how do you deploy k8s on azure stack? cc
Change:
"fmt" "io" "net" <ins> "strings" </ins> "time" csipbv1 "github.com/container-storage-interface/spec/lib/go/csi" "google.golang.org/grpc" api "k8s.io/api/core/v1" utilversion "k8s.io/apimachinery/pkg/util/version" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/klog" "k8s.io/kubernetes/pkg/features"

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: If kubelet plugin registration fails during the registration process, the kubelet never attempts to register the socket again (assuming the error was transient), unless the socket for the driver is deleted & recreated to trigger a new registration. What you expected to happen: Maybe retry with exponential backoff when kubelet plugin registration fails instead of just logging and waiting for another filesystem event like it does today. Of course, if a socket returns a terminal error (does not implement the kubelet plugin registration service, for example), we should not retry. Follow up on /milestone v1.14 /sig storage 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: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
I'd like to work on this issue
/assign
Re opening. was a temporary work around for this. is the permanent fix.
Hello! We are starting Bug Freeze for 1.15. Is this issue still planned on being incorporated into 1.15?
the dependent PR is not yet merged. can we get this in for 1.15?
said that is the "permanent fix." and that has merged. So let's close this out /close
Closing this issue. <detailsIn response to : said that is the "permanent fix." and that has merged. So let's close this out 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:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> componentbaseconfig "k8s.io/component-base/config" )

Discussion:
What would you like to be : Actually disable scheduler plugins according to the disabled list in the scheduler's component config. The semantics are defined here: Part of /sig scheduling /priority important-soon /assign
The following semantics seems vague, and I think we should reach consensus on some cases when disabled plugins are involved. Suppose we have two default plugins, and , the runs before , here are the cases we could meet with the scheduling framework, plugins which run after all the default plugins plugins which should run ahead of the plugins plugin which should run ahead of all the plugins -enable default or custom plugin should return errors
Do you have any other cases not mentioned here?
Those cases sound right, I don't have others.
Is this actually what we want? I don't think so. The comment needs rewording.
I plan to revisit the comments after
Change:
SelfLink          string    `json:"selfLink,omitempty" yaml:"selfLink,omitempty"` ResourceVersion   uint64    `json:"resourceVersion,omitempty" yaml:"resourceVersion,omitempty"` APIVersion        string    `json:"apiVersion,omitempty" yaml:"apiVersion,omitempty"` <del> Namespace         string    `json:"namespace",omitempty" yaml:"namespace,omitempty"` </del> <ins> Namespace         string    `json:"namespace,omitempty" yaml:"namespace,omitempty"` </ins> // Annotations are unstructured key value data stored with a resource that may be set by // external tooling. They are not queryable and should be preserved when modifying

Discussion:
For example: struct field tag not compatible with reflect.StructTag.Get missing argument for Errorf("%v"): format reads arg 2, have only 1 args range variable pod enclosed by function struct field tag not compatible with reflect.StructTag.Get arg minion for printf verb %s of wrong type: unreachable code unreachable code
Those all look really important
I'm going to fix this unless I hear that someone else is working on this in the next couple minutes.
Change:
<ins> { "Rules": [ { "SelectorRegexp": "k8s[.]io/kubernetes/test/e2e", "AllowedPrefixes": [] } ] } </ins>

Discussion:
What happened: Integration tests import e2e test code today and the dependency makes two drawbacks. It is hard to move test/e2e/framework into staging () Need to run integration tests always even if PRs are just changing e2e test code This PR is for removing this dependency from integration tests. Target dependencies Following files are importing e2e test code from integration tests: [x] () [x] () [x] () and we need to put file for blocking such dependency anymore.
/sig testing /area code-organization
/remove-kind bug
/assign
for /assign
Change:
expectedStatusCode: http.StatusInternalServerError, expectedBody:       "missing user", }, <del> "proxy with user": { </del> <ins> "proxy with user, insecure": { </ins> user: &user.DefaultInfo{ Name:   "username", Groups: []string{"one", "two"},

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:
test.run(t) } <ins> func TestUnsetUnexistConfig(t *testing.T) { conf := clientcmdapi.Config{ Kind:       "Config", APIVersion: "v1", Clusters: map[string]*clientcmdapi.Cluster{ "minikube":   {Server: "https://192.168.99.100:8443"}, "my-cluster": {Server: "https://192.168.0.1:3434"}, }, Contexts: map[string]*clientcmdapi.Context{ "minikube":   {AuthInfo: "minikube", Cluster: "minikube"}, "my-cluster": {AuthInfo: "mu-cluster", Cluster: "my-cluster"}, }, CurrentContext: "minikube", } test := unsetConfigTest{ description: "Testing for kubectl config unset a unexist map key", config:      conf, args:        []string{"contexts.foo.namespace"}, expectedErr: "current map key `foo` is invalid", } test.run(t) } </ins> func (test unsetConfigTest) run(t *testing.T) { fakeKubeFile, err := ioutil.TempFile(os.TempDir(), "") if err != nil {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5.3 Environment: Cloud provider or hardware configuration: minikube 0.17.1 How to reproduce it (as minimally and precisely as possible): config Note that there's only one context. the property of a non-existent context config Note that a context named foo was created just because I tried to unset a property. What you expected to happen: should give an informative message saying that context doesn't exist. Anything else we need to know: This is probably low-hanging fruit.
/sig cli
/assign i will take a look for this
GitHub didn't allow me to assign the following users: a, look, for, this, i, will, take. Note that only can be assigned. <detailsIn response to : /assign i will take a look for this 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
i can reproduce this, this is a bug, have open PR fix this. thanks
/kind bug
Change:
gidStr := strconv.FormatInt(int64(gid), 10) pv.Annotations = map[string]string{ <del> volumehelper.VolumeGidAnnotationKey:        gidStr, volumehelper.VolumeDynamicallyCreatedByKey: heketiAnn, glusterTypeAnn:                             "file", "Description":                              glusterDescAnn, v1.MountOptionAnnotation:                   "auto_unmount", </del> <ins> volumehelper.VolumeGidAnnotationKey: gidStr, "kubernetes.io/createdby":           "heketi-dynamic-provisioner", "gluster.org/type":                  "file", "Description":                       "Gluster: Dynamically provisioned PV", v1.MountOptionAnnotation:            "auto_unmount", </ins> } pv.Spec.Capacity = v1.ResourceList{

Discussion:
several operations to the glusterfs mount operation that nodes are not permitted to perform: looks up arbitrary secrets based on storage class parameters. this will not succeed, as the node authorizer will only allow nodes access to secrets referenced by pods or persistent volumes used by the node attempts to create a service and endpoint using the node's API client. nodes do not have permission to create arbitrary endpoints and services. For both of those reasons, that recreate operation will fail when attempted from the node. The recreate operation should probably move to one of the storage-related controllers (provisioner or attach/detach) cc
Marking this with 1.7 milestone until we have a better idea of whether this is blocking or not for the 1.7 release.
CC Is the endpoint originally created by the user or by the volume plugin creating/deleting Endpoint objects? In addition to the concerns raised, having a volume create new API objects seems like a bad idea (abstraction layer violation?).
From on Slack: Unless there is justification otherwise, I will roll back the PR on Monday.
cc/
revert button doesn't work, have to do it manually
Revert PR is approved and awaiting merge (). Once that merges this issue can be closed.
Opened an E2E pr to catch this kind of behavior in the future. WIP, still exploring a method to reproduce and catch the behavior.
Change:
return fmt.Errorf("error writing to %q: %v", filePath, err) } } else { <del> framework.Logf("nnTest Suite Metrics:n%snn", metricsJSON) </del> <ins> framework.Logf("nnTest Suite Metrics:n%sn", metricsJSON) </ins> } return nil

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is always appending a new line to its message: In some places of code, the message is already has a newline character and it leads to doubled new lines in the logs. What you expected to happen: I'm not sure what is the correct behavior here. One of the options could be to append a new line conditionally.
/sig testing
I'm new to Kubernetes and would like to start contributing. Is it ok if I assign myself this issue?
/assign MorrisLaw
GitHub didn't allow me to assign the following users: MorrisLaw. Note that only can be assigned. <detailsIn response to : /assign MorrisLaw 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
I can't assign this to myself, as I am not a member yet. But I am still going to take this issue.
I'll help him on reviews so assigning.
Change:
import ( "fmt" <ins> "runtime" </ins> "strings" "testing" "time"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When running , and passing the flag which was introduced in , the following error occurs: What you expected to happen: The proxy should work as it used to, supporting this mode. How to reproduce it (as minimally and precisely as possible): ./kube- --proxy-mode=kernelspace Anything else we need to know?: This was introduced after the validation was refactored in which regressed validation for . IPVS validation (and thus support) was later , but we need another mode for Windows. Environment: Kubernetes version (use ): v1.10.0-alpha.0.684+ Cloud provider or hardware configuration: n/a OS (e.g. from ): Windows Server Core 1709 Kernel (e.g. ): Install tools: Others:
/sig windows /sig network
Tentatively adding milestone so we can track getting consensus on release-blocking status.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
// We shouldn't get here. PreFilter already checked this. return statusUnschedulable(logger, "resourceclaim must be reallocated", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim)) case claim.Spec.AllocationMode == resourcev1alpha2.AllocationModeWaitForFirstConsumer: <del> // The ResourceClass might have a node filter. This is // useful for trimming the initial set of potential // nodes before we ask the driver(s) for information // about the specific pod. class, err := pl.classLister.Get(claim.Spec.ResourceClassName) if err != nil { // If the class does not exist, then allocation cannot proceed. return statusError(logger, fmt.Errorf("look up resource class: %v", err)) } if class.SuitableNodes != nil { // TODO (#113700): parse class.SuitableNodes once in PreFilter, reuse result. matches, err := corev1helpers.MatchNodeSelectorTerms(node, class.SuitableNodes) if err != nil { return statusError(logger, fmt.Errorf("potential node filter: %v", err)) </del> <ins> if selector := state.informationsForClaim[index].availableOnNode; selector != nil { if matches := selector.Match(node); !matches { return statusUnschedulable(logger, "excluded by resource class node filter", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclassName", claim.Spec.ResourceClassName) </ins> } <del> if !matches { return statusUnschedulable(logger, "excluded by resource class node filter", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclass", klog.KObj(class)) } } // Now we need information from drivers. schedulingCtx, err := state.initializePodSchedulingContexts(ctx, pod, pl.podSchedulingContextLister) if err != nil { return statusError(logger, err) </del> } <del> status := statusForClaim(schedulingCtx, pod.Spec.ResourceClaims[index].Name) if status != nil { </del> <ins> if status := state.informationsForClaim[index].status; status != nil { </ins> for _, unsuitableNode := range status.UnsuitableNodes { if node.Name == unsuitableNode { return statusUnschedulable(logger, "resourceclaim cannot be allocated for the node (unsuitable)", "pod", klog.KObj(pod), "node", klog.KObj(node), "resourceclaim", klog.KObj(claim), "unsuitablenodes", status.UnsuitableNodes)

Discussion:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign
Change:
"//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apiserver/pkg/server/storage:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/flag:go_default_library", <ins> "//vendor/k8s.io/klog:go_default_library", </ins> ], )

Discussion:
https://k8s- sample failure: (also affecting other CI jobs) cc /sig gcp
/assign We're interested in disabling the job as blocking entirely. We're of the opinion this shouldn't have bee allowed to block the community in the first place. I swear there's a historical issue around tightening the regex somewhere.
... wrong button sorry about that
possibly caused by erroring on invalid values that were previously silently skipped opened to downgrade that error to a warning for a release
Well, I mentioned the idea of making the job optional in
PR out to drop the runifchanged regex from pull-kubernetes-e2e-gke
Confirmed turns the test green
Can call this closed when merges
/pony hooray
Couldn't find a pony matching that query. <detailsIn response to : /pony hooray 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:
if len(v) > 0 { out, err := b.exec.Run("iscsiadm", "-m", "discoverydb", "-t", "sendtargets", "-p", tp, "-I", b.Iface, "-o", "update", "-n", k, "-v", v) if err != nil { <del> return fmt.Errorf("iscsi: failed to update discoverydb key %q with value %q error: %v", k, v, string(out)) </del> <ins> return fmt.Errorf("iscsi: failed to update discoverydb key %q error: %v", k, string(out)) </ins> } } }

Discussion:
This issue was reported in the Description Kubernetes can be configured to use iSCSI volumes. When using CHAP authentication, CHAP secrets are stored using the Secrets API, such as in this . When a pod is configured to use iSCSI and the AttachDisk method is called, this will call the code in Figure 1. Figure 19.1: iSCSI secret handling These two functions both iterate over a slice of strings that are keys that reference secrets in a map. These are then used to generate iscsiadm commands. As shown, if there are errors in executing these commands, errors are returned with both the key and secret values in the error string. These errors will eventually be logged using klog: Someone with access to these logs would be able to view the sensitive secrets and could potentially gain access to iSCSI volumes. Exploit Scenario Alice runs a cluster, and wishes to use iSCSI for data storage. Eve has access sufficient to collect the logs, and uses this access to connect to iSCSI storage devices as a privileged user. Recommendation Short term, as in TOB-K8S-001: Bearer tokens revealed in logs, do not log sensitive credentials at any logging level, as they may accidentally leak into inappropriate environments, such as production. Long term, implement policies that enforce code review to ensure that sensitive data is not exposed in logs, or implement logging filters that check for sensitive data and remove it prior to reification within logs. In either case, ensure that sensitive data cannot be stored in logs. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of ATR-K8S-003 and it was finding 22 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 61 of the Environment: Kubernetes version: 1.13.4
/sig storage /area security /kind bug /remove-kind feature
Change:
serv.Timeout = uint32(svcInfo.StickyMaxAgeSeconds) } if err := proxier.syncService(svcNameString, serv, true); err == nil { <ins> // check if service need skip endpoints that not in same host as kube-proxy onlyLocal := svcInfo.SessionAffinityType == api.ServiceAffinityClientIP && svcInfo.OnlyNodeLocalEndpoints </ins> activeIPVSServices[serv.String()] = true <del> if err := proxier.syncEndpoint(svcName, svcInfo.OnlyNodeLocalEndpoints, serv); err != nil { </del> <ins> if err := proxier.syncEndpoint(svcName, onlyLocal, serv); err != nil { </ins> glog.Errorf("Failed to sync endpoint for service: %v, err: %v", serv, err) } } else {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The test is flaky with the error something like: What you expected to happen: Test should pass /assign
/sig network /area ipvs
/close
Cases are green now. :tada: