jiebi/CodeConvo huggingface dataset:
Change:
if verb == "LIST" && strings.ToLower(request.QueryParameter("watch")) == "true" { verb = "WATCH" } <del> Monitor(&verb, &resource, utilnet.GetHTTPClient(request.Request), rw.Header().Get("Content-Type"), delegate.status, now) </del> <ins> Monitor(&verb, &resource, cleanUserAgent(utilnet.GetHTTPClient(request.Request)), rw.Header().Get("Content-Type"), delegate.status, now) </ins> }) } <ins> func cleanUserAgent(ua string) string { if strings.HasPrefix(ua, "Mozilla/") { return "Browser" } return ua } </ins> type responseWriterDelegator struct { http.ResponseWriter

Discussion:
Some of the exported prometheus metrics, e.g. include high-cardinality fields like the User-Agent. This creats a large number of time-series on the prometheus server is ususally not advised to do. Please consider reducing the cardinality of the exported metrics.
Change:
// ProbePodToPodConnectivity runs a series of probes in kube, and records the results in `testCase.Reachability` func ProbePodToPodConnectivity(k8s *kubeManager, model *Model, testCase *TestCase) { <del> numberOfWorkers := 3 // See https://github.com/kubernetes/kubernetes/pull/97690 </del> allPods := model.AllPods() size := len(allPods) * len(allPods) jobs := make(chan *ProbeJob, size) results := make(chan *ProbeJobResults, size) <del> for i := 0; i < numberOfWorkers; i++ { go probeWorker(k8s, jobs, results) </del> <ins> for i := 0; i < model.GetWorkers(); i++ { go probeWorker(k8s, jobs, results, model.GetProbeTimeoutSeconds()) </ins> } for _, podFrom := range allPods { for _, podTo := range allPods {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Ive done preliminary testing with on calico powered clusters on some windows variants and found that the probing seems to work. Can we add wrapper to netpol suite so that we can run it on windows clusters ? Why is this needed: We need this because otherwise, CNIs such as EKS will give us This error is caused when, for example, pods that are landing on a windows node havent defined their target platform. Somehow i guess pods which are landing on linux nodes dont have this issue. Its also needed for the obvious reason that we probably want separate linux and windows test suites for policies, in general, even though we expect the logic to be identical (modulo hostports , which we dont currently test)
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 windows
/assign
grepping around, I can't figure out where those are supposed to go. Can you give me pointers?
(resolved in slack, matts digging into this)
ok, these are running now on eks, lots of failures. will dig
/assign
the netpol are not being applied for the ns: Instead of failing because should not be able to access , the connection succeeds.
Change:
} if !s.LeaderElection.LeaderElect { <del> run(nil) </del> <ins> stopCh := make(chan struct{}) defer close(stopCh) run(stopCh) </ins> panic("unreachable") }

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: If a 1.8.x kubernetes master with a single controller-manager is configured with --leader-elect=false, deleting a deployment through the API with v1meta.DeletePropagationForeground doesn't work. The deployment has its deletionTimestamp set and a foregroundDeletion finalizer is , but the pod, rc and deployment are not deleted. What you expected to happen: The pod, rc and deployment should be deleted when the controller-manager uses --leader-elect=false. How to reproduce it (as minimally and precisely as possible): I used kubeadm with calico networking, and modified the controller-manager configuration via sudo sed -i /etc/kubernetes/manifests/kube-controller- -e '/leader-elect/ s/true/false/' and then ran to create and delete deployments. Anything else we need to know?: I suspect the problem is related to this change: It appears to require leader election before the GC controller will finish initialization. Looking at controller-manager logs with leader-elect=false, I saw this log entry from "GraphBuilder running" I did not see the "started %d new monitors, %d currently running" log entry at the end of the startMonitors() function. That seems consistent with the GC controller waiting for "<-gb.informersStarted" Environment: Kubernetes version (use ): tested with 1.8.2 and 1.8.4 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): vagrant virtualbox with the ubuntu/xenial64 box Kernel (e.g. ): Install tools: kubeadm Others:
cc Have you seen this in Openshift?
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
cc
I think this problem occurs because initialiuzes the stop channel top nil when leader-elect=false. This causes garbage collector graph_builder to exit early. The following release-1.8 patch seems to fix the problem.

creates a dummy channel which will never be closed and allows the garbage collector graph builder to work like it does when leader-elect is true. [Edit - just noticed that my initial patch had some unexpected differences]
do you really need to remove the following code?
That change was not intended. I also noticed that after I saved my change. I redid the patch and edited my previous comment to reflect that.
Agree with the diagnosis and fix, are you going to open a PR?
Yes, I can do that. Reading your PR guidelines and ours.
Will I need to go through to get this into the release-1.8 and release-1.9 branches?
Change:
return *typed.Spec.Replicas, nil } return 0, nil <ins> case *extensions.DaemonSet: return 0, nil </ins> case *batch.Job: // TODO: currently we use pause pods so that's OK. When we'll want to switch to Pods // that actually finish we need a better way to do this.

