jiebi/CodeConvo huggingface dataset:
Change:
return RegisterPluginAsExtensions(pluginName, pluginNewFunc, "Filter") } <ins> // RegisterReservePlugin returns a function to register a Reserve Plugin to a given registry. func RegisterReservePlugin(pluginName string, pluginNewFunc runtime.PluginFactory) RegisterPluginFunc { return RegisterPluginAsExtensions(pluginName, pluginNewFunc, "Reserve") } // RegisterPermitPlugin returns a function to register a Permit Plugin to a given registry. func RegisterPermitPlugin(pluginName string, pluginNewFunc runtime.PluginFactory) RegisterPluginFunc { return RegisterPluginAsExtensions(pluginName, pluginNewFunc, "Permit") } // RegisterPreBindPlugin returns a function to register a PreBind Plugin to a given registry. func RegisterPreBindPlugin(pluginName string, pluginNewFunc runtime.PluginFactory) RegisterPluginFunc { return RegisterPluginAsExtensions(pluginName, pluginNewFunc, "PreBind") } </ins> // RegisterScorePlugin returns a function to register a Score Plugin to a given registry. func RegisterScorePlugin(pluginName string, pluginNewFunc runtime.PluginFactory, weight int32) RegisterPluginFunc { return RegisterPluginAsExtensionsWithWeight(pluginName, weight, pluginNewFunc, "Score")

Discussion:
This is a bug found in The scheduler fails to schedule the pod on the first try due to PV is out of sync. This may happen because the PV/PVC may be modified before the scheduler binder assumes them. However, the scheduler skips the pod update event and never try to scheduler the pod again: This is because when the reserve plugins fails, we didn't try to forget the pod. After the is called, the pod is in the state.
/sig scheduling /sig storage /assign /priority critical-urgent
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig scheduling /sig storage /assign /priority critical-urgent 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:
var err error image := "gcr.io/google_containers/serve_hostname:v1.4" BeforeEach(func() { <ins> framework.SkipUnlessProviderIs("gce", "gke", "aws") </ins> if zoneCount <= 0 { zoneCount, err = getZoneCount(f.Client) Expect(err).NotTo(HaveOccurred()) } By(fmt.Sprintf("Checking for multi-zone cluster.  Zone count = %d", zoneCount)) framework.SkipUnlessAtLeast(zoneCount, 2, "Zone count is %d, only run for multi-zone clusters, skipping test") <del> framework.SkipUnlessProviderIs("gce", "gke", "aws") </del> // TODO: SkipUnlessDefaultScheduler() // Non-default schedulers might not spread }) It("should spread the pods of a service across zones", func() {

Discussion:
Filing separate follow up from . The issue should have been caught by failing. The suite needs a specific feature test that e.g. looks at node labels to verify multiple zones are present. cc
Yes, you make a good point. The tests currently work the other way around. If the tests detect a multi-zone cluster, they run, otherwise they skip. This makes it safe to run against any cluster, and makes test configuration much simpler. To achieve what you suggest, we will need to add a test for multi-zone that is skipped by default (i.e. in all other test jobs), and only runs on that test job (kubernetes-e2e-gce-ubernetes-lite), failing if multiple zones are not detected.
should we target this one for v1.4, or bump it to 1.5?
Moving out of v1.4 as this is a P2.
This issue was labelled only for sig/multicluster and is thus moved over to kubernetes/federation. If this does not seem to be right, please reopen this and notify us /close
Change:
return nil, err } <del> oauthConfig, err := adal.NewOAuthConfig(env.ActiveDirectoryEndpoint, token.tenantID) </del> <ins> oauthConfig, err := adal.NewOAuthConfigWithAPIVersion(env.ActiveDirectoryEndpoint, token.tenantID, nil) </ins> if err != nil { return nil, fmt.Errorf("building the OAuth configuration for token refresh: %v", err) }

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: In the to acquire AAD token, because of the inclusion of the API version in the URLs for authorization, the returned token is not compatible with many AAD scenarios like OIDC and On-Behalf-Of flow. There is a long list of issues documenting this problem: The fix is pretty simple, use with set to . This incompatible behavior impacts What you expected to happen: Follow the to acquire AAD token How to reproduce it (as minimally and precisely as possible): use kubectl to get AAD token, paste token into and verify the audience claim Anything else we need to know?: Environment: Kubernetes version (use ): all versions 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:
/area provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /area provider-azure 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/azure
/sig cli
/sig cloud-provider
/assign
Change:
# Test that it works when the live object doesn't exist output_message=$(! kubectl diff -f hack/testdata/pod.yaml) kube::test::if_has_string "${output_message}" 'test-pod' <ins> # Ensure diff only dry-runs and doesn't persist change kube::test::get_object_assert 'pod' "{{range.items}}{{ if eq ${id_field:?} "test-pod" }}found{{end}}{{end}}:" ':' </ins> kubectl apply -f hack/testdata/pod.yaml <ins> kube::test::get_object_assert 'pod' "{{range.items}}{{ if eq ${id_field:?} "test-pod" }}found{{end}}{{end}}:" 'found:' </ins> # Make sure that diffing the resource right after returns nothing (0 exit code). kubectl diff -f hack/testdata/pod.yaml

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: fails. What you expected to happen: I would expect the PatchOptions to not include FieldManager. The following fix will eliminate the problem. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.16 and 1.17 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 cli
cc
/wg apply
cc
I agree, we clearly missed that. Would you mind sending the fix in the form of a PR? Also please include a test, because that shouldn't have happened if I had tested my code properly :-(
Clearly we should also cherry-pick that into 1.17. I'll send the PR on Monday if you prefer! Thanks.
Ok, I will send a PR. However, I can't include a test immediately because I don't understand how the test works.
Thanks, I’ll try to show you how to get started!
Any update we clearly need this promptly since code-freeze is coming! Thanks.
I'll send a PR on Monday if you haven't! Thanks.
Sorry, I haven't started working on this test. Thanks.
Change:
responses: 200: body: <del> application/json: example: !include examples/controller.json </del> <ins> example: !include examples/controller.json </ins> put: description: Update a controller body: <del> json/application: schema: !include doc/controller-schema.json example: !include examples/controller.json </del> <ins> schema: !include doc/controller-schema.json example: !include examples/controller.json </ins> delete: description: Delete a specific controller responses: 200: body: <del> application/json: example: | { "success": true } </del> <ins> example: | { "success": true } </ins> /services: get:

Discussion:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.
Change:
return nil } <ins> // selinux.SELinuxEnabled implementation for unit tests type seLinuxEnabledFunc func() bool </ins> // GetSELinux is common implementation of GetSELinuxSupport on Linux. <del> func GetSELinux(path string, mountInfoFilename string) (bool, error) { </del> <ins> func GetSELinux(path string, mountInfoFilename string, selinuxEnabled seLinuxEnabledFunc) (bool, error) { // Skip /proc/mounts parsing if SELinux is disabled. if !selinuxEnabled() { return false, nil } </ins> info, err := findMountInfo(path, mountInfoFilename) if err != nil { return false, err

