jiebi/CodeConvo huggingface dataset:
Change:
// BuildInsecureHandlerChain sets up the server to listen to http. Should be removed. func BuildInsecureHandlerChain(apiHandler http.Handler, c *server.Config) http.Handler { handler := apiHandler <ins> handler = genericfilters.WithMaxInFlightLimit(handler, c.MaxRequestsInFlight, c.MaxMutatingRequestsInFlight, c.LongRunningFunc) </ins> handler = genericapifilters.WithAudit(handler, c.AuditBackend, c.AuditPolicyChecker, c.LongRunningFunc) handler = genericapifilters.WithAuthentication(handler, server.InsecureSuperuser{}, nil, nil) handler = genericfilters.WithCORS(handler, c.CorsAllowedOriginList, nil, nil, nil, "true") handler = genericfilters.WithTimeoutForNonLongRunningRequests(handler, c.LongRunningFunc, c.RequestTimeout) <del> handler = genericfilters.WithMaxInFlightLimit(handler, c.MaxRequestsInFlight, c.MaxMutatingRequestsInFlight, c.LongRunningFunc) </del> handler = genericfilters.WithWaitGroup(handler, c.LongRunningFunc, c.HandlerChainWaitGroup) handler = genericapifilters.WithRequestInfo(handler, server.NewRequestInfoResolver(c)) handler = genericapifilters.WithCacheControl(handler)

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: Working on a generalization of the max-in-flight filter, I noticed it is positioned inconsistently in the secure vs insecure handler chains. At I see it is very late in the secure handler chain, just before authorization. At I see it comes much earlier, preceding audit, authentication, and timeout (unlike the secured chain). NB: by "early" and "late" here I refer to the order in which the filters run, which is the opposite of the order in which they are constructed. What you expected to happen: I expected the two handler chains to put the filters they have in common in the same order. How to reproduce it (as minimally and precisely as possible): 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:
/cc
Change:
"//pkg/client/informers/informers_generated/externalversions:go_default_library", "//pkg/controller:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library", </ins> ], )

Discussion:
Seen in happy to send a fix but didn't know if this might have been address with your current refactors. Output:
This looks new. I'd happily review a fix. Thanks.
Dupe of
Change:
--filter='+ /vendor/'  --filter='+ /staging/***/Godeps/**'  --filter='+ /_output/dockerized/bin/**'  <ins> --filter='- /_output/dockerized/go/**'  </ins> --filter='+ zz_generated.*'  --filter='+ generated.proto'  --filter='+ *.pb.go' 

Discussion:
While debugging I discovered that setting causes @ (recent master branch commit) to fail on cleanup at the end. This doesn't happen if you don't set . It's not immediately apparent why those are related. This make target should not fail on a clean branch with no diff. set GOTOOLCHAIN to some valid go version and then run /sig testing release /triage accepted n/a Linux. ~Debian. But this is happening inside our build container. n/a docker 20.10.21 n/a
I would guess: we wind up downloading go underneath the tempdir we setup for the script and then there's some non-writeable go toolchain download cache there, or something like that.
That is indeed the case. Go toolchains are downloaded into and the folder is write protected. I will send in a fix. /assign
Change:
# https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/config/delete_cluster.go#L38 #: staging/src/k8s.io/kubectl/pkg/cmd/config/delete_cluster.go:42 msgid "Delete the specified cluster from the kubeconfig" <del> msgstr "指定したコンテキストをkubeconfigから削除する" </del> <ins> msgstr "指定したクラスターをkubeconfigから削除する" </ins> # https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/config/delete_context.go#L38 #: staging/src/k8s.io/kubectl/pkg/cmd/config/delete_context.go:42

Discussion:
There is a minor translation issue about in Japanese. Output of and are completely same. means cluster in japanese, so it must be
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
/assign
/sig docs
Change:
rbacv1 "k8s.io/api/rbac/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" </ins> "k8s.io/apimachinery/pkg/runtime/schema" types "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/uuid"

