jiebi/CodeConvo huggingface dataset:
Change:
wantMetricStrings := []string{ `apiserver_encryption_config_controller_automatic_reload_last_timestamp_seconds{apiserver_id_hash="sha256:3c607df3b2bf22c9d9f01d5314b4bbf411c48ef43ff44ff29b1d55b41367c795",status="success"} FP`, `apiserver_encryption_config_controller_automatic_reload_success_total{apiserver_id_hash="sha256:3c607df3b2bf22c9d9f01d5314b4bbf411c48ef43ff44ff29b1d55b41367c795"} 2`, <ins> `apiserver_encryption_config_controller_automatic_reloads_total{apiserver_id_hash="sha256:3c607df3b2bf22c9d9f01d5314b4bbf411c48ef43ff44ff29b1d55b41367c795",status="success"} 2`, </ins> } test.secret, err = test.createSecret(testSecret, testNamespace)

Discussion:
Change encryption config controller reload metrics to be consistent with other places (Authn, Authz) xref: Combine and into a single metric with with an enum value of and . /sig auth /triage accepted
cc
We probably should keep the existing metrics for some time to allow folks to migrate to the new one.
Ah I was thinking about this as well! Looking at "may be deleted at any time", I was leaning towards just removing it. If the common approach is to keep it for a release before removing, we could do that. I believe we can set a for the 2 metrics we want to remove.
I don't have a good sense of metrics stability because they tend to stay alpha forever and folks don't go back to update them. Since the associated feature set is GA, I think we should be conservative with the changes we make. Perhaps SIG instrumentation folks can provide some guidance here?
As part of the PR, I was going to ask when is the right time to graduate these metrics do you have thoughts on to take while deleting an alpha metric metrics should be graduated from alpha to beta and stable?
Change:
rbacv1 "k8s.io/api/rbac/v1" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apiserver/pkg/authentication/user" </ins> "k8s.io/apiserver/pkg/authorization/authorizer" utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/component-base/featuregate"

Discussion:
What happened: I checked if kubelet () has permissions for with SelfsubjectAccessReviews and I saw that it has. But when I checked its permissions with SelfsubjectRulesReviews it didn't show it. What you expected to happen: I expected that the API SelfsubjectRulesReviews will show that has permssions for . How to reproduce it (as minimally and precisely as possible): You can check it on the master or the worker. Test SelfsubjectAccessReviews: You will get answer that it has permissions: Test SelfsubjectRulesReviews: It won't show the permissions. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ):Install tools: kubeadm /area/api /kind/bug /sig api-machinery
/sig api-machinery
This is a more clean display that show the bug: I think the problem is related to the fact that the file contain the kubelet certificate which is part of the group :
/sig auth
What is the SelfSubjectRulesReview response from the server ()? Note that not all authorizers support enumerating permissions, and the API object status includes an attribute which explicitly indicates the result is incomplete. See
It has Details:
I noticed that it also doesn't show that it has permissions to view and . It probably related to the Node authorizer: Because I assume that these rules doesn't appear in RBAC.
The node authorizer does not enumerate permissions, so it does not contribute to SelfSubjectRulesReview results
fixes setting correctly when the API is requested with a kubelet's credentials
Change:
if resp.Url == "" { errorMessage := "URL is not set" <del> klog.Errorf("Exec failed: %s", errorMessage) </del> <ins> klog.Errorf("Attach failed: %s", errorMessage) </ins> return nil, errors.New(errorMessage) } return resp, nil

Discussion:
What happened: In , there is mismatch between method name and the method in logs. e.g. RemoteRuntimeService#Attach has the following: What you expected to happen: The method names should be consistent with what appear in the logs. Otherwise people would be confused when troubleshooting. /sig node
could i try to fix this?Thanks
Yes. fixes method name for ContainerStats. You can cover the rest. thanks
/assign
Change:
deps = [ "//staging/src/k8s.io/cli-runtime/pkg/genericclioptions:go_default_library", "//staging/src/k8s.io/kubectl/pkg/cmd/util:go_default_library", <ins> "//vendor/github.com/spf13/cobra:go_default_library", </ins> ], )

