jiebi/CodeConvo huggingface dataset:
Change:
- /run.sh resources: limits: <del> cpu: "0.5" image: gcr.io/google_containers/cassandra:v4 </del> <ins> cpu: "0.1" image: gcr.io/google_containers/cassandra:v5 </ins> name: cassandra ports: - name: cql

Discussion:
The namespace seems to be hard coded :
cc:
Thanks. We can improve it after v1 release.
Change:
# Kubernetes <del> [![GoDoc](https://godoc.org/github.com/GoogleCloudPlatform/kubernetes?status.png)](https://godoc.org/github.com/GoogleCloudPlatform/kubernetes) [![Travis](https://travis-ci.org/GoogleCloudPlatform/kubernetes.svg?branch=master)](https://travis-ci.org/GoogleCloudPlatform/kubernetes) </del> <ins> [![GoDoc](https://godoc.org/github.com/GoogleCloudPlatform/kubernetes?status.png)](https://godoc.org/github.com/GoogleCloudPlatform/kubernetes) [![Travis](https://travis-ci.org/GoogleCloudPlatform/kubernetes.svg?branch=master)](https://travis-ci.org/GoogleCloudPlatform/kubernetes) [![Coverage Status](https://coveralls.io/repos/GoogleCloudPlatform/kubernetes/badge.svg)](https://coveralls.io/r/GoogleCloudPlatform/kubernetes) </ins> Kubernetes is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications.

