jiebi/CodeConvo huggingface dataset:
Change:
E2eNode Suite.[It] [sig-node] Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api E2eNode Suite.[It] [sig-node] OOMKiller [LinuxOnly] [NodeConformance] single process container The containers terminated by OOM killer should have the reason set to OOMKilled 7/22 No response No response /sig node
The problem with OOM kill looks the same as this pr
will fix this and is already approved(wait for 1.28 release and merge then). /assign
/triage accepted
That PR has been merged, but the problem continues to occur, for example today in
Still seeing this occur fairly regularly. I tested locally just increasing the length of the sleep call, but depending on the node load it still flaked. I'm hopeful but not certain that marking the test as serial in will eliminate the flake.
/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
I created to revert the change to serial. It doesn't completely resolve the issue, will be digging into this deeper when I get some time.
This looks like a containerd issue and already created a ticket there. I looked at containerd logs from a good and bad test run. In the good run, we get a in the container stopped event. In the bad run, we get a on the container stopped event.
Linking containerd tickets for completeness:
do you think it is a quick start in our case? Or something else
I don't think so since the sleep didn't appear to help. containerd reads the file in the cgroup directory to discover OOM kills. I think what's happening is some race where the cgroup directory gets cleaned up before it has a chance to read the file. I did some testing and when it fails, containerd tries to read but it has already been removed.
/retitle OOMKiller tests are flaking - sometimes condition returned as Failed instead of OOMKilled
/priority important-soon I suppose that we should fix it or at least make it less flaking.
I started to do this the other day. I didn't see any good way other than by listing processes and looking for containerd, skipping the test in that case. Seemed like a giant hack, but WDYT?
According to , we may skip it due to and
Not flake in recent three weeks. /close
Closing this issue. <detailsIn response to : Not flake in recent three weeks. /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

