jiebi/CodeConvo huggingface dataset:
Change:
endpointSlice.ObjectMeta.Name = fmt.Sprintf("%s-%s", endpointSlice.ObjectMeta.GenerateName, rand.String(8)) endpointSlice.ObjectMeta.GenerateName = "" } <ins> endpointSlice.ObjectMeta.ResourceVersion = "100" </ins> return false, endpointSlice, nil })) <ins> client.PrependReactor("update", "endpointslices", k8stesting.ReactionFunc(func(action k8stesting.Action) (bool, runtime.Object, error) { endpointSlice := action.(k8stesting.CreateAction).GetObject().(*discovery.EndpointSlice) endpointSlice.ObjectMeta.ResourceVersion = "200" return false, endpointSlice, nil })) </ins> return client }

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 EndpointSlice feature enabled, after EndpointSliceController creates or updates an EndpointSlice when reconciling a Service, the Service would always be processed one extra time, which is triggered by the EndpointSlice /updated event made by itself during the first processing. What you expected to happen: EndpointSliceController shouldn't reprocess a Service due to the EndpointSlice update made by itself. How to reproduce it (as minimally and precisely as possible): EndpointSlice feature, improve kube-controller-manager log to 5. a nginx deployment a Service backed by the above deployment. kube-controller-manager log: the service will be processed twice in succession. Anything else we need to know?: It's because EndpointSliceController tracks stale resource version after creating/updating an EndpointSlice. Environment: Kubernetes version (use ): v1.18.0-alpha.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
if !ok { return 0, fmt.Errorf("invalid max log size") } <del> if maxSize < 0 { return 0, fmt.Errorf("negative max log size %d", maxSize) } </del> return maxSize, nil }

