jiebi/CodeConvo huggingface dataset:
Change:
// SetNewReplicaSetAnnotations sets new replica set's annotations appropriately by updating its revision and // copying required deployment annotations to it; it returns true if replica set's annotation is changed. <del> func SetNewReplicaSetAnnotations(deployment *apps.Deployment, newRS *apps.ReplicaSet, newRevision string, exists bool) bool { </del> <ins> func SetNewReplicaSetAnnotations(deployment *apps.Deployment, newRS *apps.ReplicaSet, newRevision string, exists bool, revHistoryLimitInChars int) bool { </ins> // First, copy deployment's annotations (except for apply and revision annotations) annotationChanged := copyDeploymentAnnotationsToReplicaSet(deployment, newRS) // Then, update replica set's revision annotation

Discussion:
What happened: We created a Deployment and continuously updated an annotation on it periodically for a week. Eventually, we noticed errors in the controller-manager logs due to the annotation growing too large. Example annotations: controller-manager error: What you expected to happen: that do not change the revision number should not be to the revision history. revision history should be capped at a fixed number of elements, it should not be possible to have unbounded growth for Deployments that are frequently updated. How to reproduce it (as minimally and precisely as possible): a Deployment modify an annotation on it and note that the annotation gets the same number appended every time. Environment: Kubernetes version (use ):
/sig scalability Not 100% sure where this one fits, I couldn't determine which group owns the Deployment/ReplicaSet controllers, but this is a scalability problem
/sig apps
Agree with these, and if the limit is hit, the beginning of the history can be removed.
/assign
Change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/uuid:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/apiserver/pkg/apis/audit:go_default_library",