Discussion:
On a busy system, kubelet failed to tell the container runtime that a pod's CSI volume supports SELinux and should be relabeled with pod's SELinux label. The pod then can't access the volume. Kubelet correctly detects that the CSI volume supports SELinux and tells the container runtime to relabel it. Unknown. Get a busy system and try hard? CSI volume plugin tried to detect that the volume supports SELinux during SetupAt. This check failed: Current CSI volume plugin code silently consumes the error and assumes that the volume does not support SELinux at all: Therefore, the volume is marked as mounted and given to the container runtime without the right SELinux options and the runtime does not relabel volume. <details22.0 </details<detailsNone </details<details</details<details</details<detailsCRI-O, but I think it's not really relevant. </details<details</details
/sig storage /triage accepted
We've updated kubelet in our clusters to v1.20.13 (which contains the cherry picked fix), but still observe the issue
Change:
var _ error = &StatusError{} <ins> var knownReasons = map[metav1.StatusReason]struct{}{ // metav1.StatusReasonUnknown : {} metav1.StatusReasonUnauthorized:          {}, metav1.StatusReasonForbidden:             {}, metav1.StatusReasonNotFound:              {}, metav1.StatusReasonAlreadyExists:         {}, metav1.StatusReasonConflict:              {}, metav1.StatusReasonGone:                  {}, metav1.StatusReasonInvalid:               {}, metav1.StatusReasonServerTimeout:         {}, metav1.StatusReasonTimeout:               {}, metav1.StatusReasonTooManyRequests:       {}, metav1.StatusReasonBadRequest:            {}, metav1.StatusReasonMethodNotAllowed:      {}, metav1.StatusReasonNotAcceptable:         {}, metav1.StatusReasonRequestEntityTooLarge: {}, metav1.StatusReasonUnsupportedMediaType:  {}, metav1.StatusReasonInternalError:         {}, metav1.StatusReasonExpired:               {}, metav1.StatusReasonServiceUnavailable:    {}, } </ins> // Error implements the Error interface. func (e *StatusError) Error() string { return e.ErrStatus.Message

Discussion:
Checked a method error using when the error was caused by a validating webhook that returns a 403 response. In this particular case, the error was generated from a validating webhook implemented with controller-runtime that returns controller-runtime's response. to return true. returned false Many (but not all) of the other family of functions in suffer the same kind of problem. I have changes ready to submit in a PR if we can get agreement that this is a problem and that it should be fixed in the functions that ought to check the of an erorr value that is or wraps an Kubernetes version (use ): 19.3 for the server
/sig api-machinery
are you going to send a PR for this? The issue description looks reasonable. /triage accepted
Thanks, PR is submitted.
/assign
Change:
You can also use `kubectl` command to see if the newly created k8s is working correctly. The `kubectl` binary is under the `cluster/ubuntu/binaries` directory. You can move it into your PATH. Then you can use the below command smoothly. <del> For example, use `$ kubectl get minions` to see if you get all your minion nodes comming up and ready. It may take some times for the minions be ready to use like below. </del> <ins> For example, use `$ kubectl get nodes` to see if all your minion nodes are in ready status. It may take some time for the minions ready to use like below. </ins> ``` <del> NAME                 LABELS             STATUS 10.10.103.162       <none>              Ready </del> <ins> NAME            LABELS                                 STATUS </ins> <del> 10.10.103.223       <none>              Ready </del> <ins> 10.10.103.162   kubernetes.io/hostname=10.10.103.162   Ready 10.10.103.223   kubernetes.io/hostname=10.10.103.223   Ready 10.10.103.250   kubernetes.io/hostname=10.10.103.250   Ready </ins> <del> 10.10.103.250       <none>              Ready </del> ```

Discussion:
This flag is deprecated and no longer has any effect.
I wonder which version does this include.Now ubuntu approach is using ubuntu 0.15.0.
This change was checked in this week, so it will be true for clusters at 0.18.0+ (once the next release is cut next week). So the next time the ubuntu documentation is updated, this change should be reflected.
Ohit means that minion node can be automatically discovered by the master node when then kubelet set ? No other configuration is needed?
Yes, the kubelet, when passed the location of the apiserver, will register itself and then post node update messages. The only part that may depend on your deployment environment is the set of addresses that the kubelet passes to the apiserver. They will be based on the name of the node, reverse resolving the name of the node, or checking for addresses from the cloud provider.
Got it.I will include this when I updates the doc and scripts. Besides, I have a little questions here. Eric told me the addon services do not have service-account now.Will 0.18.0+ have it?
Service accounts will be included as part of 0.18.0 as well.
got it
- makes sense
Change:
16: "3.3.17-0", 17: "3.4.3-0", 18: "3.4.3-0", <del> 19: "3.4.9-1", </del> <ins> 19: "3.4.13-0", </ins> 20: "3.4.13-0", 21: "3.4.13-0", }