Discussion:
Setting a negative value in currently makes kubelet crash with a stack trace. The function raises an error when the value is negative, but the comment on  says that setting a negative value disables log rotation. At the moment there’s no way to disable log rotation and I believe removing lines 141 to 143 from , would allow this.
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 node (I guess)
/area kubelet can you show the stack trace?
The stack trace is 5000 lines long and apart from the following message, I don’t think it is relevant:
/assign
You can try to quote the value with double quotation when the value is negative, like the following: syncFrequency: 0s volumeStatsAggPeriod: 0s containerLogMaxSize: "-1"
I tried "-1", but still error
volumeStatsAggPeriod: -1s means disable
Which Kubernetes version have you installed? As if on my v1.19.4 system,no errors occured after I quoted the value with double quotation.
v1.20.2
I’m on v1.20.4. That’s already the case. Also, can only be set as a string in kubelet’s configuration, trying to set an integer will raise a parsing error (see ). The problem is not with the configuration, I’ve linked to the exact line in the code that checks for a negative value and raises the error.
Maybe you can try to disable this featureGate
Seems to work, I don’t know why I didn’t find this feature gate before.
Change:
gvr("flowcontrol.apiserver.k8s.io", "v1beta3", "prioritylevelconfigurations"): { Stub:             `{"metadata": {"name": "conf4"}, "spec": {"type": "Limited", "limited": {"nominalConcurrencyShares":3, "limitResponse": {"type": "Reject"}}}}`, ExpectedEtcdPath: "/registry/prioritylevelconfigurations/conf4", <del> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta2", "PriorityLevelConfiguration"), </del> }, // --

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Change:
## Salt cluster setup <del> The **salt-master** service runs on the kubernetes-master node. </del> <ins> The **salt-master** service runs on the kubernetes-master node [(except on the default GCE setup)](#standalone-salt-configuration-on-gce). </ins> The **salt-minion** service runs on the kubernetes-master node and each kubernetes-minion node in the cluster. <del> Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file. </del> <ins> Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce). </ins> ``` [root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
// start new KMS Plugin _ = mock.NewBase64Plugin(t, "@new-kms-provider.sock") // update encryption config <del> if err := os.WriteFile(filepath.Join(test.configDir, encryptionConfigFileName), []byte(encryptionConfigWithNewProvider), 0644); err != nil { t.Fatalf("failed to update encryption config, err: %v", err) } </del> <ins> updateFile(t, test.configDir, encryptionConfigFileName, []byte(encryptionConfigWithNewProvider)) </ins> wantPrefixForSecrets := "k8s:enc:kms:v1:new-kms-provider-for-secrets:" // implementing this brute force approach instead of fancy channel notification to avoid test specific code in prod. // wait for config to be observed <del> verifyIfKMSTransformersSwapped(t, wantPrefixForSecrets, "", test) </del> <ins> verifyIfKMSTransformersSwapped(t, wantPrefixForSecrets, test) </ins> // run storage migration // get secrets

Discussion:
transformation expandless | 14m1s Failed; === RUN TestEncryptionConfigHotReload TestEncryptionConfigHotReload When I see this flake, 10-09 is the first one.(But the job history in the testgrid only started from 10-03) some PR that may be related: /sig auth /cc
/cc
/triage accepted
/cc failed two times in recent 3 runs:
/reopen as of this is still .
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
NodeName             string               `json:"nodeName"` AuthorizationModes   []string             `json:"authorizationModes,omitempty"` <ins> // Mark the controller and api server pods as privileged as some cloud // controllers like openstack need escalated privileges under some conditions // example - loading a config drive to fetch node information PrivilegedPods bool `json:"privilegedPods"` </ins> Token    string           `json:"token"` TokenTTL *metav1.Duration `json:"tokenTTL,omitempty"`

Discussion:
Dear All: I'm not sure if I'm right. When i use whith .I found controller-manager logs Someone can help me? Thanks a lot.
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
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
Please give more information about your set up cc
Sorry for report later. My openstack didn't support metadata service,but support config-drive service. More info:
Thanks Based on this, I think it's an openstack cloudprovider problem more than a kubeadm problem...
Thank you for help me. I will change the label.
/area cloudprovider
/remove-kind support
Should be fixed with you can specify a search order for metadata and config drive /close
Specifying a search order doesn't really solve the problem, especially if the metadata api isn't available which is what ZhenyangZhao said . I'm getting the same issue and since the config drive is my only option at the moment.
Like for this to be /open
can you please provide logs/versions for your problem in your environment? Thanks, Dims
Let me know if you need anything else Kubernetes version: 1.8.4 Docker version: 17.09.0-ce Linux: CentOS 7.4 Looking at the docker container log for the api-server (I don't have problems with the controller-manager):
and share the following:
Hi! Thank you for filing this issue. We appreciate your interest in Kubernetes and kubeadm. In order to make the kubernetes/kubernetes issue tracker more usable, we're routing issues to different repositories with different focuses. I think this issue belongs in the kubeadm repository. Please move this issue to the in order for the kubeadm team to be able to track this efficiently. If you disagree with my assessment of moving this issue, please speak up and/or reopen the issue. Finally, please try to reproduce the bug with the latest Kubernetes version, it might as well already have been fixed :) Thank you and have a good day!
Change:
fi if [[ "${OS_DISTRIBUTION}" == "gci" ]]; then <del> # If the master or node image is not set, we use the latest GCI dev image. # Otherwise, we respect whatever set by the user. </del> <ins> # If the master image is not set, we use the latest GCI dev image. # Otherwise, we respect whatever is set by the user. </ins> gci_images=( $(gcloud compute images list --project google-containers  --regexp='gci-dev.*' --format='value(name)') ) <del> if [[ -z "${MASTER_IMAGE:-}" ]]; then MASTER_IMAGE="${gci_images[0]}" MASTER_IMAGE_PROJECT="google-containers" fi if [[ -z "${NODE_IMAGE:-}" ]]; then NODE_IMAGE="${gci_images[0]}" NODE_IMAGE_PROJECT="google-containers" fi </del> <ins> MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-"${gci_images[0]}"} MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-google-containers} # The default node image when using GCI is still the Debian based ContainerVM # until GCI gets validated for node usage. NODE_IMAGE=${KUBE_GCE_NODE_IMAGE:-${CVM_VERSION}} NODE_IMAGE_PROJECT=${KUBE_GCE_NODE_PROJECT:-google-containers} </ins> fi # Verfiy cluster autoscaler configuration.

Discussion:
As of (specifically ), running against GCE without setting a node image defaults it to containervm, whereas before it defaulted it to the master image. For example, my config of: brings up a coreos master and then launches nodes with images. Before the above-referenced change this gave me my expected coreos nodes. Was this change intentional? The easiest fix that comes to mind for me is only doing the new containervm defaulting if is gci. cc
Yeah, this was something I was concerned too while making the change. However, the decision seems to have been that we decided to default to GCI, yet still default to the debian based containervm. Also, if we are to seriously start supporting hybrid clusters, i.e., master and nodes run on different OS distros, which seems true according to , this old assumption of defaults to needs to disappear anyways. cc/ Thoughts?
That sounds reasonable to me. We clearly didn't think about your use case whilst making this change.
I don't see the issue with defaulting to non-hybrid while supporting hybrid.. Defaulting seems totally reasonable even in a world where hybrid support is possible. A user could explicitly control that they want hybrid via setting them to different values regardless of the defaulting, or wherever hybrid is toggled on different defaulting could be done. I left a few questions on the referenced original issue which, if/when answered, might help me in making a PR to fix this for my usecase more cleanly.
Agreed. I am making a fix to this.
Change:
"Currently only applies to long-running requests.") fs.IntVar(&s.MasterCount, "apiserver-count", s.MasterCount, <del> "The number of apiservers running in the cluster, must be a positive number.") </del> <ins> "The number of apiservers running in the cluster, must be a positive number. (In use when --endpoint-reconciler-type=master-count is enabled.)") </ins> fs.StringVar(&s.EndpointReconcilerType, "endpoint-reconciler-type", string(s.EndpointReconcilerType), "Use an endpoint reconciler ("+strings.Join(reconcilers.AllTypes.Names(), ", ")+")")

