jiebi/CodeConvo huggingface dataset:
Change:
framework.Failf("pod spec TerminationGracePeriodSeconds is not 1: %d", *pod.Spec.TerminationGracePeriodSeconds) } <del> time.Sleep(5 * time.Second) pod, err = podClient.Get(ctx, pod.Name, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to query for pod") ginkgo.By("updating the pod to have a negative TerminationGracePeriodSeconds") pod.Spec.TerminationGracePeriodSeconds = utilpointer.Int64(-1) _, err = podClient.PodInterface.Update(ctx, pod, metav1.UpdateOptions{}) </del> <ins> // retry if the TerminationGracePeriodSeconds is overrided // see more in https://github.com/kubernetes/kubernetes/pull/115606 err = retry.RetryOnConflict(retry.DefaultBackoff, func() error { pod, err := podClient.Get(ctx, pod.Name, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to query for pod") ginkgo.By("updating the pod to have a negative TerminationGracePeriodSeconds") pod.Spec.TerminationGracePeriodSeconds = utilpointer.Int64(-1) _, err = podClient.PodInterface.Update(ctx, pod, metav1.UpdateOptions{}) return err }) </ins> framework.ExpectNoError(err, "failed to update pod") pod, err = podClient.Get(ctx, pod.Name, metav1.GetOptions{})

Discussion:
After , /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
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
Change:
- apiGroups: - "" resources: <ins> - configmaps </ins> - endpoints - namespaces - secrets

Discussion:
BUG REPORT: /kind bug /sig auth What happened: Kubernetes distro testing v1.12.0-rc.2 shows in setups with self-hosted control planes (i.e. apiserver, controller-manager, scheduler run as pods) that previously worked on v1.11.3 and prior, the kube-controller-manager now crash loops with: The kube-controller-manager is run with a with a to the default system ClusterRole , which seems to be defined at Editing the ClusterRole manually to add for was sufficient to fix the crash loop. What you expected to happen: I suspect a change between v1.11.3 and v1.12.0 release candidates altered kube-controller-manager to begin looking for configmap , but didn't update the ClusterRoles. How to reproduce it (as minimally and precisely as possible): Release candidate testing is happening in Anything else we need to know?: Environment: Kubernetes version (use kubectl version): v1.12.0-rc.2 Cloud provider or hardware configuration: GCE, DigitalOcean, AWS OS (e.g. from /etc/os-release): Container Linux 1855.4.0 Kernel (e.g. uname -a): 4.14.67-coreos Install tools: Typhoon
/sig cluster-lifecycle /area kubeadm /remove-sig auth edit: sorry, got this mixed up with another 1.12/1.11 issue. is this related to the secured controller manager work you did? /remove-sig cluster-lifecycle /sig auth /sig api-machinery
Those labels are not set on the issue: <detailsIn response to : /sig cluster-lifecycle /area kubeadm /remove-sig auth /sig auth /sig api-machinery 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
can you please try if works to skip that lookup?
we can make this non-fatal, compare
adding that flag to the controller-manager does also work to skip the lookup, without me manually editing the ClusterRole. Although if controller-manager defaults to looking up the configmap, I'd imagine the clusterrole should default to allowing configmap get's, no?

