jiebi/CodeConvo huggingface dataset:
Change:
GCE_HOSTS= GCE_IMAGE_CONFIG_PATH=test/e2e_node/jenkins/image-config.yaml GCE_ZONE=us-central1-f <del> GCE_PROJECT=kubernetes-jenkins </del> <ins> GCE_PROJECT=k8s-jkns-ci-node-e2e </ins> CLEANUP=true GINKGO_FLAGS='--skip="[Flaky]|[Serial]"' SETUP_NODE=false

Discussion:
I want to isolate these in their own project:
Right now just the CI jobs, but after we also need to do this for the PR jobs.
Change:
return nil }) out.Write([]byte("nTo further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.n")) <del> return nil </del> <ins> return err </ins> // TODO consider printing more information about cluster }

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?: What happened: reports that the cluster is running and returns exit code 0. correctly identifies that the cluster is not running and exists with exit code 1. What you expected to happen: should fail when the cluster is not running. How to reproduce it (as minimally and precisely as possible): Start and stop a kubernetes cluster using minikube and then type kubectl cluster-info. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-28T22:57:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-06T20:53:14Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Local OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux Ubuntu16-HP-800 4.10.0-35-generic ~16.04.1-Ubuntu SMP Wed Sep 13 09:02:42 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: snap for kubectl. minikube local for k8s. Others:
/assign /sig cli
Change:
{"invalid number", "{+12.3.0}", "cannot parse number +12.3.0"}, {"unterminated array", "{[1}", "unterminated array"}, {"unterminated filter", "{[?(.price]}", "unterminated filter"}, <ins> {"invalid multiple recursive descent", "{........}", "invalid multiple recursive descent"}, </ins> } for _, test := range failParserTests { _, err := Parse(test.name, test.text)

Discussion:
What happened: This issue was originally reported via the Kubernetes HackerOne bug bounty by HackerOne user but we have decided that due to the high privileges required, it can be addressed publicly. A user able to create CRDs could create a malicious CRD such that listing CRs will cause enormous amounts of CPU usage on the API server. What you expected to happen: The function should not expand strings with more than two consecutive periods. Either it should collapse additional repeated periods or it should return an error. How to reproduce it (as minimally and precisely as possible): /kind bug /area apiserver /area security /committee product-security /priority important-longterm
How about we take it a step further by rejecting the jsonpath which contains when parsing it? as more than 2 periods seem to make no sense IMO
good idea. I have posted to do what you suggest.
/sig api-machinery
/cc
Change:
for _, taint := range node.Spec.Taints { if taint.Key == algorithm.DeprecatedTaintNodeNotReady { <del> // delete old taint </del> tDel := taint taintsToDel = append(taintsToDel, &tDel) <del> // add right taint </del> tAdd := taint tAdd.Key = algorithm.TaintNodeNotReady taintsToAdd = append(taintsToAdd, &tAdd) <ins> } </ins> <del> glog.Warningf("Detected deprecated taint key: %v on node: %v, will substitute it with %v", algorithm.DeprecatedTaintNodeNotReady, node.GetName(), algorithm.TaintNodeNotReady) </del> <ins> if taint.Key == algorithm.DeprecatedTaintNodeUnreachable { tDel := taint taintsToDel = append(taintsToDel, &tDel) </ins> <del> break </del> <ins> tAdd := taint tAdd.Key = algorithm.TaintNodeUnreachable taintsToAdd = append(taintsToAdd, &tAdd) </ins> } } if len(taintsToAdd) == 0 && len(taintsToDel) == 0 { return nil } <ins> glog.Warningf("Detected deprecated taint keys: %v on node: %v, will substitute them with %v", taintsToDel, node.GetName(), taintsToAdd) </ins> if !util.SwapNodeControllerTaint(nc.kubeClient, taintsToAdd, taintsToDel, node) { return fmt.Errorf("failed to swap taints of node %+v", node) }

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?: What happened: When discussing issue in , I noticed: although is using key , it has actually been changed to in for quite a while. I am thinking we may need to fix this inconsistency in 1.9, by moving out of alpha. Anything else we need to know?: Task tracker: [x] update [x] update kubernetes doc
/sig scheduling
Change:
func dataSourceIsEnabled(pvcSpec *core.PersistentVolumeClaimSpec) bool { if pvcSpec.DataSource != nil { <del> if pvcSpec.DataSource.Kind == pvc && *pvcSpec.DataSource.APIGroup == "" && utilfeature.DefaultFeatureGate.Enabled(features.VolumePVCDataSource) { </del> <ins> apiGroup := "" if pvcSpec.DataSource.APIGroup != nil { apiGroup = *pvcSpec.DataSource.APIGroup } if utilfeature.DefaultFeatureGate.Enabled(features.VolumePVCDataSource) && pvcSpec.DataSource.Kind == pvc && apiGroup == "" { </ins> return true } <del> if pvcSpec.DataSource.Kind == volumeSnapshot && *pvcSpec.DataSource.APIGroup == "snapshot.storage.k8s.io" && utilfeature.DefaultFeatureGate.Enabled(features.VolumeSnapshotDataSource) { </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(features.VolumeSnapshotDataSource) && pvcSpec.DataSource.Kind == volumeSnapshot && apiGroup == "snapshot.storage.k8s.io" { </ins> return true } }

Discussion:
What happened: While implementing the new VolumePVCDataSource feature I discovered that even though the we don't use APIGroup (the appropriate setting is ) if the APIGroup is omitted it results in a nil pointer exception on the API server. What you expected to happen: APIGroup should be able to be omitted from the spec How to reproduce it (as minimally and precisely as possible): Create a spec to create a clone of a PVC with out the APIGroup parameter in the DataSource spec: The result will be an nil pointer exception during the verification of the datasource field. Adding the APIGroup entry will address this as a work-around: Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-alpha.1.+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2019-06-12T22:12:02Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Install tools: local-up-
I have a simple fix, will post PR in a moment
/sig storage
/priority critical-urgent /milestone v1.15
Change:
apiVersion: v1 kind: Service metadata: <del> name: coredns </del> <ins> name: kube-dns </ins> namespace: kube-system labels: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile kubernetes.io/name: "CoreDNS" spec: selector: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> clusterIP: $DNS_SERVER_IP ports: - name: dns

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?: /kind bug What happened: e2e test "gci-gce" is running in 2 versions: with kube-dns as DNS Service : https://k8s- with CoreDNS as DNS Service : https://k8s- In CoreDNS use case the test is failing What you expected to happen: This e2e tests should not depend on what DNS service is running as default in K8s. CoreDNS is currently BETA, will move to GA soon (after v1.10 though) See : How to reproduce it (as minimally and precisely as possible): look at logs of dashboard : https://k8s- go run -v --test --test_args='--[sig-autoscaling]sDNSshorizontalsautoscalings[DisabledForLargeClusters]skube-dns-autoscalersshouldsscaleskube-dnsspodssinsbothsnonfaultysandsfaultysscenarios$' Anything else we need to know?: Environment: Kubernetes version (use ): branch master Cloud provider or hardware configuration: GCE Install tools: deployment intra-test Others: see https://k8s-
/sig autoscaling
/unsig cli
Looks like the test is searching specifically for a deployment labeled "kube-dns". There are several references to "kube-dns" scattered around it, actually.
Right now the tool "dns-horizontal-autoscaller" seems dedicated for kube-dns. This tools is deployed as "add-on" when enabled by this ENV variable : I guess we should have the definition of another dns-horizontal-autoscaller, dedicated to coredns (unless we generate the yaml file). and the choice of deployment is based on the ENV variable . see
Currently, the translation of the deployment of "dns-horizontal-autoscaller" for CoreDNS is in progress by It is expected that the corresponding e2e test will work as is (as the artifacts are selected by labels, which are the same for CroeDNS and kube-dns).
Change:
if t.Status.Reason == "AppArmor" { return true, nil } <ins> // Loading a profile not available on disk should return a container creation error if len(t.Status.ContainerStatuses) > 0 && t.Status.ContainerStatuses[0].State.Waiting.Reason == kuberuntime.ErrCreateContainer.Error() { return true, nil } </ins> } return false, nil })

Discussion:
Also appears to be failing on: Failures as of 01/05. /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon Guessing since all tests with apparmor started failing - maybe app armor config was removed or some PR submitted recently.
/assign
ci-cri-containerd-node-e2e-features Last green run: First failed run:
This () is the only PR merged in kubernetes during the time between: Test started yesterday at 8:11 PM passed after 13m50s. (more info) Test started yesterday at 9:11 PM failed after 16m6s. (more info) And it happens to be related to AppArmor:
Working on a fix in
Change:
}, { "kind":"None", <del> "metadata":{"name":"127.0.0.2"}, </del> <ins> "metadata":{ "name":"127.0.0.2", "labels":{ "kubernetes.io/hostname":"127.0.0.2" } }, </ins> "status":{ "capacity":{"cpu":"8"}, "addresses":[

Discussion:
I love using but I cannot figure out how to print an annotation that contains a special character like or or . This does not work: nor this: nor this: nor this: kubectl get pods tmp--dhpx0 -o jsonpath="{$['metadata']['annotations']['']}" (the last one should work according to what I can find about jsonPath, but doesn't, and anyhow is hard to get shell escaping right for. Need a way to quote a
A use case for this is extracting "created-by" or "init-container" annotations. I've wanted to do both in the last month and fought jsonpath.
FYI, this is possible with go-template. We should still fix the jsonpath though. Similar issue:
Change:
} } <ins> // Echo handler that returns the contents of request headers in the body headerEchoHandler := func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) output := "" for k, arr := range r.Header { for _, v := range arr { output += fmt.Sprintf("%s: %sn", k, v) } } w.Write([]byte(output)) } </ins> prober := New() testCases := []struct { handler    func(w http.ResponseWriter, r *http.Request) reqHeaders http.Header health     probe.Result accBody    string <ins> notBody    string </ins> }{ // The probe will be filled in below.  This is primarily testing that an HTTP GET happens. {

Discussion:
Grabbed tcpdump of a readiness probe - the src ip was the bridge address (10.244.1.1), but apart from this, there is no identifying information in the HTTP request that this is a Kubernetes daemon requesting readiness checks - this might help QoS/priority assignment by the container application.
IIUC, you mean we should add a better when kubernetes daemon request a readiness check to identify this request comes from kubernetes daemon?
Yes, we should override the default net/http user-agent with our own. Better usability for users and we have no future upgrade hazards if users start hardcoding and expecting this default User-Agent string in their analytic tools.
Any news about this one? It would be nice! I've this little hack in my nginx configuration (in order to not be spamed by health check in logs) :)
This can probably be closed now that probes have support.
Change:
"sort" "k8s.io/kubernetes/pkg/api/meta" <ins> "k8s.io/kubernetes/pkg/api/unversioned" </ins> "k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/integer" </ins> "k8s.io/kubernetes/pkg/util/jsonpath" "github.com/golang/glog"

Discussion:
I'd like to be able to sort by a timestamp, e.g. but that fails with an exception: I appreciate that the root of the problem is probably outside of kubernetes, yet I hope you'd agree that sorting by a timestamp is very useful functionality.
Agree with sorting by timestamp.. Just make it clear, is of type: while only these types are allowed to be sorted:
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/serializer" <ins> "k8s.io/apimachinery/pkg/runtime/serializer/json" </ins> utilruntime "k8s.io/apimachinery/pkg/util/runtime" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We face But there is no way to generate default config file How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version 1.9.2
I'll take a look it /sig scheduling
/assign
Hi, same issue with controller-manager
Any updates here? , and don't have this flag. Is it even will be supported?
/cc
if not set, component should be use default value; why we'd like to dump all default config?
Because the documentation on the config file format is either nonexistent or difficult to find. If the program itself can generate a template, that fulfills (most of) the need for documentation of the format.
+1 for this, from my expirence, add an option to write the default config is really helpful.
/assign
also in 1.10
Deprecating all flags, prompting folks to use config files in advance is great, except when there's no documentation nor example anywhere. That means that we can't actually migrate to the new settings, and I can't seem to find clear alpha/beta/stable status for the new config file spec, nor timeline for the removal. It is also pretty confusing that the scheduler expects us to use a config file, but the controller-manager does not?
This issue indeed applies to kube-controller-manager. And there should already had deprecation policy.
According to , the flag will be available in . Since I can't find any reference online to an example config file, perhaps one could be provided or linked to here?
will you be able to pick my patch and generate a config file? I do not get my devbox handy so can only post here until Monday.
Change:
Volumes       []Volume      `json:"volumes"` Containers    []Container   `json:"containers"` RestartPolicy RestartPolicy `json:"restartPolicy,omitempty"` <del> // Optional: Set DNS policy.  Defaults to "ClusterFirst" </del> <ins> // Required: Set DNS policy. </ins> DNSPolicy DNSPolicy `json:"dnsPolicy,omitempty"` // NodeSelector is a selector which must be true for the pod to fit on a node NodeSelector map[string]string `json:"nodeSelector,omitempty"`

Discussion:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc
Change:
} } <del> // CreateServicePods creates a replication controller with the label same as service </del> <ins> // CreateServicePods creates a replication controller with the label same as service. Service listens to HTTP. </ins> func (j *TestJig) CreateServicePods(c clientset.Interface, ns string, replica int) { config := testutils.RCConfig{ Client:       c,

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Following are two e2e testing service functioning over same port but different protocol, but do not test service reachability. be able to update NodePorts with two same port numbers but different protocols use same NodePort with same port but different protocols Note: Both the e2e are verifying the same behavior of "service using same port but different protocols" differs in and . Primary goal: Test service reachability for these E2Es. Secondary goal: As both the above e2e are verifying same E2E behavior, it's good to have single e2e in spite of 2 differing in "updating" and "create only" nodePort service. For "create only", suite has another specific e2e . Why is this needed: E2E Improvement and make e2e eligible for Conformance. Service related e2e are getting promoted in /area conformance /sig testing /assign
Change:
"k8s.io/kubernetes/pkg/api/v1" extensions "k8s.io/kubernetes/pkg/apis/extensions/v1beta1" "k8s.io/kubernetes/test/e2e/framework" <del> "k8s.io/kubernetes/test/e2e/generated" </del> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega"

Discussion:
xref: /sig node /area test
I am working on this.
Can you update this with the types of tests that you are adding? Is this similar to ?
No, this is for running the existing GPU e2e tests on GKE which are currently running on only GCE.
The referenced PRs appear to have merged, closing.
Change:
package core import ( <ins> "fmt" </ins> "testing" "time"

Discussion:
If a Pod is subjected to a with "PriortyClass" as its scope, the quota's calculation is incorrect. See repo steps for more details. with "PriortyClass" as its scope can be calculated at all times. Create a PriorityClass named "p1"Create a quota with as its scope. Note: w/o specifying , this issue won't happenCreate a Job and wait for its completion.Check quota's usage calculation Here is incorrect - it should be . Worse calculation may happen if I create a regular pod and then delete the Job:The eventual result is totally incorrect. No response master, and possibly all versions. kind <details</details<details</details<details</details<details</details
/sig api-machinery /kind bug
/triage accepted
I would like to take this up!
is already in flight for this
Change:
} } } <ins> func TestGetSelfLink(t *testing.T) { var testCases = []struct { desc             string name             string namespace        string expectedSelfLink string }{ { desc:             "No namespace specified", name:             "foo", namespace:        "", expectedSelfLink: "/api/v1/namespaces/default/pods/foo", }, { desc:             "Namespace specified", name:             "foo", namespace:        "bar", expectedSelfLink: "/api/v1/namespaces/bar/pods/foo", }, } for _, testCase := range testCases { selfLink := getSelfLink(testCase.name, testCase.namespace) if testCase.expectedSelfLink != selfLink { t.Errorf("%s: getSelfLink error, expected: %s, got: %s", testCase.desc, testCase.expectedSelfLink, selfLink) } } } </ins>

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): selflink kubelet selflink default selflink manifest selflink Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): admin kubectl version Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-04-27T10:00:30Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.7", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-04-27T09:42:05Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: AWS OS: Debian GNU/Linux 8 (jessie) Kernel: Linux ip-10-150-109-115 4.4.41-k8s SMP Mon Jan 9 15:34:39 UTC 2017 x86_64 GNU/Linux Install tools: kops 1.5.3 Others: What happened: When running the selfLink for pods started from manifests were incorrect. Example: What you expected to happen: To receive a correct selfLink: Example: How to reproduce it (as minimally and precisely as possible): I believe simply using a pod manifest to start a pod will cause this issue as kubelet seems to rely on defaults when starting pods from manifests. Anything else we need to know: I believe the below linked line needs to be corrected:
/assign I reproduced it. Will fix. Thanks for reporting!
GitHub didn't allow me to assign the following users: xiangpengzhao. 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. I understand the commands that are listed . </details
Change:
// shutting it down. If the pod hasn't started yet, we know that when // the pod worker is invoked it will also avoid setting up the pod, so // we simply avoid doing any work. <del> if !kl.podWorkers.IsPodTerminationRequested(pod.UID) { </del> <ins> // We also do not try to admit the pod that is already in terminated state. if !kl.podWorkers.IsPodTerminationRequested(pod.UID) && !podutil.IsPodPhaseTerminal(pod.Status.Phase) { </ins> // We failed pods that we rejected, so activePods include all admitted // pods that are alive. activePods := kl.filterOutInactivePods(existingPods)

Discussion:
Pods that already succeeded and waiting for finalizer are being readmitted, fail to be admitted and moving from Succeeded Phase to Failed (admission failed) phase. The correct behavior would be to not try to re-admit the succeeded (or failed) Pod. Specific case: Node is exposing Devices using device plugin. Device plugin is implemented as a Pod Job's pod that is using the Device run to completion and waiting for Job Status finalizer kubelet is being restarted DevicePlugin pod is reconnecting to the kubelet. While it is reconnecting, kubelet don't have availability of devices kubelet re-admits the Pod, even though it is terminated already kubelet marks the pod as "failed to be admitted" But the same can happen with the variations of GC speed and other admission handlers. /sig node /priority important-soon /cc There is also a wider issue: , that concentrates on running pods. This issue is about terminated Pods, which is less controversial. <detailsFor sure on master, may be on earlier versions. </details<detailsN/A </details<detailsN/A </details<detailsN/A </details<detailsN/A </details<detailsN/A </details
/triage accepted I think we have at least another issue mentioning the same behavior but observed for jobs, I'll look it up and crosslink later