Discussion:
ref: and An e2e test should be , and the default should be updated. /assign cc
/assign
Thanks I can take this on.
Could someone point me to where the manifests are for the e2e test suites, I am happy to submit the patches?
Are there API server e2e tests currently?
there are not HA API server e2e tests that I'm aware of
I opened a PR for the default changes. Are there suggestions on a good E2E test to write if we don't have HA API server tests?
what is needed for this issue to complete? Do you think you'll get that by Monday, which is Code Freeze?
We need some E2E testing or add an integration test as defined . It will not be done today.
so are you planning to move it to 1.11, then? It's about to be automatically kicked out of 1.10 by automation.
I do not have permission to change the milestone. If you could kindly change it, that would be awesome!
[MILESTONENOTIFIER] Milestone Removed From Issue Important: This issue was missing the label for more than 7 days. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Reopening as this was reverted in
Change:
pod.ObjectMeta.Annotations = map[string]string{ kubelettypes.ConfigSourceAnnotationKey: kubelettypes.FileSource, } <del> pod.Spec.PriorityClassName = systemCriticalPriorityName pod.Spec.Priority = &value </del> <ins> pod.Spec.PriorityClassName = scheduling.SystemNodeCritical </ins> framework.ExpectEqual(kubelettypes.IsCriticalPod(pod), true, "pod should be a critical pod") } else {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
type daemonSetsController struct { *DaemonSetsController <del> dsStore   cache.Store podStore  cache.Store nodeStore cache.Store </del> <ins> dsStore      cache.Store podStore     cache.Store nodeStore    cache.Store fakeRecorder *record.FakeRecorder </ins> } func newTestController(initialObjects ...runtime.Object) (*daemonSetsController, *fakePodControl, *fake.Clientset) {

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): DaemonSet FailedPlacement Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): OL7.3 Kernel (e.g. ): 4.1.12-94.2.1.el7uek.x86_64 Install tools: Others: What happened: I have a DaemonSet that is only deployed to a subset of nodes in the cluster based on a . I'm seeing events fired with reason for the daemonset pods on nodes that do not fit the selector. What you expected to happen: These events should never fire because they do not meet the node selectors in the pod spec. How to reproduce it (as minimally and precisely as possible): Create a cluster with different sized nodes. E.g. smaller masters than workers. Then deploy the daemonset only to the workers. You will see events triggered for the master nodes that don't meet the requirements. Anything else we need to know:
DaemonSet controller will run predicates to check if node should run daemon pod. In the progress of predicates, it will check if pod fits resources first before other predicates such as PodSelectorMatches. /cc
I think this bug appeared when critical pods were introduced and order of checking predicates changed. The event is useless for daemonsets in current situation :/ I'm not sure if there is a clean way to fix it.
I feel like a clean solution would be to look at the predicate reasons twice. The first time you look at the reasons and keep track if any are not intentional. If all of the reasons are intentional then skip checking the reasons.
actually just changing the order of checks in GeneralPredicates may just work. I'm testing the fix now.
Ok, GeneralPredicates returns all reasons. Error that pod doesn't match the node is also returned but because it's "intentional" there is no event for it.