Discussion:
[sig-apps] Daemon set [Serial] should retry creating failed daemon pods [Conformance] [sig-apps] Daemon set [Serial] should rollback without unnecessary restarts [Conformance] [sig-apps] Daemon set [Serial] should run and stop complex daemon [Conformance] [sig-apps] Daemon set [Serial] should run and stop simple daemon [Conformance] [sig-apps] Daemon set [Serial] should update pod when spec was updated and update strategy is RollingUpdate [Conformance] Please see: https://k8s-,%20master%20(dev) https://k8s-,%20master%20(dev)
can you please take a look? I see at least one change in this range that probably caused this?
/sig apps /priority failing-test
/milestone v1.11
/kind bug /priority critical-urgent
cc
thanks for tracking and opening this issue.
cc and
These tests are also failing in sig-release-master-blocking kubeadm-gce jobs https://k8s- This is release blocking as we are entering Code slush on Tuesday 5/29.
cc
Fix in
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<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:
fi echo "Uploading to Amazon S3" <del> if ! aws s3 ls "s3://${AWS_S3_BUCKET}" > /dev/null 2>&1 ; then </del> <ins> if ! aws s3api get-bucket-location --bucket ${AWS_S3_BUCKET} > /dev/null 2>&1 ; then </ins> echo "Creating ${AWS_S3_BUCKET}" # Buckets must be globally uniquely named, so always create in a known region

Discussion:
When I run: I get the following error: Waiting a bit and running got past this point because the bucket was ready the second time around, but the getting-started process should be more robust.
I experienced the same issue
We do try to query for the bucket existing, but perhaps S3 is even more eventually consistent than I thought! I did observe that we were very trusting about the user providing the correct S3 region, and have tried to fix this in . I don't think that was the problem here though (if you make_bucket, you can't have a region mismatch...) I guess we could retry the sync a few times; might help with e.g. a network interruption during the sync also.
I believe this to have been fixed by . I'm going to close, but if it happens again please do reopen.
FYI I got this with the latest k8s as of 10/13/15: I believe this is k8s 1.0.6 but I just tore down my AWS cluster and apparently kubectl needs to talk to the now-terminated master instance. I ran to get k8s. Waiting and running again doesn't show the issue since the bucket is fully created and accessible. I just provisioned a Vagrant cluster in hopes that would help show what version I'm using. Here's the output of :
Change:
} func verifyStringArrayEqualsAnyOrder(t *testing.T, actual, expected []string) { <del> invalid := len(actual) != len(expected) if !invalid { for _, exp := range expected { found := false for _, act := range actual { if exp == act { found = true break } } if !found { t.Errorf("Expected element %q not found in %#v", exp, actual) } } } if invalid { t.Errorf("Expected: %#v, Actual: %#v", expected, actual) </del> <ins> var act, exp []string copy(act, actual) copy(exp, expected) sort.StringSlice(act).Sort() sort.StringSlice(exp).Sort() if !reflect.DeepEqual(exp, act) { t.Errorf("Expected(sorted): %#v, Actual(sorted): %#v", exp, act) </ins> } }

Discussion:
Seeing random failures.
Looks like lately refactory makes docker API requests are not deterministic. Will look into it.
Any update? It seems to be failing a lot.
I just looked into this and found that is the only test that there are two pods in the which is fed to I think podworker was syncing the two pods in parallel, this causes non-deterministic behaviour I have tried , no errors. , error happens continuously. I can try to fix this :)
Yes, that is what I believe here, but never have time working on it. Thanks for looking into this, and re-assign it to you.
I saw your old PR for this, I think we still need to keep the parallel sync here. Just need to create a for this case :)
Change:
} } <ins> func TestSingularObjectNoExtension(t *testing.T) { obj, err := NewBuilder(latest.RESTMapper, api.Scheme, fakeClient()). NamespaceParam("test").DefaultNamespace(). FilenameParam(false, "../../../examples/pod"). Flatten(). Do().Object() if err != nil { t.Fatalf("unexpected error: %v", err) } pod, ok := obj.(*api.Pod) if !ok { t.Fatalf("unexpected object: %#v", obj) } if pod.Name != "nginx" || pod.Namespace != "test" { t.Errorf("unexpected pod: %#v", pod) } } </ins> func TestSingularRootScopedObject(t *testing.T) { node := &api.Node{ObjectMeta: api.ObjectMeta{Name: "test"}, Spec: api.NodeSpec{ExternalID: "test"}} r := streamTestObject(node)

Discussion:
It works when I pipe but not with filename.
broke in this commit cc
Did you try to add an extension .json to the file? We filter for file extensions
ahhh ok. so working as intended. it used to autodetect :( ... thanks
That was unintended. The file extensions should only be used for deciding which files in a directory to process. For a single file, any extension should be allowed. We don't actually infer the content type from the extensions. For stdin and http sources, for instance, there are no extensions. cc
Fix is pretty straightforward (ignore file extensions when dealing with single file); I have it working with manual test, just adding unit test. Will send shortly.
Thanks, but this is v1.0-post, so no rush
Change:
) require ( <ins> github.com/emicklei/go-restful/v3 v3.11.0 // indirect </ins> github.com/go-logr/logr v1.4.1 // indirect github.com/go-openapi/jsonpointer v0.19.6 // indirect github.com/go-openapi/jsonreference v0.20.2 // indirect

Discussion:
We're trying to upgrade to () and found the issue on executing (). The problem is that on () missed dependency that not allow to install () No error To reproduce the same what happening on , just execute this command on code-generator folder: I think it's happens after this commit <details</details<details</details<details</details<details</details<details</details<details</details
/cc
/assign
/sig api-machinery
I was able to reproduce, but just because I had an older version of kube-openapi in my GOPATH. Using the prefix in the command fixed it. I think line needs to be
Yeah, with works for me too.
Either that or we pin to a more recent commit, for example . For some reason if you ommit the version it is using a from Feb 27.
thanks for investigating. Question, if we use would this not cause problems in the future if we try to build a release branch from the past? Maybe this is not a big deal. OTOH if we hardcode a tag, it may create maintenance costs. I'm wondering if there is a better way, say to version and use the corresponding tag, say ?
Using tags would be a way to have more reproducible builds, they still need to be tagged from time to time tho. That is still better than using or micro managing commit revisions.
Thanks and for the research. Is either of you thinking on submitting a fix for this? Thanks!
I can do it.
Thanks! /assign mbobrovskyi
Yes, please don't use Generally instead we'd control the version of a tool in the hack/tools module and install it from there (see e.g.
This allows us to also gain for the package while not polluting the main module with dev-only dependencies.
Not sure if we need to make another Because it's not just a dev-only dependency. I propose to add it to of code-generator.
This is about semversioning
/triage accepted
Change:
func (m *mockCSIDriver) PrepareTest(f *framework.Framework) (*storageframework.PerTestConfig, func()) { // Create secondary namespace which will be used for creating driver driverNamespace := utils.CreateDriverNamespace(f) <del> ns2 := driverNamespace.Name ns1 := f.Namespace.Name </del> <ins> driverns := driverNamespace.Name testns := f.Namespace.Name </ins> ginkgo.By("deploying csi mock driver") cancelLogging := utils.StartPodLogs(f, driverNamespace)

Discussion:
Tracking bug for /sig storage /important-longterm /assign
/sig storage /triage accepted
/priority important-longterm
Change:
"time" "k8s.io/api/core/v1" <del> "k8s.io/apimachinery/pkg/api/errors" </del> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels"

Discussion:
SchedulerPredicates [Serial] validates that a pod with an invalid NodeAffinity is rejected Has been failing consistently since 4/17. Here are the /kind bug /priority failing-test /priority important-soon /sig scheduling /milestone 1.11 cc /assign for triage.
The provided milestone is not valid for this repository. Milestones in this repository: [, , , , , , , , , , ] Use to clear the milestone. <detailsIn response to : ## Failing Job SchedulerPredicates [Serial] validates that a pod with an invalid NodeAffinity is rejected /priority failing-test /priority important-soon /sig scheduling /milestone 1.11 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
/milestone v1.11
/status approved for milestone
Also fails as part of upgrade job as seen below
Also fails as part of following jobs https://k8s- https://k8s- https://k8s- https://k8s-
xref
/assign
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 6 days, the issue will be moved out of the v1.11 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : 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
Seems like this is failing in (just with slightly different versions)
Change:
func (g *dockerConfigKeyProvider) Provide() credentialprovider.DockerConfig { // Read the contents of the google-dockercfg metadata key and // parse them as an alternate .dockercfg <del> if cfg, err := credentialprovider.ReadDockerConfigFileFromUrl(dockerConfigKey, g.Client, metadataHeader); err == nil { </del> <ins> if cfg, err := credentialprovider.ReadDockerConfigFileFromUrl(dockerConfigKey, g.Client, metadataHeader); err != nil { glog.Errorf("while reading 'google-dockercfg' metadata: %v", err) } else { </ins> return cfg }

Discussion:
It looks like we always try and hit the metadata server even if we aren't on GCE. We then print an error out. This should either be silent (assume after X attempts that we aren't on GCE?) or should only be activated with an option. Email thread: !topic/google-containers/w-ei5Xs6K0Y
cc:
FYI, the way the credentialprovider logic is set up, providers are asked once per keyring creation whether they are enabled. If they are enabled, then they are asked to provide their contribution to .dockercfg each time the lazy keyring is accessed. For efficiency, there is a caching provider, which composes with heavier providers and stores their .dockercfg contribution for a predetermined TTL. What was happening here was that "Enabled()" for our GCE-metadata implementations was logging about errors fetching "http://metadata", where the entire "Enabled()" check is "err == nil".
I believe that this was fixed by
Change:
zero := int64(0) <ins> // Some distributions (Ubuntu 16.04 etc.) don't support the proc file. _, err := framework.IssueSSHCommandWithResult( "ls /proc/net/nf_conntrack", framework.TestContext.Provider, clientNodeInfo.node) if err != nil && strings.Contains(err.Error(), "No such file or directory") { framework.Skipf("The node %s does not support /proc/net/nf_conntrack", clientNodeInfo.name) } framework.ExpectNoError(err) </ins> clientPodSpec := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:      "e2e-net-client",

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: e2e test "[sig-network] Network [It] should set TCP CLOSEWAIT timeout" requires the test target OS supports /proc/net/nfconntrack, but Ubuntu 16.04 doesn't support it. Then the test fails today like the following: What you expected to happen: The test succeeded or was skipped. How to reproduce it (as minimally and precisely as possible): Just kick Anything else we need to know?: The existence of /proc/net/nfconntrack depends on the Linux kernel config CONFIGNFCONNTRACKPROCFS, but that is disabled on Ubuntu 16.04. In addition, the test is skipped if the node number is less than 2. So I guess that is one of reasons this issue was not present until today. Environment: Kubernetes version (use ): v1.11.3 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): Ubuntu 16.04.4 LTS Kernel (e.g. ): 4.4.0-134-generic Install tools: kubeadm Others:
/sig network
Some kube-proxy functionalities depends on conntrack, is it possible to run a conformance cluster without having conntrack enable?
Change:
<ins> /* Copyright 2017 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package v1beta2 import ( "fmt" apps "k8s.io/api/apps/v1beta2" "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" ) // StatefulSetListerExpansion allows custom methods to be added to // StatefulSetLister. type StatefulSetListerExpansion interface { GetPodStatefulSets(pod *v1.Pod) ([]*apps.StatefulSet, error) } // StatefulSetNamespaceListerExpansion allows custom methods to be added to // StatefulSetNamespaceLister. type StatefulSetNamespaceListerExpansion interface{} // GetPodStatefulSets returns a list of StatefulSets that potentially match a pod. // Only the one specified in the Pod's ControllerRef will actually manage it. // Returns an error only if no matching StatefulSets are found. func (s *statefulSetLister) GetPodStatefulSets(pod *v1.Pod) ([]*apps.StatefulSet, error) { var selector labels.Selector var ps *apps.StatefulSet if len(pod.Labels) == 0 { return nil, fmt.Errorf("no StatefulSets found for pod %v because it has no labels", pod.Name) } list, err := s.StatefulSets(pod.Namespace).List(labels.Everything()) if err != nil { return nil, err } var psList []*apps.StatefulSet for i := range list { ps = list[i] if ps.Namespace != pod.Namespace { continue } selector, err = metav1.LabelSelectorAsSelector(ps.Spec.Selector) if err != nil { return nil, fmt.Errorf("invalid selector: %v", err) } // If a StatefulSet with a nil or empty selector creeps in, it should match nothing, not everything. if selector.Empty() || !selector.Matches(labels.Set(pod.Labels)) { continue } psList = append(psList, ps) } if len(psList) == 0 { return nil, fmt.Errorf("could not find StatefulSet for pod %s in namespace %s with labels: %v", pod.Name, pod.Namespace, pod.Labels) } return psList, nil } </ins>

Discussion:
As a prerequisite of moving the , , , and controllers to use the apps/v1beta2 APIs, we need to add list expansions for , , , and to .
/assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig apps
Change:
genericapirequest "k8s.io/apiserver/pkg/endpoints/request" "k8s.io/apiserver/pkg/storage/names" "k8s.io/kubernetes/pkg/api" <ins> "k8s.io/kubernetes/pkg/api/pod" </ins> "k8s.io/kubernetes/pkg/apis/settings" "k8s.io/kubernetes/pkg/apis/settings/validation" )

Discussion:
says "Before persisting the object to storage, clear disabled alpha fields". There is that actually implements it but there are some discussions about it. This issues is a reminder that introduced by needs to be cleared too when the discussion in settles down. /assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
kind/cleanup priority/important-soon
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details