Discussion:
What happened: I am using a command like below in GitHub actions: I get the following error: What you expected to happen: Since I am using flag, it should work without requiring a valid kubeconfig file. How to reproduce it (as minimally and precisely as possible): Just delete your local kubeconfig file and try the above command. 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 cli
/assign /kind regression
This likely breaks some scripted usage of kubectl
This is related to /assign
Or
Yes, sorry I mentioned you in this issue. Because my first thought is this brings and which will check the config file existence but in fact that's not the root cause. Actually the root cause This checks config has the server or not. And with this , this function will return error when there's no local config file. I think there might be two solutions? the similar logic like to every , , ..... when or is set. Seems not a good idea. reverse this to have the default server which is better than ? By the way, is equals ? Since This works only for .
The plan I agreed on with Jordan is that I will revert since that seems to be the main culprit behind all these problems. I'll add a test ensuring this works as required. This will allow us to backport the fix to 1.18. For 1.19 I'll put together a proper fix supporting and flags.
Change:
} var defaultParameterEncoder runtime.ParameterCodec = parameterCodec{} <ins> type versionedParameterEncoderWithV1Fallback struct{} func (versionedParameterEncoderWithV1Fallback) EncodeParameters(obj runtime.Object, to unversioned.GroupVersion) (url.Values, error) { ret, err := api.ParameterCodec.EncodeParameters(obj, to) if err != nil && runtime.IsNotRegisteredError(err) { // fallback to v1 return api.ParameterCodec.EncodeParameters(obj, v1.SchemeGroupVersion) } return ret, err } func (versionedParameterEncoderWithV1Fallback) DecodeParameters(parameters url.Values, from unversioned.GroupVersion, into runtime.Object) error { return errors.New("DecodeParameters not implemented on versionedParameterEncoderWithV1Fallback") } // VersionedParameterEncoderWithV1Fallback is useful for encoding query // parameters for thirdparty resources. It tries to convert object to the // specified version before converting it to query parameters, and falls back to // converting to v1 if the object is not registered in the specified version. // For the record, currently API server always treats query parameters sent to a // thirdparty resource endpoint as v1. var VersionedParameterEncoderWithV1Fallback runtime.ParameterCodec = versionedParameterEncoderWithV1Fallback{} </ins>

Discussion:
It seems to me like all of the garbage collection integration tests produce a ton of log messages of the form:
Change:
local output=`check-minion ${minion_ip}` echo $output if [[ "${output}" != "working" ]]; then <del> if (( attempt > 9 )); then </del> <ins> if (( attempt > 20 )); then </ins> echo echo -e "${color_red}Your cluster is unlikely to work correctly." >&2 echo "Please run ./cluster/kube-down.sh and re-create the" >&2

Discussion:
When creating a new cluster on AWS with the 1.2 version I always get a failure when checking docker on the nodes, but after the check loop ends everything seems to work fine and all nodes are marked as ready. The instance types for nodes is
That is very surprising. Are you using any particular settings (to help me try to reproduce the problem)?
These are the exports I make before running kube-up:
The problem is the instances take a very long time to start up. I had to increase the timeout to 19.
Hey how did you increase the timeout? Didn't see a setting in config- that I could override. Getting the same issue as the poster.
Thanks , that did the trick!
Change:
}) ginkgo.BeforeEach(func() { <del> if err := lookEmitSignalCommand(); err != nil { e2eskipper.Skipf("skipping test because: %v", err) return } </del> ginkgo.By("Wait for the node to be ready") waitForNodeReady()

Discussion:
xref: Graceful node shutdown test uses to invoke dbus - As per some distros, don't have installed so the test must be skipped in those environments. We should consider if we can switch to use or perhaps and fall back to to ensure the test can work across more distros.
/sig node
/sig testing
/remove-kind bug /kind feature I'm putting kind feature to signify that nothing is really broken in k8s, tests needs improvement.
/remove-sig testing This dbus command should be up to SIG node, though tentatively: /triage accepted
/area test
Do we actually have these other distros available to prevent regressions if we change that?
/assign
the change will be to replace skip logic when is missing to use an alternative way to send this. So there will be no regression on distros where it currently runs without the skip. Original bug should have a link to job that was failing
I would like to work on improving the command. Am I understanding correct here We have to change to logic where we skip to use busctl instead. Could you please give me some idea on how can we make it to use , some similar examples in the repo would be really useful.
please have a look at The issue is that the command available is too old and doesn't include .
I see, it looks like we are not just adding a condition for instead we are replacing it with . It looks you are already working on it. Please inform if I can help in anyway. Thanks for the response.
Both are possible... it was easier to get a CI signal if that was used in all cases. I might put the condition later. I am waiting for comments in the PR, but feel free to propose other solutions that might work with older systemd versions.
Change:
} patchBytes, patchObject, err = p.patchSimple(current, modified, source, namespace, name, errOut) } <del> if err != nil && errors.IsConflict(err) && p.force { </del> <ins> if err != nil && (errors.IsConflict(err) || errors.IsInvalid(err)) && p.force { </ins> patchBytes, patchObject, err = p.deleteAndCreate(current, modified, namespace, name) } return patchBytes, patchObject, err

Discussion:
/kind bug What happened: From I expected kubectl apply to support deleting a resource and recreating it, if changes cannot be applied. kubectl replace works: What you expected to happen: How to reproduce it (as minimally and precisely as possible): ` Change clusterIP to any IP address. Anything else we need to know?: Environment: Kubernetes version (use ): client v1.11.0, cluster v1.11.1 Cloud provider or hardware configuration: QEMU/KVM OS (e.g. from /etc/os-release): Cluster CentOS Linux release 7.5.1804 (Core), client macOS Kernel (e.g. ): 3.10.0-862.6.3.el7.x86_64 Install tools: kubeadm Others:
/cc
/assign
Change:
Filter: v1beta2.PluginSet{ Enabled: []v1beta2.Plugin{ {Name: "Plugin1"}, <ins> {Name: "Plugin2"}, {Name: "Plugin3"}, </ins> }, }, },

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 --Recent commit: import an issue when multiple custom plugin configured in scheduler config file, and those plugins are default plugins too. It was manipulating slice with index, but the slice is updated while index is not, which will cause the index out of range, see the exceptions listed below, config file should be handled properly without such exception override multiple default plugin in scheduler's config file. Kubernetes version (use ): latest (1.22) Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign
/sig scheduling /triage accepted
Change:
print_codegens exit 1 fi <del> codegens_to_run+=("${matches[@]}") </del> <ins> # The array-syntax abomination is to accommodate older bash. codegens_to_run+=("${matches[@]:+"${matches[@]}"}") </ins> done # If no codegens were specified, run them all.

Discussion:
I am working on a PR where I am removing some legacy code from a API. I believe I have to run some scripts to generate code. When I run I get the following error: I expect the script to work and run without error. Run hack/update- or run I am on the latest build. <details</details<details</details<details</details<details</details<details</details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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 are you synced to HEAD of master? what version of bash are you running?
I am synced to HEAD of master and my bash version is version 4.2.46(2).
Pretty sure identified it correctly as a bash version issue. I ran into this issue and it was due to using an older bash. I know that 4.2.46 (which is used in AL2) is too old, but I'm not sure exactly what the minimum version is. If you are using AL2 for development, this will drop in a compatible version:
/kind support
Let me see if there's a way to make old-bash shut up. Sadly I do not have an old version to try against - - are you willing to type commands into your shell for me?
Yep, you just caught me before I purged my old environment with suggestions.
would a slack conversation be easier?
maybe but I am juggling meetings :)
There are a few problems I ran into before just deciding to upgrade to bash v5, but I think this initial thing was a bug fixed in bash 4.4+: From, when the nounset option is enabled no longer throws an unbound variable error. So on 4.2, this fails:
working on a patch
Change:
} // TODO: if we ever want to go generic, this allows a clean -o yaml without trying to print columns or anything // rawExtension := &runtime.Unknown{ <del> // 	Raw: originalPatchedObjJS, </del> <ins> //	Raw: originalPatchedObjJS, </ins> // } printer, err := f.PrinterForMapping(cmd, mapping, false)

Discussion:
Hi, Deployment patching with doesn't show up in the deployment rollout history: first: after: Is it a bug? Should it show up? Thanks, Peter
cc
Which kubernetes and kubectl releases? Did the patch actually trigger a rollout?
I also run the command from CI with the latest . So the problem affects the v1.2.3 kubectl as well
We should also fix the way we sort revisions - 10 should be after 9, not 1.
Can confirm this. The issue is that the patch isn't updating , so the rollout history will just copy the value from the previous version. If you started with you get that for the patches. In my case I have a different line repeated. Builds 7 and 8 were built with different . I'm not sure why the patch worked once. Command I am calling is:
If no one is working on patch - i can try to make one.
I'll like to work on this issue if you haven't started yet
Actually never mind I can look at something else :)
Hi, i see that you are the author of the following comment. I think that currently every valid change cause is discarded because of version conflict. Maybe you have some information why it happens?
command instead generates a patch to update then applies that.
It was the same for patch, but for some reason was changed.
The intent was two fold. First, prevent the change-cause from ever failing patch the CLI command. change-cause isn't authoritative and the patch took hold, so a non-zero return code is inappropriate. Second, if the resource version change post-patch, before the update, the change-cause is unknown, something else touched it after the fact. A command that issues a instead of an could very easily break the history since patches will attempt to reapply themselves regardless of resource version in the face of conflicts. The object returned from the patch operation is the one that we use to avoid hitting a resource conflict with ourselves.

Truth be told, I don't feel very strongly about getting the history right since it can be changed anyone with write access to the object, includes secrets that should be elided (--token for instance), ignores environment variables which affect outcome, ignores the actual path used to locate the binary you're running, and references paths that are only good from one location on one machine, so if you want to switch it back to a second patch, I don't mind as long as a failure to update the object doesn't cause a non-zero return from the command.
Could there be a race between the call and the deployment updating itself to action the changes? On 19 May 2016 9:47 pm, "David Eads" wrote:
Change:
}, }), }, <ins> "bad-volume-zero-capacity": { isExpectedFailure: true, volume: testVolume("foo", "", core.PersistentVolumeSpec{ Capacity: core.ResourceList{ core.ResourceName(core.ResourceStorage): resource.MustParse("0"), }, AccessModes: []core.PersistentVolumeAccessMode{core.ReadWriteOnce}, PersistentVolumeSource: core.PersistentVolumeSource{ HostPath: &core.HostPathVolumeSource{ Path: "/foo", Type: newHostPathType(string(core.HostPathDirectory)), }, }, }), }, </ins> "missing-accessmodes": { isExpectedFailure: true, volume: testVolume("goodname", "missing-accessmodes", core.PersistentVolumeSpec{

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: If someone requests a zero (0) capacity PVC and an administrator creates a zero (0) capacity PV, Kubernetes will happily bind them together. Unfortunately, any use of this PVC/PV combination by a pod will fail. It fails because the zero capacity PV cannot be formatted or mounted successfully. Note: The same issue happens for dynamically provisioned PVs. What you expected to happen: I expect that Kubernetes would not allow creation of invalid PVC and PV objects, aka zero (0) capacity PVs and PVCs. How to reproduce it (as minimally and precisely as possible): Create a pod that requests a zero capacity PVC, using dynamic PV provisioning is simpler than creating your own zero (0) capacity PV. The pod will fail to reach a running state, since the related PV fails to be formatted and mounted successfully. Here is the error that I received for a test I performed requesting a zero capacity PVC using ceph rbd: Anything else we need to know?: Here is a related item with a specific fix for external ceph rbd provisioner: Environment: Nothing specific to environment
/sig storage
/assign
Change:
{testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 0, Patch: 0}}, {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 0}}, {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 10}}, <ins> {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 2, Patch: 0}}, </ins> {testName: "supported version", ver: &csipb.Version{Major: 1, Minor: 1, Patch: 0}}, {testName: "supported version", ver: &csipb.Version{Major: 1, Minor: 0, Patch: 10}}, {testName: "unsupported version", ver: &csipb.Version{Major: 10, Minor: 0, Patch: 0}, mustFail: true},

Discussion:
Current CSI E2E test has some issues which prevent it to run successfully the a local cluster. /sig storage /kind bug /assign
Change:
apiextensions.SetCRDCondition(crd, establishedCondition) updatedObj, err := c.crdClient.CustomResourceDefinitions().UpdateStatus(crd) <ins> if apierrors.IsNotFound(err) || apierrors.IsConflict(err) { // deleted or changed in the meantime, we'll get called again return nil } </ins> if err != nil { return err }

Discussion:
k8s version: v1.9.3 When I create customresourcedefinition, There is error like Operation cannot be fulfilled on "": the object has been modified; please apply your changes to the latest version and try again . apiVersion: kind: CustomResourceDefinition metadata: name: annotations: "": crd-install labels: app: istio-pilot spec: group: names: kind: VirtualService listKind: VirtualServiceList plural: virtualservices singular: virtualservice categories: istio-io networking-istio-io scope: Namespaced version: v1alpha3 So what is the reason of it?
a few questions: where are you seeing the error, in the apiserver log or in the output of the kubectl command? what kubectl command are you using to create the object? are you running HA apiservers?
The log is shown by apiserver. I run k8s in HA apiservers. The command I used is "kubectl apply -f "+file.
API servers attempt to update CRD status to indicate whether the names were available. In an HA apiserver setup, the API servers race to do so, and all but the first lose the race with a resource conflict error. That is not unexpected. Opened to avoid logging normal API responses in that scenario.
Thanks ! But I want to know whether the CRD has been set successfully in HA apiservers ? I use the command " kubectl get crd -o yaml" and get the following results. ! I see its status is true. But when i create a virtualservices, it returns error. Error from server (Timeout): error when creating "cms-api-": Timeout: request did not complete within allowed duration ! So i want to know how to solve this error.
/assign
Excuse me. Do you have some greate ideas to solve this issue??
There is a PR for this sent by
I see your request is timed-out not failed. In HA, I expect the request to fail in the first seconds of the CRD creation, but after that it should go through. I need more logs during this timeout or a consistent way to reproduce it.
Change:
The `KUBERNETES_PROVIDER` environment variable tells all of the various cluster management scripts which variant to use.  If you forget to set this, the assumption is you are running on Google Compute Engine. <ins> By default, the Vagrant setup will create a single master VM (called kubernetes-master) and one node (called kubernetes-node-1). Each VM will take 1 GB, so make sure you have at least 2GB to 4GB of free memory (plus appropriate free disk space). Vagrant will provision each machine in the cluster with all the necessary components to run Kubernetes.  The initial setup can take a few minutes to complete on each machine. </ins> If you installed more than one Vagrant provider, Kubernetes will usually pick the appropriate one. However, you can override which one Kubernetes will use by setting the [`VAGRANT_DEFAULT_PROVIDER`](https://docs.vagrantup.com/v2/providers/default.html) environment variable: ```sh

Discussion:
I cannot find such a service when . Same thing applies for . My cluster runs fine. cc:
Ah, good catch... everything is run as a container now, will update the documentation on where to get the logs.