The event "Node didn't have enough resource" should be sent only when there are no other "intentional" reasons.
Yes, I think maybe we need to check reason list twice: check is in tail of predicate list.
/cc
any PR for this? If not, I can help
I will have some time to work on it next week. If you have a spare time you can create a PR.
/assign
Change:
R: &etcd.Response{ EtcdIndex: 10, Node: &etcd.Node{ <ins> Dir: true, </ins> Nodes: []*etcd.Node{ { <ins> Key:           "/foo", </ins> Value:         `{"id":"foo","kind":"Pod","apiVersion":"v1beta1"}`, ModifiedIndex: 1, }, { <ins> Key:           "/bar", </ins> Value:         `{"id":"bar","kind":"Pod","apiVersion":"v1beta1"}`, ModifiedIndex: 2, }, { <ins> Key:           "/baz", </ins> Value:         `{"id":"baz","kind":"Pod","apiVersion":"v1beta1"}`, ModifiedIndex: 3, }, { <ins> Key:   "/directory", </ins> Value: `{"name": "directory"}`, Dir:   true, },

Discussion:
kubectl returns resources in a random order, which makes it hard to look for things when users have a lot resources. Returning resources in deterministic order should be a helpful and trivial change (hopefully). We have an issue about pagination , but that's a larger and separate issue.
We should be cause to not do this on the * namespace - I think thats a special case. No disagreement for other list calls
What is the default etcd response order? Last created or last modified? Sent from my iPhone
I think the order is by key if sort param is given. If not given, the order is by last created (maybe, but we shouldn't trust it). It seems we are not trying to get sorted result from etcd.
Today, I think it's random order in the child key space in etcd (because the node structure uses a map), so you get golang map iteration order without sort. I don't know if sort on server is any cheaper than sort on client today, so we may want to do this in rest / registry rather than by passing etcd.
Apart from performance, sorting in clients means we can also take control of how responses are sorted, so for * namespace, we can sort by namespace, then by resource ID. , Clayton Coleman wrote: Master of Electrical and Computer Engineering Carnegie Mellon University
We can always hint sort to the registry storage layer in the future, so sorting on the client now won't kill us.
Just took a closer look at our rest/registry code to implement the sort (in client), but implementation-wise, it seems much easier to pass sort to etcd (one line change). Also, namespace is a prefix on resource, so sort across all namespace with etcd key will essentially sort resources by namespace then by Name. If we are to implement sort on client side, we can either: sort package: have each list object, ie.e PodList, ControllerList, implement sort interface. (We won't do this). have ListMeta implement sort interface, if there is a way to find enclosing structs (so we can use items field) have api.Object implement sort interface, verify object is list before sorting. sort algorithm ourself, and do it in rest. Is there other golang or kubernetes idom that I haven't been aware of that can be applied to this use case?

----- Original Message ----- I think sorting it on etcd is fine for now - that's the simplest possible thing that works.
Is there any material perf impact in etcd to enable it? Sent from my iPhone
Probably not material. Can always switch away if necessary
Famous last words :-) Sent from my iPhone
Got my hat ready
Change:
} versionPath := pkgPath(group, version) <del> generator := pkg_runtime.NewDeepCopyGenerator(api.Scheme.Raw(), versionPath, sets.NewString("k8s.io/kubernetes")) </del> <ins> generator := kruntime.NewDeepCopyGenerator(api.Scheme.Raw(), versionPath, sets.NewString("k8s.io/kubernetes")) </ins> generator.AddImport(path.Join(pkgBase, "api")) if len(*overwrites) > 0 {

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done: