jiebi/CodeConvo huggingface dataset:
Change:
"type": "object" }, "io.k8s.api.flowcontrol.v1beta2.ResourcePolicyRule": { <del> "description": "ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) least one member of namespaces matches the request.", </del> <ins> "description": "ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) either (d1) the request does not specify a namespace (i.e., `Namespace==""`) and clusterScope is true or (d2) the request specifies a namespace and least one member of namespaces matches the request's namespace.", </ins> "properties": { "apiGroups": { "description": "`apiGroups` is a list of matching API groups and may not be empty. "*" matches all API groups and, if present, must be the only entry. Required.",

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 --I looked at the comment on ResourcePolicyRule to understand exactly what its ClusterScope field means, and was dismayed to find an outdated precise description that does not mention that field. I expected that comment to be up to date. Kubernetes version (use ): current 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:
/cc /cc /cc /cc
/triage accepted
Change:
"-A", string(kubeServicesChain), "-m", "comment", "--comment", fmt.Sprintf(`"%s loadbalancer IP"`, svcNameString), "-m", string(svcInfo.protocol), "-p", string(svcInfo.protocol), <del> "-d", fmt.Sprintf("%s/32", ingress.IP), </del> <ins> "-d", utilproxy.ToCIDR(net.ParseIP(ingress.IP)), </ins> "--dport", fmt.Sprintf("%d", svcInfo.port), )

Discussion:
We are working migrating ipv4 to ipv6, we should support ipv6 for IPVS. We should do the following things: remove ipv4 constraints of Node IPs() remove ipv4 in pkg/util/ipvs() use ipv6 conntrack tools use ipv6 iptables tools <!-- 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 feature /sig network /assign /cc
/area ipv6
FYI: I've just posted a PR (PR ) to fix the way that kube-proxy was calling conntrack without the required "-f ipv6" CLI flag whenever conntrack was being executed for a service that's using IPv6 addresses. There were a couple of lines in that needed to be changed. I don't think I can add UT coverage for those lines until more support for IPv6 addresses is to Cc
ACK! I will take care of , please feel free to ping me when you want my hand :)
Sounds good, is all yours. :) Likewise, let me know if I can help.
Sure, mate.
Change:
"fmt" "math" "math/rand" <ins> "net" "net/http" </ins> "os" "strconv" "sync"

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We understand the problem here - I'm working on the fix.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Change:
func validateInitContainers(containers, otherContainers []core.Container, deviceVolumes map[string]core.VolumeSource, fldPath *field.Path) field.ErrorList { var allErrs field.ErrorList if len(containers) > 0 { <del> allErrs = append(allErrs, validateContainers(containers, deviceVolumes, fldPath)...) </del> <ins> allErrs = append(allErrs, validateContainers(containers, true, deviceVolumes, fldPath)...) </ins> } allNames := sets.String{}

Discussion:
I found that kubelet will not allocate hostports specified from initContainers. And PodFitsHostPorts in kube-scheduler does not take initContainer into consideration. Also, kube-apiserver think such pod is illegal, but I think it OK. We should make the behavior of spec.HostPorts in initContainer clear
/sig node
Exactly. I think this makes sense. Since initContainers are expected to be completed, we should not expose extra port mappings during creating pod sandbox, which may bring in security risks.
Sounds good to me.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
package vclib import ( <ins> "sync" </ins> "time" <ins> "github.com/vmware/govmomi/vim25/types" </ins> "k8s.io/component-base/metrics" "k8s.io/component-base/metrics/legacyregistry" )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need reporting of version to be shown in the metrics. Why is this needed: The goal behind this is to add some info about the underlying infrastructure for the kubernetes cluster. Some customers were experiencing issues during the cluster upgrades, but nothing in the upgrades themselves or kubernetes code for provider seemingly could cause those. The issue is storage related, and happening on a variety of releases with a significant delay from any other underlying infrastructure change, to which the kubernetes cluster has no relation and a way to know about. So knowing used hostnames, and versions associated with it over time would be extremely beneficial for debugging in similar circumstances. Some of the use cases we face: 1) A is enabled in a customer environment, and so there occurs a periodic automated vMotion for VMs backing kuberentes . We'd like to know on which host the actual kubernetes was located at any moment, and if any vCenter version transitions happened over time, new hosts /removed/renamed.
/sig cloud-provider /wg provider-vsphere
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cloud-provider /wg provider-vsphere 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
/area provider/vmware
Change:
}, numErrs: 0, }, <ins> { name: "add loadBalancerSourceRanges", tweakSvc: func(oldSvc, newSvc *api.Service) { oldSvc.Spec.Type = api.ServiceTypeLoadBalancer newSvc.Spec.Type = api.ServiceTypeLoadBalancer newSvc.Spec.LoadBalancerSourceRanges = []string{"10.0.0.0/8"} }, numErrs: 1, }, { name: "update loadBalancerSourceRanges", tweakSvc: func(oldSvc, newSvc *api.Service) { oldSvc.Spec.Type = api.ServiceTypeLoadBalancer oldSvc.Spec.LoadBalancerSourceRanges = []string{"10.0.0.0/8"} newSvc.Spec.Type = api.ServiceTypeLoadBalancer newSvc.Spec.LoadBalancerSourceRanges = []string{"10.180.0.0/16"} }, numErrs: 1, }, </ins> } for _, tc := range testCases {

Discussion:
a service, type LoadBalancer. that and add a field with a value that the iptables rules do not appear It does seem that the GCE firewall rule is created. patch?
Is this a regression?
No. This has never been "right" as far as I can tell. , Phillip Wittrock wrote:
can this be closed now?
Nope. The root cause has not been fixed yet.
Change:
// About to get clients and such, detect standaloneMode standaloneMode := true <del> switch { case s.RequireKubeConfig == true: standaloneMode = false glog.Warningf("--require-kubeconfig is deprecated. Set --kubeconfig without using --require-kubeconfig.") case s.KubeConfig.Provided(): </del> <ins> if len(s.KubeConfig) > 0 { </ins> standaloneMode = false }

Discussion:
This will be the end of the deprecation period for --require-kubeconfig.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
ref
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
], deps = [ "//vendor/github.com/golang/glog:go_default_library", <ins> "//vendor/golang.org/x/net/http2:go_default_library", </ins> "//vendor/k8s.io/api/core/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library",

Discussion:
While this issue happens without this complicated reproduction, here is a sure-fire way to get it. a long-running kubectl get. In this example, I have a cluster with about 2,000 configmaps each around 100KiB. Once you see these lines Press , then type , and then you'll see... What's happening is that the apiserver is hitting , and then it . As the code says, this should make it obvious to the client (kubectl) that it didn't get the entire body, because no 0-length EOF chunk gets sent. I can confirm from using tcpdump that no such chunk gets sent. However, kubectl doesn't notice this, and instead tries to decode a 0-length Response body, giving the cryptic message. What I expected to happen the very least, a less cryptic error message like "connected closed". , this gets detected by the code and we can internally retry, just as if we got, e.g.,
cc Possibly seen here, too: openshift/origin
/assign mengqiy
Created a PR to detect it. Further improvement may be retrying when detect connection closure
closing this since you filed a PR for it
Change:
controllerErr := <-controllerCompletedCh if controllerErr != nil { <del> t.Errorf("Expected no error from the controller, but got: %#v", controllerErr) </del> <ins> t.Errorf("Expected no error from the controller, but got: %s", fmtError(controllerErr)) </ins> } }) } <ins> func fmtError(err error) string { return fmt.Sprintf("%#+v=%q", err, err.Error()) } </ins> func startAPFController(t *testing.T, stopCh <-chan struct{}, apfConfiguration []runtime.Object, serverConcurrency int, requestWaitLimit time.Duration, plName string, plConcurrency int) (utilflowcontrol.Interface, <-chan error) { clientset := newClientset(t, apfConfiguration...)

Discussion:
pull-kubernetes-unit TestPriorityAndFairnessWithPanicRecoveryAndTimeoutFilter 7/14 No response /sig api-machinery
/priority important-soon
/cc /triage accepted
and can this be related to ?
I see no direct relationship, but hey, anything's possible. We learned that with the misery in integration test failures when we merged not-really-guilty other stuff.
The expanded logging turned up some new evidence. See , where the complaint is now
The problem here is not APF, it is something in the timeout filter or the test server.
is something in APF triggering a timeout?
The flake definitely came in with on the prior commit on master: on the merge commit of
/assign
Note that the flaking test is deliberately suffering server-side timeouts. The symptom in flakes is that the test is checking that the client gets kube's designed response to a timeout while handling, a particular form HTTP response message, but sometimes the client gets something else (an http2 internal error?). is a change in metrics, and should have nothing to do with how timeouts while handling and detected or handled. I will see what I can see...
, regarding your comment above (): note that the output shown (the panic "as designed") is normal; if there are failures involved, the failing part was elided.
Also, the failures seem to be coming from one particular subtest () and that one does not involve designed panics.
On closer examination of the timeout filter, it appears that this "INTERNAL ERROR" is something that can happen normally in the course of handling a timeout. So I will adjust the test to accept this.
I have updated to include the fix for this flake.
Change:
var container string if len(args) == 1 { <ins> if len(pod.Spec.Containers) != 1 { return fmt.Errorf("POD %s has more than one container; please specify the container to print logs for", pod.ObjectMeta.Name) } container = pod.Spec.Containers[0].Name </ins> } else { container = args[1] }

Discussion:
On a cluster running 0.13.2, I ran , picked out the name of a pod that only contains a single container, let's call it foo, and then ran . It prints nothing other than the message "Unexpected path for command running". If I add on the container name (), then it prints nothing, presumably because the pod has no logs. The docs for kubectl log say that the container name is optional if the pod only has one container, so I wouldn't expect this response.
+1, we're having to work around this on guides
Change:
* **Kubectl Command Line Interface** ([kubectl.md](kubectl.md)): The `kubectl` command line reference. <ins> * **Sharing Cluster Access** ([sharing-clusters.md](sharing-clusters.md)): How to share client credentials for a kubernetes cluster. </ins> * **Roadmap** ([roadmap.md](roadmap.md)): The set of supported use cases, features, docs, and patterns that are required before Kubernetes 1.0.

Discussion:
Hi, I can't find any documentation how I add more admin users so my team members can deploy pods.
Is there a functioning concept of different user types yet or is the answer here just passing around kubeconfig files?
For now, the answer is to pass around kubeconfig files. There are better answers coming sometime, but afaik, not yet. --brendan , Alex Robinson wrote:
Yep. AFAIK, the apiserver doesn't yet support multiple user credentials, so if you want to grant others access to a cluster, they'll need to share credentials (stored in kubeconfig file).
Ok, and we do have a doc on , but unless I'm mistaken, it appears to be more targeted at developers rather than users and doesn't talk about how to find the file to copy it between machines, or where to put it when you do so. And how is a new user supposed to find that documentation if they don't know that the file is called kubeconfig?
I'm happy to add a short doc describing how to share/copy kubeconfig files for cluster access. Does sound sufficiently discoverable?
Thanks for all the answers. A doc in is fine for me.
Change:
master string // healthzPort is the port to be used by the healthz server. healthzPort int32 <ins> // metricsPort is the port to be used by the metrics server. metricsPort int32 </ins> scheme *runtime.Scheme codecs serializer.CodecFactory

Discussion:
What happened: From We used to allow using or in and . Now the validation on kubeproxyconfig disallow that (it only allows ): This seems to break backward compatibility for those two flags. Please comment if I'm missing something. cc How to reproduce it (as minimally and precisely as possible): Try with kube-proxy. Environment: Kubernetes version (use ):
/sig network /kind bug
Tried , the error is: and , the error is: So maybe we need to loosen and revert ?
Loosen the validation sounds good. was meant for loosen the validation as well (allowing not just ip, but also ip:port), but for some reason it doesn't work as intended. Would be great to fix that instead of revert :)
find the root cause of not working as expected. introduced the regression: I send a PR to fix the two issues we mentioned in this thread.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with .

/close 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 believe this hasn't been fixed yet. /remove-lifecycle rotten /reopen
Reopened this issue. <detailsIn response to : I believe this hasn't been fixed yet. /remove-lifecycle rotten /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
I agree There's also the issue of IPv6-only: Results in:
Thanks for your report. Do you mind opening a new issue regarding IPv6 since the original issue was fixed? Thanks.
Sure. Thanks
Please see:
Change:
createRoute := ws.POST(path).To(h). Doc("create a " + kind). <del> Operation("create" + kind). Reads(versionedObject) // from the request </del> <ins> Operation("create" + kind) </ins> addParamIf(createRoute, namespaceParam, namespaceScope) if _, ok := storage.(RESTCreater); ok { ws.Route(createRoute.Reads(versionedObject)) // from the request

Discussion:
The v1beta{1/2}.Minion field appears to be duplicated in the method parameter section where ever it appears.
Repro: Use the steps outlined here to stand up a cluster on GCE: View the swagger docs at https://{kubernetes master}/swaggerapi/api/v1beta2
Thanks Ian for reporting! The issue seems to be due to this line: Reads(versionedObject) is twice and hence minion in beta1 and beta2 and Pod in beta3 is repeated twice in POST body params. Will send a PR to fix.
Change:
InternalGroupKind: api.Kind("Service"), InternalOperationResources: map[admission.Operation][]api.ResourceName{ admission.Create: allResources, <ins> admission.Update: allResources, </ins> }, MatchedResourceNames: allResources, MatchesScopeFunc:     generic.MatchesNoScopeFunc,

Discussion:
the ability to get the previous version of an object directly via admission control. As a result, admission code can now use this rather than fetching the object directly. Need to update:
/cc - this is a necessary follow-up, will get to it soon.
Change:
func setupInProbeMode(t *testing.T, devs []*pluginapi.Device, callback monitorCallback, socketName string, pluginSocketName string) (Manager, <-chan interface{}, *Stub, pluginmanager.PluginManager) { m, updateChan := setupDeviceManager(t, devs, callback, socketName) <del> pm := setupPluginManager(t, pluginSocketName, m) </del> p := setupDevicePlugin(t, devs, pluginSocketName) <ins> pm := setupPluginManager(t, pluginSocketName, m) </ins> return m, updateChan, p, pm }

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: bazel-test-master Which test(s) are flaking: //pkg/kubelet/cm/devicemanager/godefaulttest:run2of_2 Testgrid link: Reason for failure: Anything else we need to know: links to appreciated Triage shows nothings (seems to not have updated data), but there are multiple failures in the job bazel-test-master. links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
/sig release
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-release 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
Digging further as the step has another recent test fail ... So on the two runs reported by has 2 test failures has 1 test failure And the most recent failure in this area is a TestAdmit/match test failure but on a different test.
/sig node
/assign /triage accepted I'll take a look at them and fix.
Change:
// DefaultDaemonSetUniqueLabelKey is the default label key that is added // to existing DaemonSet pods to distinguish between old and new // DaemonSet pods during DaemonSet template updates. <del> DefaultDaemonSetUniqueLabelKey string = "daemonset-controller-hash" </del> <ins> DefaultDaemonSetUniqueLabelKey = appsv1beta1.ControllerRevisionHashLabelKey </ins> ) // DaemonSetList is a collection of daemon sets.

Discussion:
Here are the hash label keys of all controllers: Deployment: DaemonSet: (new in 1.7) StatefulSet: (new in 1.7) Had a brief discussion with and about this, it should be consistent. We can use for DaemonSet and StatefulSet, and keep Deployment as-is. Deployment hash label key should be different from other two because Deployment pods hash labels is used by selector (unlike the other two controllers). We probably should have used hash annotations instead of hash labels for DaemonSet and StatefulSet, since we don't use hash labels to select their history or pods. Hash labels are chosen for consistency. This is fine since we don't modify hash label values.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Actually, controller revisions created by statefulset, daemonset has different label: // controller revision created by statefulset label: "" // controller revision created by daemonset label: controller-revision-hash: "" should be consistent?