i was just checking if there's a work around we could suggest for 1.12 :) longer term, we can lean towards whatever and decide (adding to bootstrap policy vs making things non-fatal)
This seems like it should get a Known Issue comment in the release notes for 1.12. Can somebody please draft test and drop it in the known issues bucket issue ASAP?
Change:
} } } <ins> { // Add additional tags glog.V(2).Infof("Creating additional load balancer tags for %s", loadBalancerName) tags := getLoadBalancerAdditionalTags(annotations) if len(tags) > 0 { err := c.addLoadBalancerTags(loadBalancerName, tags) if err != nil { return nil, fmt.Errorf("unable to create additional load balancer tags: %v", err) } } } </ins> } // Whether the ELB was new or existing, sync attributes regardless. This accounts for things

Discussion:
BUG REPORT: /kind bug /sig aws What happened: Adding this annotation to an existing service: did not trigger an update on AWS ELB (no new tags). What you expected to happen: Expected to see those 2 new tags under the existing ELB: How to reproduce it (as minimally and precisely as possible): a service without annotation the annotation tags on AWS Anything else we need to know?: Creating a new service WITH the annotation will create the expected tags on AWS. Environment: Kubernetes version (use ): 1.7.9 Cloud provider or hardware configuration**: AWS OS (e.g. from /etc/os-release): Debian GNU/Linux 8 (jessie) Kernel (e.g. ): Linux ip-xxxxx 4.4.78-k8s SMP Fri Jul 28 01:28:39 UTC 2017 x86_64 GNU/Linux Install tools: Others: Using Kops
+1
+1
+1
+1
+1
I've done some work on a fix for this, will try and get a PR submitted later today.
Change:
// GetEndpointNodeNames returns a string set of node names on which the // endpoints of the given Service are running. func (j *TestJig) GetEndpointNodeNames() (sets.String, error) { <ins> err := j.waitForAvailableEndpoint(ServiceEndpointsTimeout) if err != nil { return nil, err } </ins> endpoints, err := j.Client.CoreV1().Endpoints(j.Namespace).Get(context.TODO(), j.Name, metav1.GetOptions{}) if err != nil { return nil, fmt.Errorf("get endpoints for service %s/%s failed (%s)", j.Namespace, j.Name, err)

Discussion:
Which jobs are flaking: Which test(s) are flaking: ! Testgrid link: Reason for failure: Anything else we need to know: /cc /sig network /sig scalability /priority important-soon
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
/cc
/assign
Change:
containerTypeLabelContainer = "container" ) <del> func NewDockerSevice(client dockertools.DockerInterface) DockerLegacyService { </del> <ins> func NewDockerService(client dockertools.DockerInterface) DockerLegacyService { </ins> return &dockerService{ client: dockertools.NewInstrumentedDockerInterface(client), }

Discussion:
umbrella issue: kuberuntime uses to ]parse the version string of the api version]() from the runtime. When using with docker, it complains that Maybe we should just enforce that the api version returned by the runtime should be semver compatible. /cc
This is mentioned in . :) For now, we can add a after the docker apiversion to make it semver compatible.
Thanks for the reminder! We should make it clear in the API. This blocks kubelet from starting up, so we should fix it first.
I've checked the code, currently is only used in when checking the docker version compatibility. It is not exposed to the user by any means, so it should be fine to make some change ourselves, such as adding a . However, if we want to expose this to the user via in the future, it may make user confusing.
Change:
} func (mounter *SafeFormatAndMount) diskLooksUnformatted(disk string) (bool, error) { <del> return true, nil </del> <ins> return true, unsupportedErr </ins> } func (mounter *Mounter) GetFileType(pathname string) (FileType, error) { <del> return FileType("fake"), errors.New("not implemented") </del> <ins> return FileType("fake"), unsupportedErr </ins> } func (mounter *Mounter) MakeDir(pathname string) error { <del> return nil </del> <ins> return unsupportedErr </ins> } func (mounter *Mounter) MakeFile(pathname string) error { <del> return nil </del> <ins> return unsupportedErr </ins> } func (mounter *Mounter) ExistsPath(pathname string) bool { <ins> glog.Errorf("%s", unsupportedErr) </ins> return true } func (mounter *Mounter) PrepareSafeSubpath(subPath Subpath) (newHostPath string, cleanupAction func(), err error) { <del> return subPath.Path, nil, nil </del> <ins> return subPath.Path, nil, unsupportedErr </ins> } func (mounter *Mounter) CleanSubPaths(podDir string, volumeName string) error { <del> return nil </del> <ins> return unsupportedErr </ins> } func (mounter *Mounter) SafeMakeDir(pathname string, base string, perm os.FileMode) error { <del> return nil </del> <ins> return unsupportedErr </ins> }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Calls to on unsupported platforms do not report any error and potentially misbehave. What you expected to happen: I would expect an error to be reported, that can be consumed by the caller. How to reproduce it (as minimally and precisely as possible): for and were failing on darwin, and no error was being reported. See: & Environment: OS (e.g. from /etc/os-release): I have been testing on osx/darwin, which is not a supported platform.
/sig storage
/assign
Change:
import ( "fmt" "io" <del> "sort" "strconv" </del> "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/api/meta"

Discussion:
Ref and should sort revisions correctly (10 should be after 9, not 1).
I can help with this bug. Looks like trivial fix in PrintRolloutHistory
Thanks
are you still taking care of this one ? I am searching for some easy to do PR to just get familiar with the process and put my first PR in.
I created pr some time ago to close this issue
great thanks :-)
you can look for help-wanted issues or check and
thanks
Change:
} for n := range p.visitedNamespaces { <del> if len(o.Namespace) != 0 && n != o.Namespace { continue } </del> for _, m := range namespacedRESTMappings { if err := p.prune(n, m); err != nil { return fmt.Errorf("error pruning namespaced object %v: %v", m.GroupVersionKind, err)

Discussion:
Not sure if this is a bug, feature requests, or a documentation issue. What happened: I am trying to apply some configs with --prune, and was surprised by the behavior. I have a config file with objects in multiple namespaces, and apply with (note: no flag). By kube context was set to a namespace that was not in the manifests. Here is what I found: If my context is set to a random namespace, nothing is pruned If its set to namespace X, only objects in namespace X are applied If I pass a flag I can control which namespace gets pruned, but that will break the apply because the file has multiple namespaces in it What you expected to happen: I expect some way to be able to apply a config file with objects in multiple namespace and having pruning across all namespaces. Seems there are a few options: all namespaces referenced in the file, prune these across all namespaces warn about why we are not pruning due to namespace mismatch How to reproduce it (as minimally and precisely as possible): Run the script from namespace default, a, and b. You will see different behavior on each run. Related? Environment: Kubernetes version (use ): 1.17.0 Others: /sig cli
I encountered this issue. I think has the bug that o.namespace gets "default" if no namespace is given. Then only a single namespace is visited with or without namespace. If my observation is correct, it changes the bahaviour drastically. In my work, pruning just stops working.
Change:
if m.adapter.cgroupManagerType == libcontainerSystemd { updateSystemdCgroupInfo(libcontainerCgroupConfig, cgroupConfig.Name) } else { <del> if libcontainercgroups.IsCgroup2UnifiedMode() { libcontainerCgroupConfig.Path = m.buildCgroupUnifiedPath(cgroupConfig.Name) } else { libcontainerCgroupConfig.Path = cgroupConfig.Name.ToCgroupfs() } </del> <ins> libcontainerCgroupConfig.Path = cgroupConfig.Name.ToCgroupfs() </ins> } if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.SupportPodPidsLimit) && cgroupConfig.ResourceParameters != nil && cgroupConfig.ResourceParameters.PidsLimit != 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: is created on a cgroup2 host What you expected to happen: Such directory should not be created How to reproduce it (as minimally and precisely as possible): Boot Ubuntu 20.04 with Install moby/moby with containerd/containerd and opencontainers/runc Install kubernetes-sigs/kind . This version uses as the base image. Run with Run Run to drop into the shell of the node The following directories are unexpectedly created. (No process seems to belong to these groups actually) Environment: (See above)
cc
/sig node
Change:
It("Pod should perfer to scheduled to nodes pod can tolerate", func() { // make the nodes have balanced cpu,mem usage ratio <del> createBalancedPodForNodes(f, cs, ns, nodeList.Items, podRequestedResource, 0.5) </del> <ins> err := createBalancedPodForNodes(f, cs, ns, nodeList.Items, podRequestedResource, 0.5) framework.ExpectNoError(err) </ins> //we need apply more taints on a node, because one match toleration only count 1 By("Trying to apply 10 taint on the nodes except first one.") nodeName := nodeList.Items[0].Name

Discussion:
Chronically failing test. Perhaps covers deprecated behavior? /sig scalability /assign
shows up in
/sig scheduling is one of scheduling e2e test.
/assign I'll check this one.
According to the log, the balanced pods were not created by scheduler, the cpu/mem usage was unchanged.
This test failing every other run. Fix or disable? Blocking 1.7?
similar to , move to 1.8, but I'll still working on that.
Change:
ginkgo.By("attempting to create a CR with unknown metadata fields in the embedded object") metaEmbedded := fmt.Sprintf(metaPattern, testCRD.Crd.Spec.Names.Kind, testCRD.Crd.Spec.Group, testCRD.Crd.Spec.Versions[0].Name, "test-cr-embedded") <del> unknownEmbeddedMetaCR := fmt.Sprintf(embeddedCRPattern, metaEmbedded, `"unknownMetaEmbedded": "bar",`) </del> <ins> unknownEmbeddedMetaCR := fmt.Sprintf(embeddedCRPattern, metaEmbedded, `"unknownMetaEmbedded": "bar",`, ns) </ins> _, err = framework.RunKubectlInput(ns, unknownEmbeddedMetaCR, "create", "--validate=true", "-f", "-") if err == nil { framework.Failf("unexpected nil error when creating CR with unknown embedded metadata field")

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig cli
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
/assign

/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig cli
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
/assign
Change:
### Options ``` <del> --all[=false]: [-all] to select all the specified resources. </del> <ins> --all[=false]: select all resources in the namespace of the specified resource types. </ins> -f, --filename=[]: Filename, directory, or URL to file of resource(s) to be stopped. --grace-period=-1: Period of time in seconds given to the resource to terminate gracefully. Ignored if negative. --ignore-not-found[=false]: Treat "resource not found" as a successful stop.

Discussion:
It actually doesn't support --all.
/assign
ohh, thanks, will make a pr to address that right now..
Change:
func TestExperimentalPrefix(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> resp, err := http.Get(s.URL + "/apis/extensions/") if err != nil {

Discussion:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.
Change:
list = &beta case "/apis/extensions/v1beta2": list = &beta2 <ins> case "/apis/extensions/v1beta3": list = &extensionsbeta3 case "/apis/extensions/v1beta4": list = &extensionsbeta4 case "/apis/extensions/v1beta5": list = &extensionsbeta5 case "/apis/extensions/v1beta6": list = &extensionsbeta6 case "/apis/extensions/v1beta7": list = &extensionsbeta7 case "/apis/extensions/v1beta8": list = &extensionsbeta8 case "/apis/extensions/v1beta9": list = &extensionsbeta9 case "/apis/extensions/v1beta10": list = &extensionsbeta10 case "/apis/apps/v1beta1": list = &appsbeta1 case "/apis/apps/v1beta2": list = &appsbeta2 case "/apis/apps/v1beta3": list = &appsbeta3 case "/apis/apps/v1beta4": list = &appsbeta4 case "/apis/apps/v1beta5": list = &appsbeta5 case "/apis/apps/v1beta6": list = &appsbeta6 case "/apis/apps/v1beta7": list = &appsbeta7 case "/apis/apps/v1beta8": list = &appsbeta8 case "/apis/apps/v1beta9": list = &appsbeta9 case "/apis/apps/v1beta10": list = &appsbeta10 </ins> case "/api": list = &metav1.APIVersions{ Versions: []string{

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: With client-go v0.17.0, I observed many "Throttling request" when DiscoveryClient is used to get API group resources from API server. This didn't happen with client-go kubernetes-1.16.0. It looks like originally this kind of discovery requests are not throttled because no rate limiter provided and QPS == 0. But with rate limiter is always set if nil rate limiter is provided. is particularly suspicious because it is always true because DefaultQPS is nonzero. What you expected to happen: Discovery requests should not be throttled as before. How to reproduce it (as minimally and precisely as possible): Create DiscoveryClient and then call with it. 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:
/sig api-machinery
The NewTokenBucketRateLimiter was via Always negotiate a decoder using ClientNegotiator /cc
To be clear, that was fixing a bug where the documented defaults for rate limiting were not taking effect. I don't think we should completely disable throttling until more of the server-side priority work is completed, but discovery is expected to be bursty, so I could see defaulting to a different amount in the discovery client constructor, similar to
Yeah, everyone must be rate limited. I think we could give discovery a big burst value.
opened
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/schema" utilerrors "k8s.io/apimachinery/pkg/util/errors" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/cli-runtime/pkg/genericclioptions" "k8s.io/cli-runtime/pkg/printers" discovery "k8s.io/client-go/discovery"

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: When using kubectl auth can-i <verb<resourcesthe "verb" isn't check and returns yes on any resource regardless of what the verb is. What you expected to happen: I expected the cli to register an error like when you don't have enough arguments. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): client version GitVersion: 1.19.2 server version: GitVersion: 1.19.0 Cloud provider or hardware configuration: Mac OS X OS (e.g: ): n/a Kernel (e.g. ): Darwin Install tools: brew Network plugin and version (if this is a network-related bug): n/a Others:
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 cli
This is working as intended. The authorization layer can answer questions about arbitrary verbs, and the response to can-i mirrors the response you would get from a subjectaccessreview permission check. Getting a "yes" response to arbitrary verbs likely means you are a superuser and would be authorized for any operation.
Wouldn't a superuser only have access to the Kubernetes verbs that exist and not the arbitrary verbs that it is allowed to query that is defined here () This seems to go against the selfsubjectaccessreview which will return a set of actions that a user can perform. Arbitrary verbs seem like they shouldn't be allowed from that definition.
No, the cluster-admin superuser role allows verbs which allows any verb
Change:
for (( i=0; i <${NUM_MINIONS}; i++)) do KUBE_MINION_IP_ADDRESSES[$i]="${MINION_IP_BASE}$[$i+2]" MINION_NAMES[$i]="${MINION_IP_BASE}$[$i+2]" <del> done </del>  No newline at end of file <ins> VAGRANT_MINION_NAMES[$i]="minion-$[$i+1]" done </ins>

Discussion:
Running vagrant from scratch gives the error: For vagrant cluster, the last minion cannot be detected. The /tmp/minions file only shows two minions, but after a while, using the same command, i.e. will get three minions. There is a race between kube-up and validate-, we should wait a while before panic.
I can look to fix this.
Change:
"k8s.io/kubernetes/pkg/kubelet/util" ) <del> // maxMsgSize use 8MB as the default message size limit. </del> <ins> // maxMsgSize use 16MB as the default message size limit. </ins> // grpc library default is 4MB <del> const maxMsgSize = 1024 * 1024 * 8 </del> <ins> const maxMsgSize = 1024 * 1024 * 16 </ins> // DockerServer is the grpc server of dockershim. type DockerServer struct {

Discussion:
What happened: What you expected to happen: should not fail because of it's response size. How to reproduce it (as minimally and precisely as possible): N/A. Anything else we need to know?: Run batches through Argo workflow, but I don't think it's specific to the workloads. Environment: Kubernetes version (use ): 1.12 Cloud provider or hardware configuration: Amazon Linux 2 OS (e.g: ):Kernel (e.g. ): <br<brMy question is: limit is 8 MB. limit is 16 MB. 's the difference between and ? is for Docker, and is for containerd? Can somebody help understand the difference? does have difference limit than ? I think we should give them the same limits. /cc
/sig node
+1 to make it the same. as reviewers mentioned, it's a temporary thing as the right way to fix it is to have some pagination which is not available currently
Thanks for the guidance - putting out a pr to bump the size rn.