jiebi/CodeConvo huggingface dataset:
Change:
return nil, nil, errors.New("No authentication method configured") } <del> authenticator := group.NewGroupAdder(unionauth.New(authenticators...), []string{user.AllAuthenticated}) </del> <ins> authenticator := group.NewAuthenticatedGroupAdder(unionauth.New(authenticators...)) </ins> if c.Anonymous { authenticator = unionauth.NewFailOnError(authenticator, anonymous.NewAuthenticator()) }

Discussion:
When an auth proxy tries to proxy an anonymous request, the user.Info ends up with the group system:authenticated, which is wrong.
Change:
// Create an API Server. controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() controlPlaneConfig.GenericConfig.Authorization.Authorizer = newRBACAuthorizer(t, controlPlaneConfig) <del> controlPlaneConfig.GenericConfig.Authentication.Authenticator = bearertoken.New(tokenfile.New(map[string]*user.DefaultInfo{ </del> <ins> controlPlaneConfig.GenericConfig.Authentication.Authenticator = group.NewAuthenticatedGroupAdder(bearertoken.New(tokenfile.New(map[string]*user.DefaultInfo{ </ins> superUser:                          {Name: "admin", Groups: []string{"system:masters"}}, "any-rolebinding-writer":           {Name: "any-rolebinding-writer"}, "any-rolebinding-writer-namespace": {Name: "any-rolebinding-writer-namespace"},

Discussion:
While moving APF to beta (see comments on ), we discovered that the integration tests commonly present users which are not members of any groups. We had thought that the system enforced membership in either the authenticated or unauthenticated group. If this is supposed to be a system invariant (as we thought), we'd like to ask SIG Auth: Please fix the integration tests Please add e.g. logging so that if real, operational clusters hit this there's at least a log message and people will file bugs. /sig auth
Can I suggest also, if this is a real invariant, that it be documented in some place(s) likely to be read?
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /priority important-longterm /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen
fixes the authenticator configured in one of the integration test API server startup helpers which resolved this issue for . Remaining tests that still need fixing that are encountering unexpected users look to be ones set up to specifically test auth paths:
open to fix remaining integration test users
Change:
handler = genericapifilters.WithTracing(handler, c.TracerProvider) } handler = genericapifilters.WithLatencyTrackers(handler) <ins> // WithRoutine will execute future handlers in a separate goroutine and serving // handler in current goroutine to minimize the stack memory usage. It must be // after WithPanicRecover() to be protected from panics. if utilfeature.DefaultFeatureGate.Enabled(genericfeatures.APIServingWithRoutine) { handler = genericfilters.WithRoutine(handler, c.LongRunningFunc) } </ins> handler = genericapifilters.WithRequestInfo(handler, c.RequestInfoResolver) handler = genericapifilters.WithRequestReceivedTimestamp(handler) handler = genericapifilters.WithMuxAndDiscoveryComplete(handler, c.lifecycleSignals.MuxAndDiscoveryComplete.Signaled())

