jiebi/CodeConvo huggingface dataset:
Change:
], importmap = "k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/errors", importpath = "k8s.io/apimachinery/pkg/util/errors", <ins> deps = ["//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library"], </ins> ) filegroup(

Discussion:
What happened: I configured my API server with a Webhook token authentication server by way of the "authentication-token-webhook-config-file" command-line flag, and confirmed that the API server does pass bearer tokens through, issuing HTTP POST requests with a JSON-encoded body. When my Webhook server indicates authentication failure, it responds with HTTP status code 200 and a JSON-encoded in the body, this time with the object's "Error" field populated. Here's an example: When the API server receives this response, it refuses the original motivating request with an HTTP status code 401 response, but the API server writes the following into its log file: This use of this default error message is due to an omission in file , where , and . What you expected to happen: The API server should instead log a message that includes the value from . Per a brief discussion with , he agreed that the API server log message should include such an error message from the Webhook server, provided it's present and nonempty. How to reproduce it (as minimally and precisely as possible): Configure an API server to delegate to a Webhook token authentication server. Force that Webhook server to respond "successfully" with an HTTP 200 response, but with the "Authenticated" field set to false (or omitted) and with a particular error message in the "Error" field. Make an HTTP request of the API server with an HTTP "Authentication" header with a value starting with the string "Bearer " followed by at least one more character. Inspect the logs from the API server, looking for a message that begins with "Unable to authenticate the request due to an error." Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS EC2 OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: kubeadm_
/sig auth
/assign
Change:
framework.ConformanceIt("should adopt matching pods on creation and release no longer matching pods", func() { testRSAdoptMatchingAndReleaseNotMatching(f) }) <ins> ginkgo.It("Replicaset should have a working scale subresource", func() { testRSScaleSubresources(f) }) </ins> }) // A basic test to check the deployment of an image using a ReplicaSet. The