Discussion:
[ ] two weeks soak start date : testgrid-link [ ] two weeks soak end date : [ ] test promotion pr : kubernetes/kubernetes#? It was picked up in APISnoop that an untested endpoint was promoted from Beta to GA. PR ingress: promote CRUD API tests for v1 to conformance covered the Ingress life cycle tests, but readNetworkingV1NamespacedIngressStatus was missed. According to this APIsnoop readNetworkingV1NamespacedIngressStatus endpoint is untested. ginkgo.By("get /status") ingResource := schema.GroupVersionResource{Group: "", Version: ingVersion, Resource: "ingresses"} gottenStatus, err := f.DynamicClient.Resource(ingResource).Namespace(ns).Get(context.TODO(), createdIngress.Name, metav1.GetOptions{}, "status") framework.ExpectNoError(err) statusUID, _, err := unstructured.NestedFieldCopy(gottenStatus.Object, "metadata", "uid") framework.ExpectNoError(err) framework.ExpectEqual(string(createdIngress.UID), statusUID, fmt.Sprintf("createdIngress.UID: %v expected to match statusUID: %v ", createdIngress.UID, statusUID)) ''' List endpoints hit by the test: readNetworkingV1NamespacedIngressStatus endpoint If this test get merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
Duplicate of
/reopen Merged /assign Ready for creation of Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged /assign Ready for creation of Promotion PR 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
Code change was a bug fix in a Merged conformance test. The correction should not require Promotion. /close
Closing this issue. <detailsIn response to : Code change was a bug fix in a Merged conformance test. The correction should not require Promotion. /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:
// Run scheduler. informerFactory.Start(ctx.Done()) <ins> informerFactory.WaitForCacheSync(ctx.Done()) </ins> go sched.Run(ctx) // Send pods to be scheduled.

Discussion:
Which test(s) are flaking: pkg/scheduler unit tests occasionally timeout at 5 minutes Reason for failure: Stats from 10 runs of the package: The average (excluding the run that timed out) is ~40 seconds. The run that timed out took at least 5 minutes before being killed. That smells like a deadlock / failure-to-progress scenario which could be a real bug. Our presubmit CI runs tolerate flakes, retrying 3 times and passing on a single success, which is masking this issue. Observed in which is turning off that toleration and exercising every unit test package 10 times to ensure consistent passes: I can reproduce this by building the unit test package with: and then running repeatedly with : this appears to hang increasing numbers of parallel runs on the deadlock until timeouts are hit: /sig scheduling
the first step is to try individual tests in that package to see if a single test is deadlocking Stressing each test individually with short timeouts (set at at least 5x the normal run time of the test) and seeing if they pass with no timeout failures after 2x the specified timeout: [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] takes ~.1 seconds on average, immediately starts failing with stress test timeout of 10s, fix in [x] [x] [x] [x] takes 15 seconds on average [x] [x] [x]
can consistently reproduce a hang with: I this debugging: and the hang appears to be while waiting for the create calls and resulting events to be produced:
the full goroutine dump at the time of the hang: <details</details
this is also reproducible against the release-1.18 branch
could you help take a look at the problem in ?
/priority important-soon
/assign
PR up for review Thanks a lot for the repro steps TIL
fantastic, that resolves the MultipleProfiles flake:
TestSchedulerWithVolumeBinding looks flaky as well (see )
I see. I went by the title thinking that the other one was already resolved. Let me have a look.