Discussion:
oomTargetContainerName string } <del> var _ = SIGDescribe("OOMKiller [LinuxOnly] [NodeConformance]", func() { </del> <ins> // Marked as [Serial] since currently the runtime can miss the OOM event if the pod is killed too quickly. This seems // to occur more often when the node is highly loaded. var _ = SIGDescribe("OOMKiller [LinuxOnly] [NodeConformance] [Serial]", func() { </ins> f := framework.NewDefaultFramework("oomkiller-test") f.NamespacePodSecurityLevel = admissionapi.LevelPrivileged
Change:
This issue was reported in the Impact An attacker may be able to guess a service account token secret, and impersonate the affected account to read, modify, or delete application data to which the account has access in a Kubernetes cluster. Description Service account token secrets () are a type of secret used to authenticate service accounts. The “Service account token Secrets” section of the Kubernetes “Configuration” documentation does not recommend their usage: Nevertheless, their usage appears to be possible, and may be employed by Kubernetes users. The process of creating a service account token is documented in the “Configure Service Accounts for Pods” documentation section. An incoming service account request is authenticated by first verifying the JWT signature of the token, then by comparing the secret token value embedded in the request, against the server’s record of the value. If the values don’t match, the authentication request is rejected. The comparison is performed in a non constant-time way; that is, it will return as soon as it reaches mismatched bytes between the two values. This leaks information about the token, which may assist attackers in successfully guessing the secret value. The issue is present in function of file (). Recommendation Compare the token secret values in constant-time. This can be achieved by using Go’s of the subtle package. Component kube-apiserver Location Function in file Anything else we need to know? See umbrella issue for current status of all issues created from these findings. The vendor gave this issue an ID of NCC-E003660-PCK and it was finding 16 of the report under the kube-apiserver section. The vendor considers this issue Risk as Informational, High Impact, Exploitability at None To view the original finding, begin on page 45 of the Test Environment Kubernetes 1.24.3
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 security
/assign
/sig auth

Discussion:
package serviceaccount import ( <del> "bytes" </del> "context" <ins> "crypto/subtle" </ins> "encoding/json" "errors" "fmt"

klog.V(4).Infof("Token is deleted and awaiting removal: %s/%s for service account %s/%s", namespace, secretName, namespace, serviceAccountName) return nil, errors.New("Token has been invalidated") } <del> if !bytes.Equal(secret.Data[v1.ServiceAccountTokenKey], []byte(tokenData)) { </del> <ins> if subtle.ConstantTimeCompare(secret.Data[v1.ServiceAccountTokenKey], []byte(tokenData)) == 0 { </ins> klog.V(4).Infof("Token contents no longer matches %s/%s for service account %s/%s", namespace, secretName, namespace, serviceAccountName) return nil, errors.New("Token does not match server's copy") }
Change:
Add a code static check for to report using server-side-apply extract With optimization of and , the will be removed in and , and maybe more of other components in the future, using Extract is problematic. It's safer to add this lint check.
/cc
/sig api-machinery
/sig scheduling /sig apps
/assign /triage accepted

Discussion:
- linters: - ginkgolinter text: use a function call in (Eventually|Consistently) <ins> # SSA Extract calls are allowed in tests. - linters: - forbidigo text: should not be used because managedFields was removed path: _test.go$ </ins> linters: disable-all: false # in contrast to golangci.yaml, the default set of linters remains enabled enable: # please keep this alphabetized and in sync with golangci.yaml <ins> - forbidigo </ins> - ginkgolinter - gocritic - govet

path: ../_output/local/bin/logcheck.so description: structured logging checker original-url: k8s.io/logtools/logcheck <ins> forbidigo: analyze-types: true forbid: - p: ^managedfields.ExtractInto$ pkg: ^k8s.io/apimachinery/pkg/util/managedfields$ msg: should not be used because managedFields was removed - p: .Extract pkg: ^k8s.io/client-go/applyconfigurations/ msg: should not be used because managedFields was removed </ins> gocritic: staticcheck: checks:

- linters: - ginkgolinter text: use a function call in (Eventually|Consistently) <ins> # SSA Extract calls are allowed in tests. - linters: - forbidigo text: should not be used because managedFields was removed path: _test.go$ </ins> linters: disable-all: true # not disabled in golangci-strict.yaml enable: # please keep this alphabetized and in sync with golangci-strict.yaml <ins> - forbidigo </ins> - ginkgolinter - gocritic - govet

path: ../_output/local/bin/logcheck.so description: structured logging checker original-url: k8s.io/logtools/logcheck <ins> forbidigo: analyze-types: true forbid: - p: ^managedfields.ExtractInto$ pkg: ^k8s.io/apimachinery/pkg/util/managedfields$ msg: should not be used because managedFields was removed - p: .Extract pkg: ^k8s.io/client-go/applyconfigurations/ msg: should not be used because managedFields was removed </ins> gocritic: enabled-checks:             # not limited in golangci-strict.yaml - equalFold               # not limited in golangci-strict.yaml

return nil, fmt.Errorf("failed to fetch the objectType: %v", err) } result := &unstructured.Unstructured{} <del> err = managedfields.ExtractInto(object, *objectType, fieldManager, result, subresource) </del> <ins> err = managedfields.ExtractInto(object, *objectType, fieldManager, result, subresource) //nolint:forbidigo </ins> if err != nil { return nil, fmt.Errorf("failed calling ExtractInto for unstructured: %v", err) }
Change:
[X] test approval issue : [X] test pr : [x] two weeks soak end date : 11 Sept 2023 [x] test promotion pr : [x] remove endpoint from According to following APIsnoop query, there are two PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 13 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC 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 13 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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

Discussion:
--- <del> - createCoreV1NamespacedPersistentVolumeClaim </del> - createCoreV1NamespacedServiceAccountToken - createCoreV1Node <del> - createCoreV1PersistentVolume </del> - createStorageV1CSINode - createStorageV1StorageClass - createStorageV1VolumeAttachment <del> - deleteCoreV1CollectionNamespacedPersistentVolumeClaim - deleteCoreV1CollectionPersistentVolume - deleteCoreV1NamespacedPersistentVolumeClaim </del> - deleteCoreV1Node <del> - deleteCoreV1PersistentVolume </del> - deleteStorageV1CollectionCSINode - deleteStorageV1CollectionStorageClass - deleteStorageV1CollectionVolumeAttachment

- deleteStorageV1VolumeAttachment - getInternalApiserverAPIGroup - getResourceAPIGroup <del> - listCoreV1PersistentVolumeClaimForAllNamespaces </del> - listStorageV1CSINode - listStorageV1StorageClass - listStorageV1VolumeAttachment <del> - patchCoreV1NamespacedPersistentVolumeClaim </del> - patchCoreV1NamespacedPersistentVolumeClaimStatus <del> - patchCoreV1PersistentVolume </del> - patchCoreV1PersistentVolumeStatus - patchStorageV1CSINode - patchStorageV1StorageClass - patchStorageV1VolumeAttachment - patchStorageV1VolumeAttachmentStatus <del> - readCoreV1NamespacedPersistentVolumeClaim </del> - readCoreV1NamespacedPersistentVolumeClaimStatus <del> - readCoreV1PersistentVolume </del> - readCoreV1PersistentVolumeStatus - readStorageV1CSINode - readStorageV1StorageClass - readStorageV1VolumeAttachment - readStorageV1VolumeAttachmentStatus <del> - replaceCoreV1NamespacedPersistentVolumeClaim </del> - replaceCoreV1NamespacedPersistentVolumeClaimStatus <del> - replaceCoreV1PersistentVolume </del> - replaceCoreV1PersistentVolumeStatus - replaceStorageV1CSINode - replaceStorageV1StorageClass
Change:
flakes several times recently /kind flake /sig api-machinery
This failure occurs for all tests in as mentioned in The description shows flaking.
/cc
/cc I remember someone tried to fix it some time ago,
/assign for context of /triage accepted
All of them fail with "connection not yet established" There is something odd in these tests, since we mock the KV but we create a "real" etcd process, I wonder if we flake on trying to connect to the real etcd process or there is some weird race because of that
do you want to try with ?

Discussion:
var prober *etcd3ProberMonitor clientErr := fmt.Errorf("etcd client connection not yet established") <del> go wait.PollUntil(time.Second, func() (bool, error) { newProber, err := newETCD3ProberMonitor(c) </del> <ins> go wait.PollImmediateUntil(time.Second, func() (bool, error) { </ins> lock.Lock() defer lock.Unlock() <ins> newProber, err := newETCD3ProberMonitor(c) </ins> // Ensure that server is already not shutting down. select { case <-stopCh:
Change:
Has been flaking on both and architectures. https://prow.ppc64le- TestTwoCRDsSameGroup /sig testing
/sig api-machinery /remove-sig testing
/cc /triage accepted
any ideas on this one?
I'm able to repro this with stress, happening about every 100-500 runs. Still trying to find the root cause.

Discussion:
ctx, cancel := context.WithCancel(context.Background()) factory.Start(ctx.Done()) <ins> factory.WaitForCacheSync(ctx.Done()) </ins> env.mux = http.NewServeMux() h := handler.NewOpenAPIService(&spec.Swagger{})
Change:
fails in build environments without network connection due to missing in-tree vendored dependency . Build to succeed with without needing to download any go dependencies. In a network-less build environment, run . No response Building off of the v1.28.0-rc.0 tag N/A <details</detailsN/A N/A N/A
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 release
This is a hack/tools dependency here by , he may have more context
hack/tools aren't vendored. if you want to ensure those are available offline, will do that
My hack for building with OBS (), see
Is this actually a bug?
in I agree we probably don't want to calls in the build path... in code generation or verify tools, that's more ok, but the build target of a particular SHA should be able to execute hermetically
opened to scope down when we do this to test targets, and avoid the install if the env already explicitly set GOMAXPROCS
fix merged to master and head of release-1.28 branch

Discussion:
# This seems to matter to some tools export GO15VENDOREXPERIMENT=1 <ins> } kube::golang::setup_gomaxprocs() { </ins> # GOMAXPROCS by default does not reflect the number of cpu(s) available # when running in a container, please see https://github.com/golang/go/issues/33803 <del> if ! command -v ncpu >/dev/null 2>&1; then # shellcheck disable=SC2164 pushd "${KUBE_ROOT}/hack/tools" >/dev/null GO111MODULE=on go install ./ncpu # shellcheck disable=SC2164 popd >/dev/null </del> <ins> if [[ -z "${GOMAXPROCS:-}" ]]; then if ! command -v ncpu >/dev/null 2>&1; then # shellcheck disable=SC2164 pushd "${KUBE_ROOT}/hack/tools" >/dev/null GO111MODULE=on go install ./ncpu || echo "Will not automatically set GOMAXPROCS" # shellcheck disable=SC2164 popd >/dev/null fi if command -v ncpu >/dev/null 2>&1; then GOMAXPROCS=$(ncpu) export GOMAXPROCS kube::log::status "Set GOMAXPROCS automatically to ${GOMAXPROCS}" fi </ins> fi <del> GOMAXPROCS=${GOMAXPROCS:-$(ncpu)} export GOMAXPROCS kube::log::status "Setting GOMAXPROCS: ${GOMAXPROCS}" </del> } # This will take binaries from $GOPATH/bin and copy them to the appropriate

source "${KUBE_ROOT}/hack/lib/init.sh" kube::golang::setup_env <ins> kube::golang::setup_gomaxprocs </ins> # start the cache mutation detector by default so that cache mutators will be found KUBE_CACHE_MUTATION_DETECTOR="${KUBE_CACHE_MUTATION_DETECTOR:-true}"
Change:
All the dual stack jobs ! ,%20ipvs,%20dual,%20master All dual stacks tests Since I modified this helper function to fix a flake ,%20ipvs,%20dual,%20master The function must consider only one IP family to verify the number of endpoints /assign /sig network /sig testing
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

Discussion:
return false, nil } <ins> // Endpoints are single family but EndpointSlices can have dual stack addresses, // so we verify the number of addresses that matches the same family on both. addressType := discoveryv1.AddressTypeIPv4 if isIPv6Endpoint(endpoint) { addressType = discoveryv1.AddressTypeIPv6 } </ins> esList, err := c.DiscoveryV1().EndpointSlices(namespace).List(ctx, metav1.ListOptions{LabelSelector: fmt.Sprintf("%s=%s", discoveryv1.LabelServiceName, serviceName)}) if err != nil { Logf("Unexpected error trying to get EndpointSlices for %s : %v", serviceName, err)

return false, nil } <del> if countEndpointsSlicesNum(esList) != expectNum { Logf("Unexpected number of Endpoints on Slices, got %d, expected %d", countEndpointsSlicesNum(esList), expectNum) </del> <ins> if countEndpointsSlicesNum(esList, addressType) != expectNum { Logf("Unexpected number of Endpoints on Slices, got %d, expected %d", countEndpointsSlicesNum(esList, addressType), expectNum) </ins> return false, nil } return true, nil

return num } <del> func countEndpointsSlicesNum(epList *discoveryv1.EndpointSliceList) int { </del> <ins> // isIPv6Endpoint returns true if the Endpoint uses IPv6 addresses func isIPv6Endpoint(e *v1.Endpoints) bool { for _, sub := range e.Subsets { for _, addr := range sub.Addresses { if len(addr.IP) == 0 { continue } // Endpoints are single family, so it is enough to check only one address return netutils.IsIPv6String(sub.Addresses[0].IP) } } // default to IPv4 an Endpoint without IP addresses return false } func countEndpointsSlicesNum(epList *discoveryv1.EndpointSliceList, addressType discoveryv1.AddressType) int { </ins> // EndpointSlices can contain the same address on multiple Slices addresses := sets.Set[string]{} for _, epSlice := range epList.Items { <ins> if epSlice.AddressType != addressType { continue } </ins> for _, ep := range epSlice.Endpoints { if len(ep.Addresses) > 0 { addresses.Insert(ep.Addresses[0])
Change:
hi, we have 3 master nodes , one of nodes errors output this err kubectl -n kube-system logs kube-apiserver-loshu-k8s-master02 k8s version lb proxy haproxy+keeaplive on-premise ubuntu 22.04 kubeadm containerd calico
/sig api-machinery for triage
/cc
Yes, looks like a real bug, an oversight in logic. Will fix.
Will this fix be backported to v1.26?
/cc hello, I want to know what the scenario of this problem is, what if I reproduce it? thanks
I have k8s 1.26 and recently got same error.
/triage accepted
I have observed the same error on v1.27.6
I have observed the same error on v1.28.3
I have observed the same error on v1.28.4
Try to update to the latest patch version.
it seems fixed in See vs
yep, it's been restored, but I want to know the reason it happens

Discussion:
} func (stats *seatDemandStats) update(obs fq.IntegratorResults) { <ins> stats.highWatermark = obs.Max if obs.Duration <= 0 { return } if math.IsNaN(obs.Deviation) { obs.Deviation = 0 } </ins> stats.avg = obs.Average stats.stdDev = obs.Deviation <del> stats.highWatermark = obs.Max </del> envelope := obs.Average + obs.Deviation stats.smoothed = math.Max(envelope, seatDemandSmoothingCoefficient*stats.smoothed+(1-seatDemandSmoothingCoefficient)*envelope) }
Change:
Follow up PR: would be good to use some local vars to make these statements shorter. Originally posted by in
/sig auth /triage accepted /kind cleanup /assign

Discussion:
} var resolver *claimResolver <del> if opts.JWTAuthenticator.ClaimMappings.Groups.Claim != "" { resolver = newClaimResolver(opts.JWTAuthenticator.ClaimMappings.Groups.Claim, client, verifierConfig) </del> <ins> groupsClaim := opts.JWTAuthenticator.ClaimMappings.Groups.Claim if groupsClaim != "" { resolver = newClaimResolver(groupsClaim, client, verifierConfig) </ins> } authenticator := &Authenticator{

} var username string <del> if err := c.unmarshalClaim(a.jwtAuthenticator.ClaimMappings.Username.Claim, &username); err != nil { return nil, false, fmt.Errorf("oidc: parse username claims %q: %v", a.jwtAuthenticator.ClaimMappings.Username.Claim, err) </del> <ins> usernameClaim := a.jwtAuthenticator.ClaimMappings.Username.Claim if err := c.unmarshalClaim(usernameClaim, &username); err != nil { return nil, false, fmt.Errorf("oidc: parse username claims %q: %v", usernameClaim, err) </ins> } <del> if a.jwtAuthenticator.ClaimMappings.Username.Claim == "email" { </del> <ins> if usernameClaim == "email" { </ins> // If the email_verified claim is present, ensure the email is valid. // https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims if hasEmailVerified := c.hasClaim("email_verified"); hasEmailVerified {

} } <del> if a.jwtAuthenticator.ClaimMappings.Username.Prefix != nil && *a.jwtAuthenticator.ClaimMappings.Username.Prefix != "" { username = *a.jwtAuthenticator.ClaimMappings.Username.Prefix + username </del> <ins> userNamePrefix := a.jwtAuthenticator.ClaimMappings.Username.Prefix if userNamePrefix != nil && *userNamePrefix != "" { username = *userNamePrefix + username </ins> } info := &user.DefaultInfo{Name: username} <del> if a.jwtAuthenticator.ClaimMappings.Groups.Claim != "" { if _, ok := c[a.jwtAuthenticator.ClaimMappings.Groups.Claim]; ok { </del> <ins> groupsClaim := a.jwtAuthenticator.ClaimMappings.Groups.Claim if groupsClaim != "" { if _, ok := c[groupsClaim]; ok { </ins> // Some admins want to use string claims like "role" as the group value. // Allow the group claim to be a single string instead of an array. // // See: https://github.com/kubernetes/kubernetes/issues/33290 var groups stringOrArray <del> if err := c.unmarshalClaim(a.jwtAuthenticator.ClaimMappings.Groups.Claim, &groups); err != nil { return nil, false, fmt.Errorf("oidc: parse groups claim %q: %v", a.jwtAuthenticator.ClaimMappings.Groups.Claim, err) </del> <ins> if err := c.unmarshalClaim(groupsClaim, &groups); err != nil { return nil, false, fmt.Errorf("oidc: parse groups claim %q: %v", groupsClaim, err) </ins> } info.Groups = []string(groups) } } <del> if a.jwtAuthenticator.ClaimMappings.Groups.Prefix != nil && *a.jwtAuthenticator.ClaimMappings.Groups.Prefix != "" { </del> <ins> groupsPrefix := a.jwtAuthenticator.ClaimMappings.Groups.Prefix if groupsPrefix != nil && *groupsPrefix != "" { </ins> for i, group := range info.Groups { <del> info.Groups[i] = *a.jwtAuthenticator.ClaimMappings.Groups.Prefix + group </del> <ins> info.Groups[i] = *groupsPrefix + group </ins> } }