Discussion:
Right now, we execute unit tests in Travis with , and you can see the results on each line: but we don't have an easy place to go browse our code and figure out what's covered and what isn't. Is there some awesome way to do this? At the very least, can we get the actual line-by-line coverage results integrated into our CI build process so we can poke at these somehow?
cc
I'm willing to take a look into this to at least see if something is possible.
Looking into using Coveralls; there are a few other teams at Google already using this. Integration with Travis and Go are supported with the goveralls package:
Unit test coverage can now be viewed at - both master push builds and PRs will be shown there; additionally, Coveralls will update the status and post comments on PRs with coverage stats. (If we find these too spammy, we can disable either or both.) The top-level also has a badge/link to the coverage dashbaord.
Change:
"format": "byte" }, "service": { <del> "description": "`service` is a reference to the service for this webhook. Either `service` or `url` must be specified.nnIf the webhook is running within the cluster, then you should use `service`.nnIf there is only one port open for the service, that port will be used. If there are multiple ports open, port 443 will be used if it is open, otherwise it is an error.", </del> <ins> "description": "`service` is a reference to the service for this webhook. Either `service` or `url` must be specified.nnIf the webhook is running within the cluster, then you should use `service`.nnPort 443 will be used if it is open, otherwise it is an error.", </ins> "$ref": "#/definitions/io.k8s.api.admissionregistration.v1beta1.ServiceReference" }, "url": {

Discussion:
What happened: Deployed a webhook backend and service as follows: Please note that there is only 8443 port on the service. Register the webhook as follows: Got the following error when creating pods: What you expected to happen: Based on , should be called. Not the 443 port shown in the error message. How to reproduce it (as minimally and precisely as possible): Just deploy the same setup and register webhook. Anything else we need to know?: Environment: Kubernetes version (use ): HEAD Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.0-alpha.1.97+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-01-22T20:00:24Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.470+", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-03-12T19:36:42Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): COS Kernel (e.g. ): COS
thanks for the detailed bug report!
I actually think that the API specification (or documentation) must change. Not all API servers will have access to look up the Service object and see what ports it defines. If we want to support ports other than 443, the port information must be specified in the webhook object, not discovered by direct Service object lookup
/assign
Looks like it will always use 443 no matter what ports are available, right? Should our documentation reflect this or should it behave differently? (also just sets 443 in the custom dial wrapper thing )
As a first step, I would adjust the documentation. As noted in , if we want to support ports other than 443, that information needs to be to the webhook config object
Change:
- watch: - pkg: docker-io - pkg: openvswitch {% endif %}

Discussion:
Which jobs are failing: capa-conformance-v1alpha3-k8s-master (ci-cluster-api-provider-aws-make-conformance-v1alpha3-k8s-ci-artifacts) Which test(s) are failing: [] Pods should get a host IP [NodeConformance] [Conformance] Since when has it been failing: 06-06 17:23 PDT Testgrid link: Reason for failure: <*errors.errorString | 0xc0000daf10: { s: "pod ran to completion", } pod ran to completion occurred skipped 89 lines unfold_more Jun 6 10:07:34.676: INFO: Latency metrics for node ip-10-0-0- Jun 6 10:07:34.676: INFO: Waiting up to 3m0s for all (but 0) nodes to be ready STEP: Destroying namespace "pods-7990" for this suite. Anything else we need to know: /sig testing /cc /priority critical-urgent /milestone v1.19
/sig scheduling observing a timeout Jun 10 05:42:34.202: INFO: found a healthy node: test1-md-0-4qcf5 [It] runs ReplicaSets to verify preemption running path [Conformance] Jun 10 05:42:42.675: INFO: pods created so far: [1 1 1] Jun 10 05:42:42.675: INFO: length of pods created so far: 3 Jun 10 05:44:42.765: FAIL: pod sched-preemption-path-3834/pod4 failed to preempt other pods Unexpected error: &lt;*errors.errorString | 0xc00011bdd0: { s: "timed out waiting for the condition", } timed out waiting for the condition occurred Full Stack Trace (0xc000e48f20, 0xc001dbb800, 0x1bf08eb000) +0x16b skipped 318 lines unfold_more Jun 10 05:44:44.847: INFO: Waiting up to 3m0s for all (but 0) nodes to be ready STEP: Destroying namespace "sched-preemption-4796" for this suite.

[AfterEach] [sig-scheduling] SchedulerPreemption [Serial]
/remove-sig scheduling I observing failure since yesterday as the cluster failed to get created using the CloudFormation template Attempting to create CloudFormation stack cluster-api-provider-aws-sigs-k8s-io Error: failed to create AWS CloudFormation stack: ResourceNotReady: failed waiting for successful resource stateError: failed to create AWS CloudFormation stack: ResourceNotReady: failed waiting for successful resource state
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig remove scheduling Error: failed to create AWS CloudFormation stack: ResourceNotReady: failed waiting for successful resource stateError: failed to create AWS CloudFormation stack: ResourceNotReady: failed waiting for successful resource state` 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
/remove-sig scheduling
/assign
/remove-sig testing SIG testing doesn't own CAPA bringup failures
/sig cluster-lifecycle
It is expected that will provide a fix /cc
/assign
/lifecycle active
Change:
RUN clean-install bash ADD kube-addons.sh /opt/ <del> ADD namespace.yaml /opt/ </del> ADD kubectl /usr/local/bin/ CMD ["/opt/kube-addons.sh"]

Discussion:
What happened: Add-on manager uses kubectl apply to create the kube-system namespace at start-up. This is redundant because the kube-apiserver creates the namespace in NewBootstrapController. This is a problem because if someone uses apply to make changes to the kube-system namespace, the add-on manager will wipe out these changes. What you expected to happen: Kube-APIServer has the sole responsibility of creating the kube-system namespace. How to reproduce it (as minimally and precisely as possible): kubectl apply a label to the kube-system namespace. restart the add-on manager. Note the labels have been removed. Anything else we need to know?: /sig api-machinery Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
the contention script wipes out namespace ^^
/cc
i guess it is intentional to have the addon manager to ensure kube-system is not modified, it tries to avoid the case that some cluster admin accidentally delete kube-system that result in a non-functional cluster.
The add-on manager will only perform the check when it restarts. The API Server will also perform this check when it restarts. I think we should only have 1 system responsible for this and I believe that system should be the API server.
trying to have my first contribute here, so is it proper to have the kube-system existence checked before applying the yaml file to create the kube-system namespace once again?
The Kube API Server will check for the existence of the kube-system namespace and create it if absent. It does all of this using client-go requests. The Add-On manager is the only system creating the kube-system by applying (a private) yaml file. I believe the correct fix here is to remove the Add-On managers attempts to create the kube-system namespace entirely. This is especially important if a user writes a CI/CD controller to apply their desired state to the kube-system namespace. I would argue the CI/CD is correct but the add-on manager will randomly wipe out the users changes. The API Server on the other hand will not.
, thanks for your help, so i will remove that line and pull a request later
Trying to get my first PR here. Is the issue still open ?
The issue is still open. You may want to check on though as was trying to fix the issue with that PR.
Change:
// Construct the resulting typed, unversioned object. objToUpdate := p.restPatcher.New() if err := runtime.DecodeInto(p.codec, patchedObjJS, objToUpdate); err != nil { <del> return nil, err </del> <ins> return nil, errors.NewInvalid(schema.GroupKind{}, "", field.ErrorList{ field.Invalid(field.NewPath("patch"), string(patchedObjJS), err.Error()), }) </ins> } if p.fieldManager != nil {

Discussion:
/kind bug /sig api-machinery /cc What happened: patching (SMP) any object's annotation using invalid patch content will result in an (500) internal-server error. expecting a (400) bad-request error in this case. patch body: received error: the error is thrown from converter instead of the patcher, so it seems that patcher considers the body as valid then the converter complained. Anything else we need to know?: when my grandpa was 65 years old he started running one mile a day to keep fit. he's 70 now and we have no idea where he is.
I just tried the same patch with "MergePatchType", and it also fails with 500.
I can't make it fail with JSONPatchType, I get a 422
I suspect the error should read "the server rejected your request due to an error in our request"
Change:
} ``` <del> Once you have that pod file, you can create the redis pod in your Kubernetes cluster using the `cloudcfg` cli: </del> <ins> Once you have that pod file, you can create the redis pod in your Kubernetes cluster using the `cloudcfg` CLI: </ins> ```shell <del> cluster/cloudcfg.sh -c redis-master.json create /pods </del> <ins> $ cluster/cloudcfg.sh -c examples/guestbook/redis-master.json create /pods </ins> ``` Once that's up you can list the pods in the cluster, to verify that the master is running:

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: I am running an admission webhook using If there it has been hours since the last mutating request to the webhook, then the next mutating request will take many seconds to be processed. This may even take long enough to have the request time out. What you expected to happen: A request takes approximately the same amount of time to be processed regardless of how long it has been since the last request. How to reproduce it (as minimally and precisely as possible): Create an API server for handling a new API group. Wait a couple hours. Send a CREATE request to the API server. Observe that the CREATE request takes a few seconds to complete. Anything else we need to know?: This is the offending code. It must loop through once for every second since the last request. Environment: Kubernetes version (use ): 1.19.0
/sig api-machinery
I thought we'd already merged a fix for this from before the release?
I assume that the fix was supposed to be From my understanding, those changes only are in effect if the apiserver is running with priority and fairness enabled. In my situation, I do not have that enabled.
Ack, if we have the problem in both places we need the fix in both places :)
/triage accepted
I think we have fixed this in , do you guys agree?
Change:
--project "${PROJECT}"  --region "${REGION}"  --quiet  <del> "${MASTER_NAME}-ip" || true </del> <ins> "${MASTER_NAME}-ip" </ins> export CONTEXT="${PROJECT}_${INSTANCE_PREFIX}" clear-kubeconfig <ins> set -e </ins> } # Update a kubernetes cluster with latest source

Discussion:
'kubernetes-soak-weekly-deploy' sometimes fails to deploy because the clean-up cluster step fails to delete the template: Then the subsequent cluster step fails to create the template, because it already exists: It keeps retrying and failing, because the template already exists, until it times out and the deployment fails. Suggested fixes: Cluster down should try harder to delete the template (maybe wait/retry). Cluster up should recognize that the template exists, and try to delete/recreate, or just re-use the existing.
Looks like ran in to this on Monday, May 11, 2015 around 1:00 PM PST. I'll assign this to my self and take a crack at fixing it.
This is causing most of our e2e tests to fail in continuous integration as well as users private e2e test clusters. Bumping to priority/p0 and v1.0 milestone. Saad thinks he's figured it out, and is working on a fix as we speak.
In essence... Saad: "I think what's happening is the previous clean up step to delete the managed instance group happens asynchronously, therefore there is a race condition to delete the template. Working on a fix".
Change:
// IsConflict determines if the err is an error which indicates the provided update conflicts. // It supports wrapped errors. func IsConflict(err error) bool { <del> return ReasonForError(err) == metav1.StatusReasonConflict </del> <ins> reason, code := reasonAndCodeForError(err) if reason == metav1.StatusReasonConflict { return true } if _, ok := knownReasons[reason]; !ok && code == http.StatusConflict { return true } return false </ins> } // IsInvalid determines if the err is an error which indicates the provided resource is not valid. // It supports wrapped errors. func IsInvalid(err error) bool { <del> return ReasonForError(err) == metav1.StatusReasonInvalid </del> <ins> reason, code := reasonAndCodeForError(err) if reason == metav1.StatusReasonInvalid { return true } if _, ok := knownReasons[reason]; !ok && code == http.StatusUnprocessableEntity { return true } return false </ins> } // IsGone is true if the error indicates the requested resource is no longer available. // It supports wrapped errors. func IsGone(err error) bool { <del> return ReasonForError(err) == metav1.StatusReasonGone </del> <ins> reason, code := reasonAndCodeForError(err) if reason == metav1.StatusReasonGone { return true } if _, ok := knownReasons[reason]; !ok && code == http.StatusGone { return true } return false </ins> } // IsResourceExpired is true if the error indicates the resource has expired and the current action is

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:
<ins> apiVersion: v1beta3 kind: Service metadata: name: openshift spec: ports: - port: 8443 name: openshift targetPort: 8443 selector: name: openshift createExternalLoadBalancer: true </ins>