Discussion:
What happened: Found while testing kubeadm 1.20 for openSUSE Kubic in openQA. The test attempted to bootstrap a simple kubernetes 1.19.4 cluster with but this test failed, complaining it could not find a etcd container with tag - etcd 3.4.9 images were removed from our registry after the recent CVE, which was resolved by 3.4.13, which was supported as of k8s 1.19.1 ( for reference) This seems to be because still references etcd 3.4.9 for clusters of version even though 3.4.13 is the correct version to be used. Thanks to for finding that. What you expected to happen: Kubeadm should use etcd v3.4.13 for all clusters version 1.19.1 and higher How to reproduce it (as minimally and precisely as possible): Run , check version of etcd. It should be , but with this bug it will be Anything else we need to know?: Environment: OS (e.g: ): NAME="openSUSE MicroOS" ID="opensuse-microos" IDLIKE="suse opensuse opensuse-tumbleweed" VERSIONID="" PRETTYNAME="openSUSE MicroOS" ANSICOLOR="0;32" CPENAME="cpe:/o:opensuse:microos:" BUGREPORTURL="" HOMEURL="" DOCUMENTATIONURL="" LOGO="distributor-logo" Kernel (e.g. ): Linux r2d2 5.9.12-1-default SMP Wed Dec 2 09:24:35 UTC 2020 () x8664 x8664 x8664 GNU/Linux /sig cluster-lifecycle
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 cluster-lifecycle
/assign
According to , the cve is fixed in 3.4.13+ & 3.3.25+ & 3.5+.