np, good to knock them out one at a time... the symptoms were consistent so I left it as one issue thinking there might be a shared root cause, but that doesn't appear to be the case
my mistake, I got the wrong average runtime for the volume binding test... it actually takes ~16 seconds because we artificially wait for channel timeout for ~2 seconds for each of the subtests. when I stressed it with a timeout of 1m, I got no flakes separately, we could look into improving the runtime of that test by selecting between error/bind/timeout with something like the following, but that is a different cleanup/improvement issue, not a flake fix
Change:
# Find all of the built client binaries local platform platforms platforms=($(cd "${LOCAL_OUTPUT_BINPATH}" ; echo */*)) <del> for platform in "${platforms[@]}"; do </del> <ins> for platform in "${platforms[@]}" ; do </ins> local platform_tag=${platform///-} # Replace a "/" for a "-" <del> kube::log::status "Starting tarball: client $platform_tag" </del> <ins> kube::log::status "Building tarball: client $platform_tag" </ins> <del> ( local release_stage="${RELEASE_STAGE}/client/${platform_tag}/kubernetes" rm -rf "${release_stage}" mkdir -p "${release_stage}/client/bin" </del> <ins> local release_stage="${RELEASE_STAGE}/client/${platform_tag}/kubernetes" rm -rf "${release_stage}" mkdir -p "${release_stage}/client/bin" </ins> <del> local client_bins=("${KUBE_CLIENT_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then client_bins=("${KUBE_CLIENT_BINARIES_WIN[@]}") fi </del> <ins> local client_bins=("${KUBE_CLIENT_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then client_bins=("${KUBE_CLIENT_BINARIES_WIN[@]}") fi </ins> <del> # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # KUBE_CLIENT_BINARIES array. cp "${client_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/client/bin/" </del> <ins> # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # KUBE_CLIENT_BINARIES array. cp "${client_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/client/bin/" </ins> <del> kube::release::clean_cruft </del> <ins> kube::release::clean_cruft </ins> <del> local package_name="${RELEASE_DIR}/kubernetes-client-${platform_tag}.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." ) & </del> <ins> local package_name="${RELEASE_DIR}/kubernetes-client-${platform_tag}.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." </ins> done <del> kube::log::status "Waiting on tarballs" wait || { kube::log::error "client tarball creation failed"; exit 1; } </del> } # Package up all of the server binaries

Discussion:
After 6 minutes or so of using 50% my 4-core MBP CPU and chewing up a ton of memory, make release gives up with a timeout.
This is on my master branch (no local changes) after rebasing to head this evening. It was working fine earlier today so seems like the likely culprit. /cc
It's certainly my changes. I'm on a low function device, feel free to revert. This is only an issue for low memory systems, I suspect. :/ On Apr 1, 2015 10:24 PM, "Robert Bailey" wrote:
(This is functioning fine on Jenkins and my desktop, FWIW.) On Apr 1, 2015 10:36 PM, "Zachary Loafman" wrote:
Change:
// // Enable pods to consume pre-allocated huge pages of varying page sizes HugePages utilfeature.Feature = "HugePages" <ins> // owner @brendandburns // alpha: v1.8 // // Enable nodes to exclude themselves from service load balancers ServiceNodeExclusion utilfeature.Feature = "ServiceNodeExclusion" </ins> ) func init() {

Discussion:
For various reasons (network topology, heterogenous nodes, etc) a user may want to control the addition of a node to a cloud load balancer. A specific issue with the Azure Container Instances connector which introduces a virtual node can be found here: The right way to do this is via a node annotation, e.g.
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
/reopen This is still a problem.. any word on when feature gate goes out of alpha?
Setup the enhancement tracking issue for this Still discussing with sig-network on how we want to move forward with this.
Change:
func AddOrUpdateLabelOnNode(c *client.Client, nodeName string, labelKey string, labelValue string) { patch := fmt.Sprintf(`{"metadata":{"labels":{"%s":"%s"}}}`, labelKey, labelValue) <del> err := c.Patch(api.MergePatchType).Resource("nodes").Name(nodeName).Body([]byte(patch)).Do().Error() </del> <ins> var err error for attempt := 0; attempt < UpdateRetries; attempt++ { err = c.Patch(api.MergePatchType).Resource("nodes").Name(nodeName).Body([]byte(patch)).Do().Error() if err != nil { if !apierrs.IsConflict(err) { ExpectNoError(err) } else { Logf("Conflict when trying to add a label %v:%v to %v", labelKey, labelValue, nodeName) } } else { break } time.Sleep(100 * time.Millisecond) } </ins> ExpectNoError(err) }