Discussion:
[x] two weeks soak end date : 26 Feb 2021 According to this APIsnoop query, there are still some remaining RESOURCENAME endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a ReplicaSet with a static label Read the ReplicaSetScale Update the ReplicaSetScale Get the ReplicaSetScale to ensure it is updated Patch the ReplicaSetScale Read the ReplicaSetScale to ensure it is Patch Delete the Namespace and ReplicaSet Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent ----------------------------------------|
patchAppsV1NamespacedReplicaSetScale | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet Replicaset should have a working scale subresource readAppsV1NamespacedReplicaSetScale | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet Replicaset should have a working scale subresource replaceAppsV1NamespacedReplicaSetScale | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet Replicaset should have a working scale subresource (3 rows) If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture
/triage accepted
Presented in Conformance meeting of 9 Feb 2021 and it was agreed that that method see to achieve the purpose and a PR can be created. A similar approach would be taken for the DepoymentScale endpoints.
/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:
name = "go_default_library", srcs = ["flock_unix.go"], tags = ["automanaged"], <del> deps = ["//vendor:golang.org/x/sys/unix"], </del> ) filegroup(

Discussion:
BUG REPORT: Kubernetes version latest master: Environment: Ubuntu 16.04 LTS, Linux 4.2.0-42-generic: What happened: The doesn't provide mutual exclusion. Two processes can both grab the same flock at the same time. What you expected to happen: Only one process should be able to grab the flock. How to reproduce it (as minimally and precisely as possible): Anything else we need to know: Although the flock doesn't work, the does work. Since we usually specify together with , so the 1st process will exit anyway. However we still need to fix the flock..
cc
Sent a PR to fix this ()
Change:
go_test( name = "go_default_test", <del> srcs = ["insecure_serving_test.go"], </del> <ins> srcs = [ "insecure_serving_test.go", "options_test.go", ], </ins> embed = [":go_default_library"], deps = [ "//cmd/controller-manager/app/options:go_default_library",

Discussion:
/kind bug /sig scheduling What happened: kube-scheduler that is pointed to a componentconfig file having ignores that it should use this kubeconfig file. Instead, it uses the in-cluster config (as is neither provided). What you expected to happen: The kube-scheduler should respect the kubeconfig provided in the . How to reproduce it (as minimally and precisely as possible): Starting image with whereby the content of looks like this: makes the scheduler logging The exact same configuration as above works with branch. Seems like has introduced the behaviour. The kube clients are created but the componentconfig file is loaded . /cc Environment: Kubernetes version (use ): 1.11.0-rc.2
/milestone v1.11 for triage
Could you please take a look at this? It seems related to the changes you made recently.
/assign
/assign /priority critical-urgent bumping priority since this would be a 1.11 regression
[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:
pv:            testVolumeWithNodeAffinity(t, &v1.VolumeNodeAffinity{}), }, { <del> name:          "valid-constraints", </del> <ins> name:          "select-nothing", expectSuccess: false, pv:            testVolumeWithNodeAffinity(t, &v1.VolumeNodeAffinity{Required: &v1.NodeSelector{}}), }, { name:          "select-nothing-empty-terms", expectSuccess: false, pv: testVolumeWithNodeAffinity(t, &v1.VolumeNodeAffinity{ Required: &v1.NodeSelector{ NodeSelectorTerms: []v1.NodeSelectorTerm{ { MatchExpressions: []v1.NodeSelectorRequirement{}, }, }, }, }), }, { name:          "valid-multiple-terms", expectSuccess: true, pv: testVolumeWithNodeAffinity(t, &v1.VolumeNodeAffinity{ Required: &v1.NodeSelector{ NodeSelectorTerms: []v1.NodeSelectorTerm{ { MatchExpressions: []v1.NodeSelectorRequirement{ { Key:      "test-key3", Operator: v1.NodeSelectorOpIn, Values:   []string{"test-value1", "test-value3"}, }, }, }, { MatchExpressions: []v1.NodeSelectorRequirement{ { Key:      "test-key2", Operator: v1.NodeSelectorOpIn, Values:   []string{"test-value0", "test-value2"}, }, }, }, }, }, }), }, { name:          "valid-multiple-match-expressions", </ins> expectSuccess: true, pv: testVolumeWithNodeAffinity(t, &v1.VolumeNodeAffinity{ Required: &v1.NodeSelector{

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /assign What happened: The terms are ANDed, which is not correct:
cc
Change:
obj := &corev1.Pod{} newObj, err := f.Apply(obj, []byte(`{ <del> "apiVersion": "v1", </del> <ins> "apiVersion": "apps/v1", </ins> "kind": "Deployment", "metadata": { "name": "b",

Discussion:
What happened: When sending a request to the server side apply endpoint (), if the apiVersion provided in the object is different from the apiVersion in the url, it returns a 500 error, like: What you expected to happen: The request should fail if the apiVersion provided in the object is different from the apiVersion in the url, but it should fail before trying to merge, and be a 4xx error. Probably a bad request error. Anything else we need to know?: The check should probably be done somewhere near this . The issue, though, is that the patch is given as a byte array, and needs to be deserialized into an object to access the apiVersion field. How to reproduce it (as minimally and precisely as possible): With a kube-apiserver built from head, running with :
/kind bug /sig api-machinery /wg apply /priority important-longterm /assign
Change:
RevisionHistoryAnnotation:      true, DesiredReplicasAnnotation:      true, MaxReplicasAnnotation:          true, <del> OverlapAnnotation:              true, </del> } // skipCopyAnnotation returns true if we should skip copying the annotation with the given annotation key

Discussion:
The Deployment overlap annotation () is no longer populated nor used by 1.6+ on the server side. However, in we maintained knowledge of the annotation for 1.6 clients in case they talk to pre-1.6 servers. That PR also adds code to clean up the annotation whenever it's found in 1.6+ clusters, so that pre-1.6 clients don't see it and make the wrong assumptions. The code handling this annotation should be removed when all the following conditions are met: We no longer support a 1.5.x client talking to the latest server version. We no longer support upgrading the server directly from 1.5.x to the latest version. The soonest milestone that meets both conditions according to the is v1.8. This issue should be moved to that milestone once it exists.
TODOs: [x] deployment controller: [x] deployment util: [x] deployment reaper: [x] deployment describer:
I can help on this
/assign
GitHub didn't allow me to assign the following users: wanghaoran1988. Note that only can be assigned. <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
thanks, feel free to send patches
Change:
file := corev1.PersistentVolumeFilesystem goldClassName := "gold" now := time.Now() <del> deletionTimestamp := metav1.Time{Time: time.Now().UTC().AddDate(10, 0, 0)} </del> <ins> deletionTimestamp := metav1.Time{Time: time.Now().UTC().AddDate(-10, 0, 0)} </ins> testCases := []struct { name               string pvc                *corev1.PersistentVolumeClaim

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: Kubectl describe pv xxx shows last<invalidif pv is terminating ! I found pvc and pod have the same issue What you expected to happen: Terminating (lasts 10s) How to reproduce it (as minimally and precisely as possible): 1 create a pv, pvc or pod is terminating 2 using kubectk describe xxx Anything else we need to know?: Environment: Kubernetes version (use ): 1.13.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig cli
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
Change:
// zone based on pod labels. }) <del> ginkgo.Describe("GCE [Slow] [Feature:NEG]", func() { </del> <ins> ginkgo.Describe("GCE [Slow] [Feature:NEG] [Flaky]", func() { </ins> var gceController *gce.IngressController // Platform specific setup

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Timeout while - trying to gave a 404 or 502 Anything else we need to know: 4 flakes in the past week: Triage: /sig network <!-- Please see the deflaking doc () for more guidance! --
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
Hi and any update on this ?
/assign
Minhan -- can you take a look?
/triage accepted
Looks like the LB did not stabilize before timeout. Still looking. We are considering disabling some of the tests here
This test is still flaking a bit -- recent failures from the past 2 days:
It looks like this test is still flaking quite frequently: Any ideas on how to move forward?
I will start disabling the tests.
Change:
func (t *prefixTransformers) TransformToStorage(ctx context.Context, data []byte, dataCtx Context) ([]byte, error) { start := time.Now() transformer := t.transformers[0] <del> prefixedData := make([]byte, len(transformer.Prefix), len(data)+len(transformer.Prefix)) copy(prefixedData, transformer.Prefix) </del> result, err := transformer.Transformer.TransformToStorage(ctx, data, dataCtx) RecordTransformation("to_storage", string(transformer.Prefix), start, err) if err != nil { return nil, err } <ins> prefixedData := make([]byte, len(transformer.Prefix), len(result)+len(transformer.Prefix)) copy(prefixedData, transformer.Prefix) </ins> prefixedData = append(prefixedData, result...) return prefixedData, nil }

Discussion:
The code at: assumes that the transformation does not change the size of the data. Since we know it most cases that it does, we should try to account for that during the allocation.
/sig auth
/triage accepted
/assign
I think there is no problem with the memory allocation of , because needs to be executed afterwards, in order to avoid executing new memory allocation during append, so is no problem. IMO
After reading your code, I understand.
/assign
Change:
return result } <ins> // getCompletionMode returns string representation of the completion mode. Used as a label value for metrics. func getCompletionMode(job *batch.Job) string { if isIndexedJob(job) { return string(batch.IndexedCompletion) } return string(batch.NonIndexedCompletion) } </ins> func trackingUncountedPods(job *batch.Job) bool { return feature.DefaultFeatureGate.Enabled(features.JobTrackingWithFinalizers) && hasJobTrackingAnnotation(job) }

Discussion:
Occasionally job completions are counted twice (or potentially multiple times?) in the metric. This happens for about 20% of jobs, but may depend on the Job specificity, which results in an overestimation of the number of finished jobs. The metric reflects the actual number of completed jobs. a kind cluster with prometheus monitoring stack (for example follow this: ). the number of completed jobs by inspecting the metric and delete a job multiple times in a loop Example job: Example repro script: . Check the number of completed jobs by inspecting the metric and the job Yes, in the kube-controller-logs we find the following log lines which are related and probably indicate repeated updated which results in double counting. <details</details<detailsReproducible with kind </details<details</details<details</details<details</details<details</details
/assign
FYI
/sig apps
/triage accepted
Change:
return 0, framework.NewStatus(framework.Error, fmt.Sprintf("getting node %q from Snapshot: %v", nodeName, err)) } <del> meta := migration.PriorityMetadata(state) s, err := priorities.CalculateNodePreferAvoidPodsPriorityMap(pod, meta, nodeInfo) return s.Score, migration.ErrorToFrameworkStatus(err) </del> <ins> node := nodeInfo.Node() if node == nil { return 0, framework.NewStatus(framework.Error, "node not found") } controllerRef := metav1.GetControllerOf(pod) if controllerRef != nil { // Ignore pods that are owned by other controller than ReplicationController // or ReplicaSet. if controllerRef.Kind != "ReplicationController" && controllerRef.Kind != "ReplicaSet" { controllerRef = nil } } if controllerRef == nil { return framework.MaxNodeScore, nil } avoids, err := v1helper.GetAvoidPodsFromNodeAnnotations(node.Annotations) if err != nil { // If we cannot get annotation, assume it's schedulable there. return framework.MaxNodeScore, nil } for i := range avoids.PreferAvoidPods { avoid := &avoids.PreferAvoidPods[i] if avoid.PodSignature.PodController.Kind == controllerRef.Kind && avoid.PodSignature.PodController.UID == controllerRef.UID { return 0, nil } } return framework.MaxNodeScore, nil </ins> } // ScoreExtensions of the Score plugin.

Discussion:
/sig scheduling /priority important-soon See as an example. Part of This shouldn't need a PostFilter Plugin, it is not worth caching the result of metav1.GetControllerOf. /assign
Change:
elif [[ "${KUBE_FASTBUILD:-}" == "true" ]]; then host_arch=$(kube::util::host_arch) <del> if [[ "${host_arch}" != "amd64" && "${host_arch}" != "arm64" ]]; then # on any platform other than amd64 and arm64, we just default to amd64 </del> <ins> if [[ "${host_arch}" != "amd64" && "${host_arch}" != "arm64" && "${host_arch}" != "ppc64le" ]]; then # on any platform other than amd64, arm64 and ppc64le, we just default to amd64 </ins> host_arch="amd64" fi KUBE_SERVER_PLATFORMS=("linux/${host_arch}")

Discussion:
On a ppc64le host, fast build was failing: # make KUBEFASTBUILD=true quick-release +++ [0908 15:56:36] Verifying Prerequisites.... +++ [0908 15:56:36] Building Docker image kube-build:build--5-v1.23.0-go1.17-buster.0 +++ [0908 15:56:44] Syncing sources to container +++ [0908 15:56:48] Running build command... +++ [0908 15:56:56] Building go targets for linux/ppc64le: touch: cannot touch 'output/bin/prerelease-lifecycle-gen': No such file or directory make[2]: [Makefile.generatedfiles:209: output/bin/prerelease-lifecycle-gen] Error 1 make[1]: [Makefile:552: generatedfiles] Error 2 make: [Makefile:512: cross] Error 1 !!! [0908 15:56:58] Call tree: !!! [0908 15:56:58] 1: kube::build::runbuildcommandex(...) !!! [0908 15:56:58] 2: kube::build::runbuildcommand(...) make: [Makefile:454: quick-release] Error 1 This error happened because the output/bin/ directory didn't exist at the moment the file output/bin/prerelease-lifecycle-gen was touched, so the path didn't exist. The output/bin symlink was not created by kube::golang::placebins() because kube::golang::setupplatforms() assumed KUBECLIENT_PLATFORMS=linux/amd64 despite being on a ppc64le host.
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 release
looks like this is a missing feature and not a bug. /kind feature
Change:
echo "Adding $minion to hosts file" echo "$ip $minion" >> /etc/hosts fi <del> echo "127.0.0.1 localhost" >> /etc/hosts # enables cmds like 'kubectl get pods' on master. </del> done <ins> echo "127.0.0.1 localhost" >> /etc/hosts # enables cmds like 'kubectl get pods' on master. </ins> # Update salt configuration mkdir -p /etc/salt/minion.d

Discussion:
It's a small problem. Now in "/etc/hosts" of master in vagrant cluster, there are duplicate "127.0.0.1 localhost". Though it doesn't make any error, I think it's better to remove duplicate content.
Change:
readonly gcloud_supported_providers="gce gke" readonly master_logfiles="kube-apiserver.log kube-apiserver-audit.log kube-scheduler.log kube-controller-manager.log cloud-controller-manager.log etcd.log etcd-events.log glbc.log cluster-autoscaler.log kube-addon-manager.log konnectivity-server.log fluentd.log kubelet.cov" <del> readonly node_logfiles="kube-proxy.log containers/konnectivity-agent-*.log fluentd.log node-problem-detector.log kubelet.cov" </del> <ins> readonly node_logfiles="kube-proxy.log containers/konnectivity-agent-*.log fluentd.log node-problem-detector.log kubelet.cov kube-network-policies.log" </ins> readonly node_systemd_services="node-problem-detector" readonly hollow_node_logfiles="kubelet-hollow-node-*.log kubeproxy-hollow-node-*.log npd-hollow-node-*.log" readonly aws_logfiles="cloud-init-output.log"

Discussion:
,%20google-gce all I can't say , but at least a few weeks ,%20google-gce No response No response /sig network
/assign
/triage accepted
Change:
MinReplicas:        o.Min, MaxReplicas:        o.Max, CPUPercent:         o.CPUPercent, <del> ScaleRefName:       name, </del> <ins> ScaleRefName:       refName, </ins> ScaleRefKind:       mapping.GroupVersionKind.Kind, ScaleRefAPIVersion: mapping.GroupVersionKind.GroupVersion().String(), }, nil

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: the hpa name is always info.Namenot --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: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
/sig cli
Change:
{ name: "Remove node before its pods", operations: []operation{ <del> addNode(0), addNode(1), addPod(1), addPod(11), removeNode(1), updatePod(1), updatePod(11), removePod(1), removePod(11), </del> <ins> addNode(0), addNode(1), addPod(1), addPod(11), updateSnapshot(), removeNode(1), updateSnapshot(), updatePod(1), updatePod(11), removePod(1), removePod(11), </ins> }, expected: []*v1.Node{nodes[0]}, },

Discussion:
/sig scheduling What happened: reverted an old behavior to ensure Pod information is not lost when Nodes are recreated without its Pods getting recreated. A ghost Pod is kep in The problem is that we rely in this map for determining deleted Nodes when updating the snapshot in . The good thing is that the nodeinfo's are cloned into the snapshot, so we shouldn't have nil pointer accesses. But we might lose a few cycles trying to schedule on nodes that are deleted How to reproduce it (as minimally and precisely as possible): a node with a few pods. node without deleting pods. Result: The snapshot still has the node. Environment: Kubernetes version (use ): 1.18+
/assign
It actually produces the error: which would cause failed scheduling cycles (the map is not recreated, only the lists).