: Fix CVE-2020- and CVE-2020-. Should we upgrade all etcd versions which has the issue in 1.19 or 1.18?
the fix for the default behavior at master and 1.20 is fine. for readers, note that you can always override the etcd image using ClusterConfiguration.Etcd.
Change:
deps = [ "//cmd/kube-scheduler/app/config:go_default_library", "//cmd/kube-scheduler/app/options:go_default_library", <del> "//pkg/api/legacyscheme:go_default_library", </del> "//pkg/scheduler:go_default_library", "//pkg/scheduler/apis/config:go_default_library", "//pkg/scheduler/framework/runtime:go_default_library",

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: Kube-Scheduler exposes metrics in a secure manner (TLS and authentication required) on port by default. If one does not authenticate itself, the error message displayed is: What you expected to happen: Kube-Scheduler should emit a clear and understandable error message if authentication fails. Kube-Controller-Manager does that the following way: How to reproduce it (as minimally and precisely as possible): up a Kubernetes Cluster to access the exposed metrics endpoint (https://metrics-server:/metrics) without authentication Anything else we need to know?: xref: Environment: Kubernetes version (use ): 1.18.6 Cloud provider or hardware configuration: Bare metal OS (e.g: ): Debian GNU/Linux 10 (buster) Kernel (e.g. ): 4.19.0-9-amd64 Install tools: Kubeadm (Kube-Scheduler )
/sig scheduling instrumentation
If ok, I can try this fix /assign
/assign
Change:
} uid := string(uuid.NewUUID()) <ins> klog.V(6).InfoS("Encrypting content using envelope service", "uid", uid, "key", string(dataCtx.AuthenticatedData())) </ins> resp, err := t.envelopeService.Encrypt(ctx, uid, newKey) if err != nil { return nil, fmt.Errorf("failed to encrypt DEK, error: %w", err)

Discussion:
Add additional logging at level that associates UID with the metadata from the request. xref: /sig auth
/triage accepted
/milestone v1.26
Mind if I take a look at this? /assign
Hello I am wondering how's this coming along. Is there anything I can help with?
Sorry. I got a bit occupied with a different project.. Will have a PR opened for this for review tomorrow.. I am trying to find a way to inject the Verbs into log. But haven't found the right way to include that into the context.. Any suggestion on what can be done?
any suggestion on what is the best way to get the additional metadata for verbs into this log? Move that info across using ?
Hello , bug triage team here, just wanted to touch base with you for updates on this ticket. Thanks!
Thanks! This is being worked on and is still on track for .
There is a Pull request opened on this already as well. But Waiting on some clarification to see if that needs additional changes.
/reopen /assign /unassign
Reopened this issue. <detailsIn response to : /reopen /assign /unassign 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.27
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]:
/remove-lifecycle stale
Hi Bug Triage Team for v1.27 here o/ Just wanted to touch base with you for updates on this ticket. Thanks!
I am not working on this anymore Carlos. This was re-assigned
This is tracked for . I've linked the PR.
Change:
) // Fit is determined by non-conflicting disk volumes. <del> scheduler.RegisterFitPredicate(predicates.NoDiskConflictPred, predicates.NoDiskConflict) </del> <ins> scheduler.RegisterFitPredicateFactory( predicates.NoDiskConflictPred, func(args scheduler.AlgorithmFactoryArgs) predicates.FitPredicate { return nil }, ) </ins> // GeneralPredicates are the predicates that are enforced by all Kubernetes components // (e.g. kubelet and all schedulers)

Discussion:
/sig scheduling /priority important-soon See as an example. Part of /assign
GitHub didn't allow me to assign the following users: angao. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /sig scheduling /priority important-soon 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
thx, I will do it soon.
Change:
for url in "${urls[@]}"; do local file="${url##*/}" rm -f "${file}" <del> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --max-time 80 --retry 6 --retry-delay 10 "${url}"; then </del> <ins> if ! curl -f --ipv4 -Lo "${file}" --connect-timeout 20 --max-time 300 --retry 6 --retry-delay 10 "${url}"; then </ins> echo "== Failed to download ${url}. Retrying. ==" elif [[ -n "${hash}" ]] && ! validate-hash "${file}" "${hash}"; then echo "== Hash validation of ${url} failed. Retrying. =="

Discussion:
We download the kube bundle from S3 with curl . But, now that the bundle is well over 1GB, 80 seconds is often not long enough on some of the smaller AWS instances (I think it's a combo of disk slowness, CPU slowness for the SSL and network slowness). PR coming which bumps it to 300 once I have tested it.