Discussion:
https://k8s- /sig auth /kind failing-test
Adding a priority to this: /priority important-soon Please raise the priority if you consider this a release blocker. Given the test job, it normally wouldn't be.
It's a test issue. I'm hoping to fix this before 1.13 but I don't consider it a release blocker.
Change:
- *Flocker Dataset Agent(s)*: a convergence agent that modifies the cluster state to match the desired configuration; - *Flocker Container Agent(s)*: a convergence agent that modifies the cluster state to match the desired configuration (unused in this configuration but still required in the cluster). <del> Read more about the [Flocker Cluster Architecture](https://docs.clusterhq.com/en/latest/concepts/architecture.html) at the [Flocker Documentation](https://docs.clusterhq.com/). </del> <ins> The Flocker cluster can be installed on the same nodes you are using for Kubernetes. For instance, you can install the Flocker Control Service on the same node as Kubernetes Master and Flocker Dataset/Container Agents on every Kubernetes Slave node. </ins> It is recommended to follow [Installing Flocker](https://docs.clusterhq.com/en/latest/install/index.html) and the instructions below to set-up the Flocker cluster to be used with Kubernetes.

Discussion:
We found that some users coming to the document were getting a little confused. It should include more detail about where to install Flocker services, how to set environment variables, that you can create volumes now with Docker CLI and give more detail in example including how to use it with a spec that includes a replication controller.
Change:
"io/ioutil" "net/http" "os" <del> goruntime "runtime" </del> "strings" "time"

Discussion:
A new flag indicating how kube-proxy gets the number of CPUs, either from goruntime or . In kube-proxy, we can use to set node's , the resulting is . We have nodes where pods with none CPU policy and static CPU policy are running together. Pods like kube-proxy are running in none CPU policy by default, and they only gets CPUs left by static CPU policy pods. If static CPU policy pods take away most CPUs cores, kube-proxy can only get one or two cores, then will be set to a very small values. In this case, a lot packet failure can occur. When we set kube-proxy to work in static CPU policy, kube-proxy only gets the number of CPUs selected by the CPU policy, not the number of total CPUs on the node. This may surprise users who are only trying to limit kube-proxy's CPU usages, but resulting in some conntrack fulls faults. Please let me know if this enhancement is reasonable, so I can send a pr later. Thanks!
/sig network
Is it refer to deploy order of kube-proxy? If kube-proxy deploy first in node, will it get just one or two core?
By one or two I mean kube-proxy gets a small number of CPU cores, because most of CPU cores are allocated to static policy pods, sorry for the misunderstanding. The number of conntrack-max depends on the CPU cores when kube-proxy started, even kube-proxy was first deployed, it can get restarted or redeployed by some reasons. Then the conntrack-max will change.
yeah, when kube-proxy deploy firstly, Maybe it can see the whole cpu nums from shared cpu(/var/lib/kubelet/cpumanagestate when kubelet start with static cpu policy). But I think it is a bug for kube-proxy. The cpu info can also get from node resource info. So will it be suitable to add a flag to set cpu num?
Maybe, or we can add a flag for user to choose where kube-proxy should get CPU informations from. There maybe some multi-tenant scenarios where kube-proxy are deployed for per tenant so they would like to limit conntrack-max by CPU cores allocated to each tenant.
I think the simple fix is to replace with something that counts /proc/cpuinfo. I don't know of anyone running multiple proxies, and I don't think it would work well. The intention was "all the CPUs on the node". PRs welcome!
/triage accepted
Change:
package common import ( <ins> "encoding/json" </ins> "fmt" "k8s.io/api/core/v1"

Discussion:
This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to these query results from APIsnoop, we are lacking in tests for the follow endpoints related to Secrets. We chose the follow endpoints for this mock test. Test outline: a Secret in the default namespace with custom values Secrets in all namespaces search for Secret created in  the data in Secret  Secret  Secrets in all namespaces ensure that Secret  doesn't exist Discover useragents Display endpoints hit by the test Review the change in coverage If a test with these calls gets merged in, conformance will go up by 3 endpoints. /sig architecture /area conformance
/reopen
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
Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /close
Closing this issue. <detailsIn response to : Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /close 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:
// kubectl command (begining with a space). func kubectlArgs() string { if *checkVersionSkew { <del> return " --match-server-version --v=4" </del> <ins> return " --match-server-version" </ins> } <del> return " --v=4" </del> <ins> return "" </ins> } func bashWrap(cmd string) string {

Discussion:
In case it isn't clear why this happened, it's because gcloud ships with an older version of kubectl (currently version 0.7.0). We keep it as up to date as we can, but it will always lag a release or so behind head.
Fixed by the revert.
Change:
transformContext := authenticatedDataString(key) for { if err := preconditions.Check(key, origState.obj); err != nil { <del> return err </del> <ins> // If our data is already up to date, return the error if !mustCheckData { return err } // It's possible we were working with stale data // Actually fetch origState, err = getCurrentState() if err != nil { return err } mustCheckData = false // Retry continue </ins> } ret, ttl, err := s.updateState(origState, tryUpdate)

Discussion:
Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: https://k8s- Not showing up in triage, oddly, but seen in individual failures: not sure if this specific to custom resources, but that's where I'm seeing the flakes /sig api-machinery /priority important-soon /area custom-resources
adding to the milestone until root-caused
/cc
I suspect there is some cache/race that keeps the old CR information around during the update from the CR that fails UID check during an update etcd log: few read (other other version defined by CRD. the port difference indicates a different client) the timestamp, the failure happened after the write a successful CR from another test in that file (TestValidateOnlyStatus, TestGeneration, etc) (different etcd key prefix from the same etcd log) few read (update) few read (the second version. I'm surprised that the port didn't change) few read
leaving in the milestone for visibility as we root cause whether this is a test-only issue or not
I spent a while trying to recreate this and could not (again). I made one of the tests hotloop with QPS 100 doing get/update of the status subresource, then ran that in parallel with the other integration tests in the package. No failures found after running for ~10 minutes. Updated description with testgrid link to locate recent flakes (https://k8s-), found a couple in the last week.
iiuc, the error comes from apiserver the UID against the . The requested obj is up-to-date since it was from etcd, but I didn't see mechanism that guarantees the watch cache to be up-to-date after a "delete-create" or "delete-create-get" sequence (the cacher implementation for Delete, Create and Get(rv="") go through etcd directly). Is this failure an expected behavior, and should we just retry on precondition failure?
the triage page seems to be stale, filed
talked with offline, we get it reproduced by adding some delay to the watch cache: as suggested preconditions should retry on stale watch data instead of surfacing such error, this is not a test issue. I will send a fix
Change:
} cmd.Flags().BoolVar(&makeSymlinksFlag, "make-symlinks", makeSymlinksFlag, "create a symlink for each server in current directory") cmd.Flags().MarkHidden("make-symlinks") // hide this flag from appearing in servers' usage output <ins> cmd.Flags().MarkDeprecated("make-symlinks", "This feature will be removed in a later release.") </ins> for i := range commandFns { cmd.AddCommand(commandFns[i]())

Discussion:
Hyperkube supports a number of short aliases for commands, such as , , , , etc, rather than the longer , , , etc. There are comments indicating this is "unfortunate" and we still currently create these aliases in the hyperkube docker image: It'd be nice to simplify this, assuming we can find all uses of the short aliases and remove them. /kind cleanup Not sure which sig should own this, so tagging a few. /sig architecture cluster-lifecycle cli cc
interestingly, the command doesn't create the short aliases, though we also don't really use anywhere either.
I think we can just go ahead and start the deprecation cycle for this. WDYT? cc
cc as well
+1 to nuke it
/assign :wink: ok?
SGTM
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
I would like to work on it!
It seems like this issue was already solved in ?
I don't think the hyperkube code was changed in that PR, only the image?
Yes, thanks for your comment, can i try to fix it ?
I made a PR here: . Review/feedback/suggestions appreciated! :)
/assign /unassign
GitHub didn't allow me to assign the following users: Rand01ph.

Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /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
/remove-sig architecture cli /sig release Does anyone even still use hyperkube? Wouldn't they use kubeadm or k3s instead?
AFAIK, SAP (the company) still use hyperkube.
aks-engine deployer ( ) still uses hyperkube
Since this ticket is completed now. Can this todo be removed?
we are removing the whole thing :)
Change:
srcs = [ "controller_test.go", "import_known_versions_test.go", <ins> "master_openapi_test.go", </ins> "master_test.go", ], library = ":go_default_library",

Discussion:
Haven't seen this one before and I am not sure it has any relation with the that hit it. https://k8s-
From what I can gather, it is being killed due to taking over 5 minutes which is roughly how long it takes (~300s) on successful unit builds.
bumping priority. I'm seeing this pretty frequently this morning. I see OpenAPI and associate you. You know something about this one?
Yes, I wrote this test. It was failing (timing out) for quite some time on jenkins but passing quite fast locally. I've disabled it but after a while it started passing and I assumed it was a configuration change on test machines. I will spend some time on it again to see if I can find the root cause and will disable it otherwise. This test is passing locally in about 15 second. Do you have any idea why it is timing out (or passing near to 300s) on jenkins machines? where do you see the successful test stats?
I see what you do. Locally it takes 25s, with bots it is 300s. My guess is that we are constrained by CPU and all the encode/decode is causing strain either on CPU or GC. The bots fail about 75% for me so I just keep retrying until success. Just had 2 this morning pass at 296s.
Curiously, it's taking about 20 seconds with Bazel. this might be worth looking at.
I think we run tests in Jenkins with , which might explain the slowness?
Nevermind, we hit it in a bazel run: https://k8s-
-race does kill the performance, 25s -166s which is on par with bazel.
is it possible to disable -race for this test? and should we do that if it is possible?
Now blocking the submit queue.
I think I am missing something here. I've checked some of the attached PRs. Links to the pkg/master folder in master branch has the change (new file called but non of the recent PRs I checked has the file in their branch: That means they didn't sync with master? What am I missing here?
OK. I see, the tests are patching the change of the PR into the master, so everybody should get that if they retest, but it look like my test is not blocking submit queue. there should be another issue.
Change:
// no-op, we've been upgraded case resp.StatusCode < http.StatusOK || resp.StatusCode > http.StatusPartialContent: if !isStatusResponse { <del> return nil, false, r.transformUnstructuredResponseError(resp, req, body) </del> <ins> return Result{err: r.transformUnstructuredResponseError(resp, req, body)} </ins> } <del> return nil, false, errors.FromObject(&status) </del> <ins> return Result{err: errors.FromObject(&status)} </ins> } // If the server gave us a status back, look at what it was. success := resp.StatusCode >= http.StatusOK && resp.StatusCode <= http.StatusPartialContent if isStatusResponse && (status.Status != api.StatusSuccess && !success) { <del> // "Working" requests need to be handled specially. </del> // "Failed" requests are clearly just an error and it makes sense to return them as such. <del> return nil, false, errors.FromObject(&status) </del> <ins> return Result{err: errors.FromObject(&status)} </ins> } <del> created := resp.StatusCode == http.StatusCreated return body, created, nil </del> <ins> return Result{ body:    body, created: resp.StatusCode == http.StatusCreated, codec:   r.codec, } </ins> } // transformUnstructuredResponseError handles an error from the server that is not in a structured form.

Discussion:
Storing r.req / r.resp internally (for use from DoRaw and Do) is probably not the right factoring. There should be a common method doRaw that returns request and body.
Change:
}, nil, NewDefaultClientConfigLoadingRules(), promptedCredentials{}} ) <ins> // getDefaultServer returns a default setting for DefaultClientConfig // DEPRECATED func getDefaultServer() string { if server := os.Getenv("KUBERNETES_MASTER"); len(server) > 0 { return server } return "http://localhost:8080" } </ins> // ClientConfig is used to make it easy to get an api server client type ClientConfig interface { // RawConfig returns the merged result of all overrides

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:
return nil, false, fmt.Errorf("Spec does not reference a NFS volume type") } <ins> func getServerFromSource(source *v1.NFSVolumeSource) string { if netutil.IsIPv6String(source.Server) { return fmt.Sprintf("[%s]", source.Server) } return source.Server } </ins>

Discussion:
In bare-metal IPv6 environment, any pod consuming storage resource is not able to run. The storage should be consumable, and the pod should become in status. Running the in a bare-metal IPv6 configurations. I have replaced the cloud-based storage resource with a mounted to a folder on my localhost. Steps alongside logs are below :- $kubectl get svc $kubectl describe svc nfs-server $kubectl describe pv nfs $kubectl get pod -w $kubectl get pod -w $kubectl describe pod nfs-busybox-6r96h I have built the master branch to make sure it was not fixed up to this moment.
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 storage
/sig storage /tirage accepted /assign
Change:
<del> serve_hostname ============== </del> <ins> ## serve_hostname </ins> <del> Util app to serve your hostname on TCP and/or UDP.  Useful for testing. </del> <ins> This is a small util app to serve your hostname on TCP and/or UDP.  Useful for testing. The `serve_hostname` Makefile supports multiple architectures, which means it may cross-compile and build an docker image easily. Arch-specific busybox images serve as base images. If you are releasing a new version, please bump the `TAG` value in the `Makefile` before building the images. ## How to release: ``` # Build cross-platform binaries $ make all-push # Build for linux/amd64 (default) $ make push ARCH=amd64 # ---> gcr.io/google_containers/serve_hostname-amd64:TAG $ make push ARCH=arm # ---> gcr.io/google_containers/serve_hostname-arm:TAG $ make push ARCH=arm64 # ---> gcr.io/google_containers/serve_hostname-arm64:TAG $ make push ARCH=ppc64le # ---> gcr.io/google_containers/serve_hostname-ppc64le:TAG ``` Of course, if you don't want to push the images, run `make all-container` or `make container ARCH={target_arch}` instead. </ins> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/contrib/for-demos/serve_hostname/README.md?pixel)]()

Discussion:
cross-build , Supported arch are: amd64(default) arm arm64 ppc64le PR is . This issue and PR() is an effort to achieve multiarch Kubernetes()
Done.