Discussion:
Optimize the memory usage of goroutine stack for serving watch requests. According to the of handling a watch request, the stack memory is 0x3768, which is very close to 16 KiB and Golang runtime will double it to 32 KiB once exceeded. In fact, it does exceed if we print the traceback deeper and take the fact that extra stack memory reserved by Golang itself into consideration. A naive optimization is to run as much as preparation handlers in a separate goroutine and then move the actual serving to another goroutine, so the former routine can free the stack memory earlier and make it more memory efficient. Given the extensive use of watch requests, 32 KiB per watch could add up to a very high amount of memory overhead for . A typical watch request commonly lasts for 30s or longer, which means this memory will be active for quite long. I see a great improvement in memory efficiency to do this optimization.
/cc
/sig api-machinery
/cc if you would like to take a look when you have time :) Thank you /triage accepted
Change:
for ix := range ports { allowedPorts[ix] = strconv.Itoa(int(ports[ix].Port)) } <del> hostTags, err := gce.computeHostTags(hosts) if err != nil { return nil, err </del> <ins> // If the node tags to be used for this cluster have been predefined in the // provider config, just use them. Otherwise, invoke computeHostTags method to get the tags. hostTags := gce.nodeTags if len(hostTags) == 0 { var err error if hostTags, err = gce.computeHostTags(hosts); err != nil { return nil, fmt.Errorf("No node tags supplied and also failed to parse the given lists of hosts for tags. Abort creating firewall rule.") } </ins> } firewall := &compute.Firewall{ Name:         makeFirewallName(name), Description:  desc,

Discussion:
In some custom setup cases the prefix-matching logic for GCE load-balancers can break and end up creating a firewall rule with no tags. We should instead refuse to create the rule. In fact, if we find it, we should probably delete the rule, but that's maybe too aggressive. Looking at the logic, if we return error in the tag-selection, we'll abort the whole load-balancer creation, which is unfortunate, but not TERRIBLE. We could just silently not create the firewall but not return error, which will just retry over and over.
/cc
Are you active on this? may have some starter-project bandwidth to help.
Not active. It would indeed be a good starter project :)
Change:
kube::util::download_file "${url}" "${download_file}" tar xzf "${download_file}" ln -fns "etcd-v${ETCD_VERSION}-linux-amd64" etcd <ins> rm "${download_file}" </ins> fi kube::log::info "etcd v${ETCD_VERSION} installed. To use:" kube::log::info "export PATH=$(pwd)/etcd:${PATH}"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: During k8s cluster launch, is checked and if any etcd binary is found regardless of current OS Distribution, expected etcd binary is not downloaded and etcd soft link is not updated to point desired etcd binary, so cluster creation fails. What you expected to happen: Along with expected etcd version, OS Distribution should also be checked for successfully and efficiently installing etcd during setting up local cluster. How to reproduce it (as minimally and precisely as possible): Checkout k8s codbase on MacOS and launch cluster. working k8s codebase under virtual machine to launch cluster in VM. (Cluster creation would fail, prompting error that etcd needs to be installed and update in {KUBEROOT}/thirdparty/etcd-v{ETCDVERSION}-linux-* Anything else we need to know?: It's an optimization on managing thirdparty etcd binary for local cluster setup. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
do you have a patch that you are working on? we don't really support local-up-cluster on macos yet. /sig testing
is fixing this issue. Though I use Mac as my workstation but sometimes need local-cluster to test codebase so I mapped (softlinked) my GOPATH in virtual machine keeping separate bin directory. Everything is running perfectly fine after making changes mentioned in this PR. So thought to submit small optimization on etcd installation logic.
/close
Change:
f := framework.NewDefaultFramework("fake-node") f.NamespacePodSecurityLevel = admissionapi.LevelPrivileged <del> ginkgo.It("should run through the lifecycle of a node", func(ctx context.Context) { </del> <ins> /* Release: v1.32 Testname: Node, resource lifecycle Description: Creating and Reading a Node MUST succeed with required name retrieved. Patching a Node MUST succeed with its new label found. Listing Nodes with a labelSelector MUST succeed with only a single node found. Updating a Node MUST succeed with its new label found. Deleting the Node MUST succeed and its deletion MUST be confirmed. */ framework.ConformanceIt("should run through the lifecycle of a node", func(ctx context.Context) { </ins> // the scope of this test only covers the api-server nodeClient := f.ClientSet.CoreV1().Nodes()

Discussion:
[x] two weeks soak end date : 2024-09-08 According to following APIsnoop query, there are two Node endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 2 endpoints. The e2e logs for this test are listed below. This query shows the following Node endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/sig node
/reopen Tracking the next steps to conformance
Reopened this issue. <detailsIn response to : /reopen Tracking the next steps to conformance 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
/reopen Tracking the final step
Reopened this issue. <detailsIn response to : /reopen Tracking the final step 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:
create-node-instance-template $template_name } <del> function create-nodes() { local template_name="${NODE_INSTANCE_PREFIX}-template" </del> <ins> # Assumes: # - MAX_INSTANCES_PER_MIG # - NUM_NODES # exports: # - NUM_MIGS function set_num_migs() { </ins> local defaulted_max_instances_per_mig=${MAX_INSTANCES_PER_MIG:-500} if [[ ${defaulted_max_instances_per_mig} -le "0" ]]; then echo "MAX_INSTANCES_PER_MIG cannot be negative. Assuming default 500" defaulted_max_instances_per_mig=500 fi <del> local num_migs=$(((${NUM_NODES} + ${defaulted_max_instances_per_mig} - 1) / ${defaulted_max_instances_per_mig})) local instances_per_mig=$(((${NUM_NODES} + ${num_migs} - 1) / ${num_migs})) local last_mig_size=$((${NUM_NODES} - (${num_migs} - 1) * ${instances_per_mig})) </del> <ins> export NUM_MIGS=$(((${NUM_NODES} + ${defaulted_max_instances_per_mig} - 1) / ${defaulted_max_instances_per_mig})) } # Assumes: # - NUM_MIGS # - NODE_INSTANCE_PREFIX # - NUM_NODES # - PROJECT # - ZONE function create-nodes() { local template_name="${NODE_INSTANCE_PREFIX}-template" local instances_per_mig=$(((${NUM_NODES} + ${NUM_MIGS} - 1) / ${NUM_MIGS})) local last_mig_size=$((${NUM_NODES} - (${NUM_MIGS} - 1) * ${instances_per_mig})) </ins> #TODO: parallelize this loop to speed up the process <del> for i in $(seq $((${num_migs} - 1))); do </del> <ins> for i in $(seq $((${NUM_MIGS} - 1))); do </ins> gcloud compute instance-groups managed  create "${NODE_INSTANCE_PREFIX}-group-$i"  --project "${PROJECT}" 

Discussion:
cc:
It was broken by . I'll send a fix in a sec.
Sorry & thanks for fixing.
Change:
shift $((OPTIND - 1)) # Use eval to preserve embedded quoted strings. <del> eval "goflags=(${KUBE_GOFLAGS:-})" </del> <ins> eval "goflags=(${GOFLAGS:-})" </ins> eval "testargs=(${KUBE_TEST_ARGS:-})" # Used to filter verbose test output.

Discussion:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign
Change:
package services import ( <del> "flag" </del> "fmt" "io/ioutil" "math/rand" <del> "net/http" </del> "os" "os/exec" <del> "os/signal" </del> "path" "path/filepath" <del> "reflect" "strconv" </del> "strings" <del> "syscall" "time" </del> "github.com/golang/glog" "github.com/kardianos/osext"

Discussion:
In node e2e, we have the option to keep the services running after test for further debug. However, we set to for the services, which means that once the parent exits, they will receive and exit with the parent if they don't trap the signal. With this, option will never work. If we still need this feature, we should not set if is false. /cc
We still need this feature. It helps with debugging test failures by keeping all the daemons running upon failure. , Lantao Liu wrote:
Change:
} crd, err := crd.CreateMultiVersionTestCRD(f, group, func(crd *v1beta1.CustomResourceDefinition) { <del> apiVersions := []v1beta1.CustomResourceDefinitionVersion{} for _, version := range versions { v := v1beta1.CustomResourceDefinitionVersion{ </del> <ins> var apiVersions []v1beta1.CustomResourceDefinitionVersion for i, version := range versions { apiVersions = append(apiVersions, v1beta1.CustomResourceDefinitionVersion{ </ins> Name:    version, Served:  true, <del> Storage: false, } apiVersions = append(apiVersions, v) </del> <ins> Storage: i == 0, }) </ins> } <del> apiVersions[0].Storage = true </del> <ins> crd.Spec.Versions = apiVersions </ins> crd.Spec.Validation = &v1beta1.CustomResourceValidation{ OpenAPIV3Schema: props,

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-features Which test(s) are failing: [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of same group but different versions [sig-api-machinery] CustomResourceConversionWebhook [Feature:CustomResourceWebhookConversion] Should be able to convert a non homogeneous list of CRs [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for CRD without validation schema` [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of same group and version but different kinds [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] updates the published spec when one versin gets renamed [sig-api-machinery] CustomResourceConversionWebhook [Feature:CustomResourceWebhookConversion] Should be able to convert from CR v1 to CR v2 [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of different groups [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] removes definition from spec when one versin gets changed to not be served Since when has it been failing: Failing since 5/16 . There were two PRs related to API machinery and tests that were merged during this period and Testgrid link: Reason for failure: The first failure seems to be this: [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of same group but different versions /cc /priority critical-urgent /kind failing test /milestone v1.15 /cc
/assign sttts
/assign
looks like there were some alpha gated tests that need adjusting after
/unassign
On it.
another PR touching CRD OpenAPI publishing was merged yesterday and we didn't run alpha presubmit test let me know if you think it's specific to CRD openapi publishing and I can look into it
debugging now
is now green /close
Closing this issue. <detailsIn response to : is now green 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:
// Ignores claims that already have a storage class. // TODO: if resync is ever changed to a larger period, we might need to change how we set the default class on existing unbound claims func (ctrl *PersistentVolumeController) assignDefaultStorageClass(claim *v1.PersistentVolumeClaim) (bool, error) { <del> if claim.Spec.StorageClassName != nil { </del> <ins> if storagehelpers.GetPersistentVolumeClaimClass(claim) != "" { </ins> return false, nil }

Discussion:
We observed that when deplying manifests to a cluster running 1.26.1-gke.200, the StorageClass and PVC get created successfully. However, the PVC is stuck in a Pending state and no PV is provisioned. The workaround is to add storageClassName to one of the pending PVCs on cluster, and it did go from Pending to properly provisioned a PV and reaching Bound state. We looked at the logs and found that according to the doc: , Is this annotation is fully deprecated in the new 1.26.1 release? If yes can we add this detail to documentation or release note? the PVC should not stuck in a Pending state and PV is provisioned in 1.26.1 a 1.26.1-gke.200 cluster in GKE via yaml The error comes form the code: and There are some hypotheses here: The annotation does not work on 1.26.1 any more, so a default storage class is being populated to the PVC. For some reason, the did not work, so the PVC was deployed with an empty StorageClass nil. Then the kube controller manager tried to update the PVC with the default StorageClass, which triggered the error: <details</details<detailsGKE </details<details</details<details</details<details</details<details</details
/sig storage
Annotation support seem to be still intact. Check the e2e test
From the point of view of the code, this annotation is still in use. I'll try to see if I can reproduce it.
It's a bug introduced in The feature is enabled in 1.26 by default.
/triage accepted
Change:
exit 1 fi fi <del> if [[ "${KUBE_SKIP_UPDATE}" == "y" ]]; then return fi # update and install components as needed if [[ "${KUBE_PROMPT_FOR_UPDATE}" != "y" ]]; then gcloud_prompt="-q" fi local sudo_prefix="" if [ ! -w $(dirname `which gcloud`) ]; then sudo_prefix="sudo" fi ${sudo_prefix} gcloud ${gcloud_prompt:-} components install alpha || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components install beta || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components install kubectl|| true ${sudo_prefix} gcloud ${gcloud_prompt:-} components update || true </del> <ins> update-or-verify-gcloud </ins> } # Validate a kubernetes cluster

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): all :smile: Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): all Kernel (e.g. ): all Install tools: Others: What happened: uses the cli a lot and does a (in the commonly used function ) before doing things like . updates can introduce breaking changes (for example in the recent 132.0.0 release it removed a bunch of flags). This has caused cross-the-board test failures like . But this is not limited to just tests. Any kubernetes GCE users who rely on the and commands could have been broken. What you expected to happen: Stop updating gcloud automatically. We could either warn user to have the required dependencies installed, or pin to specific versions of dependencies like gcloud. How to reproduce it (as minimally and precisely as possible): download 1.4.4 release tarball run and Anything else do we need to know:
cc
/cc
cc I think it's reasonable to remove gcloud update calls from scripts, as I believe gcloud is updated out of band by k8s continuous testing. The scripts will still need to work with latest, so maybe they should check for a minimum version.
Good idea.
Yeah, we definitely want to continue using latest in CI so that we know if things break, but I think it's reasonable to remove the update itself from the kubernetes cluster util scripts.
Change:
pod, err = c.CoreV1().Pods(ns).Get(pod.Name, metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred()) <del> // Wait for `VolumeStatsAggPeriod' to grab metrics time.Sleep(1 * time.Minute) // Grab kubelet metrics from the node the pod was scheduled on kubeMetrics, err := metricsGrabber.GrabFromKubelet(pod.Spec.NodeName) Expect(err).NotTo(HaveOccurred(), "Error getting kubelet metrics : %v", err) framework.Logf("Deleting pod %q/%q", pod.Namespace, pod.Name) framework.ExpectNoError(framework.DeletePodWithWait(f, c, pod)) </del> // Verify volume stat metrics were collected for the referenced PVC volumeStatKeys := []string{ kubeletmetrics.VolumeStatsUsedBytesKey,

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: What you expected to happen: Test should not flake /sig storage /cc
/assign
GitHub didn't allow me to assign the following users: vkamra. Note that only can be assigned. <detailsIn response to : /assign 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
/assign
GitHub didn't allow me to assign the following users: vkamra. Note that only can be assigned. <detailsIn response to : /assign 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
- You won't be able to assign this to me (not a kubernetes member). Am taking a look.
volumemetrics.go_ could/should have more logging, either calling or more calls to .
The test appears to fail on this metric: "kubeletvolumestatsused_bytes". So samplePVC != pvcName and/or sampleNS != namespace. It would be nice if the sample name and ns were also logged. Also something is weird here: the framework's is called before the local . Note in the log:
- will add a couple of Logf() statements to log the samples - you're right that will help. Once the volume is attached, volume stats are grabbed every interval. The thing I noticed in the logs is that we issue a delete for the pod at but the volume only got attached/bound successfully at The test assumes blocks till the pod is running and PVC is attached but maybe that's not a valid assumption?
Nevermind - That log message has 2 timestamps in it - the volume was provisioned at .
Pushed The working theory being that volume stats were not collected within the wait earlier being used.
did you figure out if I was correct in thinking that the framework was invoked before the local ? That seems very, very unlikely but that is how it looked in the log.
- I believe you're right that the framework is being invoked before the local one.

I observe the same in a test as well, so I don't think it's specific to this call. Based on the , nested blocks should be invoked inner-outer. It's not clear, however - whether the local is nested - or at the same level as the framework block when I look at