Discussion:
This PR was prematurely merged: Need to update the PR based on the actual steps that were needed to get what was demonstrated at the public Kubernetes meet-up last week.
Any chance you can get rid of the hostPort from the example?
- depending on the Kubernetes provider, yes. For Vagrant based provider, I think I still need the hostPort because I do not have routes. For the GCE provider, I should be able to get rid of it because I have routes. In both providers, there were a number of setup steps that did not make the merged PR. For those that are tracking this issue (which I know folks have pinged me on separately) needs to be configured to allow privelaged containers needs to be configured to allow pushing to an insecure registry (this is point in time) Ideally, I could use a ReplicationController in the example to load balance OpenShift, but until we can provide a pattern to run etcd as a pod, I am unable to do this and need to use the embedded etcd we end up running.
Note: I will resolve this issue in 2 phases. Vagrant (which was demonstrated) to document using GCE (which has some additional steps on firewall rules)
Turns out OpenShift Origin is too secure now ;-) This is blocked until OpenShift Origin allows you to mint certs on the client, and then supply the certs on startup as a secret to the pod. This feature is coming soon. /cc
I now have all the required pieces to get this to work. I hope to get a PR submitted to fix this issue by end of this week.
Change:
errNotFound = errors.NewNotFound(gvr.GroupResource(), "pod") assert.EqualError(t, err, errNotFound.Error()) } <ins> func Test_resourceCovers(t *testing.T) { type args struct { resource string action   Action } tests := []struct { name string args args want bool }{ { args: args{ resource: "*", action:   ActionImpl{}, }, want: true, }, { args: args{ resource: "serviceaccounts", action:   ActionImpl{}, }, want: false, }, { args: args{ resource: "serviceaccounts", action: ActionImpl{ Resource: schema.GroupVersionResource{ Resource: "serviceaccounts", }, }, }, want: true, }, { args: args{ resource: "serviceaccounts/token", action: ActionImpl{ Resource: schema.GroupVersionResource{}, }, }, want: false, }, { args: args{ resource: "serviceaccounts/token", action: ActionImpl{ Resource: schema.GroupVersionResource{ Resource: "serviceaccounts", }, }, }, want: false, }, { args: args{ resource: "serviceaccounts/token", action: ActionImpl{ Resource:    schema.GroupVersionResource{}, Subresource: "token", }, }, want: false, }, { args: args{ resource: "serviceaccounts/token", action: ActionImpl{ Resource: schema.GroupVersionResource{ Resource: "serviceaccounts", }, Subresource: "token", }, }, want: true, }, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { if got := resourceCovers(tt.args.resource, tt.args.action); got != tt.want { t.Errorf("resourceCovers() = %v, want %v", got, tt.want) } }) } } </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 -- Can't match "serviceaccounts/token", can only match "serviceaccounts" Can match "serviceaccounts/token"
/kind feature
/sig testing
/assign
/triage accepted
Change:
} type effectiveVersion struct { <ins> // When true, BinaryVersion() returns the current binary version useDefaultBuildBinaryVersion atomic.Bool // Holds the last binary version stored in Set() </ins> binaryVersion atomic.Pointer[version.Version] // If the emulationVersion is set by the users, it could only contain major and minor versions. // In tests, emulationVersion could be the same as the binary version, or set directly,

Discussion:
Starting in 1.31, --version no longer works to modify the build ID of the running components. /kind regression /priority important-soon Running kube-apiserver v1.31.0 with ignores the modified build ID and reports In 1.28, 1.29, and 1.30 (since ), this allowed modifying the build ID of the running server. /sig api-machinery /assign Run v1.31.0 with No response 31.0 n/a <details</details<details</details<details</details<details</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
I think this broke in DefaultBuildEffectiveVersion() is grabbed in NewAPIServerCommand(), before the flag is parsed, so the GitVersion propagated into the snapshot effectiveVersion doesn't honor
cc
Change:
fi IFS="$OLD_IFS" <del> IFS="," __debug "RET=${RET[@]} len=${#RET[@]}" </del> <ins> IFS="," __kubectl_debug "RET=${RET[@]} len=${#RET[@]}" </ins> for w in ${RET[@]}; do if [[ ! "${w}" = "${cur}"* ]]; then

Discussion:
/kind bug I wasn't able to find issue opened for ZSH case, and aware about similar, fixed, case with bash in 1.10.0-b1 bash completion is working fine
/sig cli
can you verify this and label for v1.10 milestone and note if it will be considered a release blocker
I cannot reproduce this on my local machine (zsh 5.3.1 x86_64-apple-darwin16.3.0). Please produce a docker container (with Dockerfile) that shows this issue.
And another important question for the release: can you try with the 1.9 kubectl? Is that working in your setup?
little bit more info: i'm running this on CentOS 7.4 1708 x64 and zsh from official repo same issue happenes with 1.10.0-b3: 3
From sig-cli Slack: Kazuki Suda [01:22] It seems that have to be renamed to due to changes contained (edited)
You can reproduce this with the below:
was renamed to at , but has been used yet in completions generated by . So we have to replace to .
issue still exists with v10.0.0-b4
10.0-beta.4 does not contain the fix, yet.
Because the fix is not cherry-picked to release-1.10 yet.