Discussion:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that NodeSelector is respected if matching [Conformance] {Kubernetes e2e suite}
Change:
rm -rf "${ROLLBACK_BACKUP_DIR}" mkdir -p "${ROLLBACK_BACKUP_DIR}" cp -r "${DATA_DIRECTORY}" "${ROLLBACK_BACKUP_DIR}" <del> rm -rf "${DATA_DIRECTORY}"/member/snap/*.snap </del> echo "Performing etcd3 -> etcd2 rollback" ${ROLLBACK} --data-dir "${DATA_DIRECTORY}" if [ "$?" -ne "0" ]; then

Discussion:
I tried to do a rollback on my own test cluster and got a panic. I will attach the data-dir tarball. The script that performs the migration goes from 2.2.1-2.3.7-3.0.14-2.3.7, and it is this last step that barfs. Script is forthcoming in a PR, but there's a snapshot at
This seems that it's not even about the real data, but about some metadata of the cluster. - any thoughts on it?
Is the data you uploaded the original data before 2.2.1-2.3.7?
yes
The rollback tool couldn't accept any v2 data existed. One way to make it work is to remove snap files:
To clarify, the panic is caused by existing v2 snap files. In the migrate step 2.3.7 -3.0.x, the script didn't remove v2 snap files.
- thanks a lot for looking into it. I will add a step to our migration script to remove the v2 data before rollback. Did it work after removing the data?
send out for review
To clarify - I verified that it fixed the problem reported (rollback works on the data provided in the issue).
The fix in the shell script is good, but the error message in the rollback tool could definitely be improved upon.
says that removing the snap file was not the right way to go.
i marked as milestone 1.5 and marking this as a non-release-blocker. hope this is correct.
Hmm... I tried re-running this on my test data, and now 2.3.7 always panics after the last step, whether I begin with backup data or not. Here is the data before running rollback: after running rollback:
I do not understand this. Does the migration tool still panic? Or the etcd 2.3.7 panics? etcd 2.3.7 should panic if you build the migration tool with 3.0 wal pkg. I believe I sent you the correct migration binary over slack.
Can we close this issue if the rollback tool stop panics? If the migrated data panics etcd 2.3, it is expected. And there is some other issues tracking it. I think we went though them a few weeks ago before thinks giving.

your slack message was lost while I was out of office, but the attached file is still there. Trying it now.
it works with the binary you shared. We still need a way to build that binary, but I will open a separate issue about that.
Change:
<ins> #!/bin/bash # Copyright 2016 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. echo "This is NOT a production-ready tool.n IT'S A HACKY, BEST-EFFORT WAY TO "STOP" CREATION OF THE GKE CLUSTER." read -n 1 -p "Are you sure you want to proceed (y/N)?: " decision echo "" if [[ "${decision}" != "y" ]]; then echo "Aborting..." exit 0 fi set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. if [ -f "${KUBE_ROOT}/cluster/env.sh" ]; then source "${KUBE_ROOT}/cluster/env.sh" fi source "${KUBE_ROOT}/cluster/gke/util.sh" STAGING_ENDPOINT="CLOUDSDK_API_ENDPOINT_OVERRIDES_CONTAINER=https://staging-container.sandbox.googleapis.com/" detect-project cluster=$(gcloud container operations list "--project=${PROJECT}" | grep "CREATE_CLUSTER" | grep "RUNNING" || true) if [ -z "${cluster}" ]; then echo "Couldn't find any cluster being created in production environment. Trying staging..." cluster=$(env ${STAGING_ENDPOINT} gcloud container operations list "--project=${PROJECT}" | grep "CREATE_CLUSTER" | grep "RUNNING" || true) fi if [ -z "${cluster}" ]; then echo "No cluster creation in progress found. Aborting." exit 0 fi zone=$(echo "${cluster}" | tr -s "[:blank:]" | cut -f3 -d" ") cluster_name=$(echo "${cluster}" | tr -s "[:blank:]" | cut -f4 -d" ") gcloud="gcloud" if [ "${zone}" == "us-east1-a" ]; then gcloud="env ${STAGING_ENDPOINT} gcloud" fi migs=$(${gcloud} compute instance-groups managed list --project=${PROJECT} --zones=${zone} | grep "gke-${cluster_name}" | cut -f1 -d" ") echo "Managed instance groups for cluster ${cluster_name}: ${migs}" for mig in ${migs}; do echo "Resizing ${mig}..." ${gcloud} compute instance-groups managed resize --project="${PROJECT}" --zone="${zone}" "${mig}" --size=1 done echo "All managed instance groups resized to 1. Cluster creation operation should end soon, and you will be be able to delete the cluster." </ins>

Discussion:
We need a "panic" script for stopping clusters also when they are currently being created. This is needed for the purpose of our performance testing. It should work for at least GCE and GKE.
I think that the first step in GCE and GKE can basically be as simple as: "resize to 0 (or delete)" all MIGs It's far from being perfect but better than nothing.
For GKE that's probably only thing we can do now.
Discussed offline and it seems that for GCE it should be enough to kill the kube-up script and immediately after that start kube-down. Which we already have.
But we still need to for GKE. I'll try to hack something today.
Change:
"k8s.io/kubernetes/pkg/client/typed/discovery" "k8s.io/kubernetes/pkg/client/typed/dynamic" "k8s.io/kubernetes/pkg/runtime" <ins> utilerrors "k8s.io/kubernetes/pkg/util/errors" </ins> "k8s.io/kubernetes/pkg/util/sets" "github.com/golang/glog"

Discussion:
I have been having the kube-controller-manager (running in a container) crash quite frequently with this error: I cant fathom what seems to cause it. It seems to happen consistently for a while (CrashLoopBackoff occurs) and then fixes itself after an undetermined amount of time. Kubectl version: Docker version: Networking: Calico (with the calico k8s policy agent) Please do let me know if there is any other information that I can supply. I appreciate I haven't given much to go off of. I am not sure what the steps to reproduce are...
cc
It looks like a bug. I'll take a look. Thanks for reporting it.
Weirdly, the description showed up in the email github sent me but it appears absent on the github issue?
The description was there when I read it but disappeared now.
Well thats very odd! If you have it on your email, could you post it on here please (and I will update the description)? I unfortunately haven't got the error message to hand now...
I took the liberty of just editing the OP.
thanks a lot! Not sure what happened there!
could you paste the returned output at "server-ip:port/api" and "server-ip:port/apis"?
Sure.
Thanks "" has an empty preferred version and that's causing the error you reported. Is "" created via the thirdparty resource api? ()
aha! Good spot! Yes, it was created via that API. This is the Yaml file I used to create it: Here is the output of
Thanks for the confirmation Your configuration is correct. The preferred version is left empty by the thirdparty resource controller, while our discovery client has an assumption that the preferred version won't be empty. I'll patch the discovery client to tolerate an empty preferred version, and will discuss with on if we should make a default preferred version for a thirdparty resource.
Thanks a lot Great job on working it out :)
Sent to fix.
What would be a workaround for this before the release, how can one specify the preferredVersion?
AFAIK, there is no workaround. There is no way to specify the preferredVersion for the thirdPartyResource.

I have a quick workaround to fix this : 1) Change the kubernetes to reflect the following : from : thirdpartyresources=true to : thirdpartyresources=false 2) Then restart 'kubelet' service OR reboot the K8S Master server systemctl restart kubelet 3) Revert back the changes done to kube- from : thirdpartyresources=false to : thirdpartyresources=true 4) Verify whether the above change on the above manifest file has been automatically picked up by the kubernetes API ps aux | grep -i thirdpartyresources 5) Finally you may restart kubelet service systemctl restart kubelet 6) Now verify whether the 'kube-controller-manager' is in a 'Running' state kubectl get pods --all-namespaces | grep -i controller-manager Hope this fix works for you guys as well !!
Change:
hk.AddServer(testServer("test2")) hk.AddServer(testServer("test3")) hk.AddServer(testServerError("test-error")) <ins> hk.AddServer(testCobraCommand("test-cobra-command")) </ins> a := strings.Split(args, " ") t.Logf("Running full with args: %q", a)

Discussion:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .