jiebi/CodeConvo huggingface dataset:
Change:
controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() controlPlaneConfig.GenericConfig.Authentication.Authenticator = authenticator.RequestFunc(func(req *http.Request) (*authenticator.Response, bool, error) { return &authenticator.Response{ <del> User: &user.DefaultInfo{Name: username}, </del> <ins> User: &user.DefaultInfo{ Name:   username, UID:    username, Groups: []string{user.AllAuthenticated}, }, </ins> }, true, nil }) controlPlaneConfig.GenericConfig.Authorization.Authorizer = sarAuthorizer{}

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:
t.Errorf("expect to get %d, but got %d", max-1, f) } } <ins> func TestAllocateUniqueness(t *testing.T) { max := 128 dynamicOffset := 16 uniqueAllocated := map[int]bool{} m := NewAllocationMapWithOffset(max, "test", dynamicOffset) // Allocate all the values in both the dynamic and reserved blocks for i := 0; i < max; i++ { alloc, ok, _ := m.AllocateNext() if !ok { t.Fatalf("unexpected error") } if _, ok := uniqueAllocated[alloc]; ok { t.Fatalf("unexpected allocated value %d", alloc) } else { uniqueAllocated[alloc] = true } } if max != len(uniqueAllocated) { t.Errorf("expect to get %d, but got %d", max, len(uniqueAllocated)) } } </ins>

Discussion:
In a enabled cluster, Kubernetes assigns duplicate IP addresses when the dynamic block is exhausted. I expected all clusterIPs are uniquely assigned. a enabled Kubernetes v1.24 cluster with a small service-cluster-ip-range. I confirmed on the minikube with the following command. services until the dynamic block is exhausted. see some clusterIPs are duplicated. No response <details</details<detailsminikube v1.25.2 </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
When the dynamic block is exhausted, we expect the service creation to fail with an error message like "No IP address available", right?
According to , Dynamically IP assignment will use the upper band by default, once this has been exhausted it will use the lower range. So I think using the reserved block (the lower range) is expected behavior
/sig network
upps /assign
/assign great catch, thanks
Change:
finalAttached:        true, trigerWatchEventTime: 100 * time.Millisecond, timeout:              50 * time.Millisecond, <del> sleepTime:            5 * time.Millisecond, </del> shouldFail:           true, }, } for i, tc := range testCases { <del> fakeWatcher.Reset() </del> <ins> plug, fakeWatcher, tmpDir := newTestWatchPlugin(t) defer os.RemoveAll(tmpDir) attacher, err := plug.NewAttacher() if err != nil { t.Fatalf("failed to create new attacher: %v", err) } csiAttacher := attacher.(*csiAttacher) </ins> t.Logf("running test: %v", tc.name) pvName := fmt.Sprintf("test-pv-%d", i) volID := fmt.Sprintf("test-vol-%d", i)

Discussion:
/kind bug /sig storage What happened: CSI unit tests occasionally end up with data race: How to reproduce it (as minimally and precisely as possible): to get CSI unit tests into a binary: the binary 500 times in parallel until it breaks: . Use different argument to really load your machine, it should not be idle! . On my Linux, I got 3 failures in ~1000 runs. puts stderr of failed runs into .
/assign
I make a Fix: PTAL
Change:
indexers *cache.Indexers, objectType reflect.Type) *watchCache { wc := &watchCache{ <del> capacity:            defaultLowerBoundCapacity, keyFunc:             keyFunc, getAttrsFunc:        getAttrsFunc, cache:               make([]*watchCacheEvent, defaultLowerBoundCapacity), lowerBoundCapacity:  defaultLowerBoundCapacity, upperBoundCapacity:  defaultUpperBoundCapacity, </del> <ins> capacity:     capacity, keyFunc:      keyFunc, getAttrsFunc: getAttrsFunc, cache:        make([]*watchCacheEvent, capacity), // TODO get rid of them once we stop passing capacity as a parameter to watch cache. lowerBoundCapacity:  min(capacity, defaultLowerBoundCapacity), upperBoundCapacity:  max(capacity, defaultUpperBoundCapacity), </ins> startIndex:          0, endIndex:            0, store:               cache.NewIndexer(storeElementKey, storeElementIndexers(indexers)),

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /priority critical-urgent /milestone v1.19
/sig api-machinery
Suspect it has to do with cc /assign (for CI signal ownership)
Seems unlikely since multiple kind e2e tests passed on the PR itself
I was thinking that as well, but I don't see any other relevant changes
Actually, I take that back. Looks like the same failure was encountered as a flake on some of the PR runs. Looking at the test, it appears to assume the resource version of the kubernetes service will always be in the watch window, which is a bad assumption. I'd expect us to fix that assumption in the test, but also make sure we didn't unintentionally shrink the watch window for resources.
/assign
Note: this also appears to be breaking
Failure seems to be timeout related as well shows the runtime ~tripled after merged
revert open in can investigate test failure and timeouts and bring the change back in
I take it back, the test tolerates an expired error explicitly.
showed 17 of the 22 runs since merged took ~1 hour. The first run after the revert at returned to less than 30 minutes for the run. Will keep an eye on that to see if subsequent runs match.
- thanks a lot for looking into it. I don't think my PR changed anything that anyone should rely on. I will take a deeper look into it and try to fix that (hopefully later this week).
contains the explanation and describes the bug (in fact this bug still exists in the codebase, that PR was only increasing the probability of this particular test hitting it)
Change:
// paths in the case that a user specifies the same volume/volume mount name. func (c *controlPlaneHostPathMounts) AddExtraHostPathMounts(component string, extraVols []kubeadmapi.HostPathMount) { for _, extraVol := range extraVols { <del> fmt.Printf("[control-plane] Adding extra host path mount %q to %qn", extraVol.Name, component) </del> hostPathType := extraVol.PathType c.NewHostPathMount(component, extraVol.Name, extraVol.HostPath, extraVol.MountPath, extraVol.ReadOnly, &hostPathType) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : when using kubeadm init include Why is this needed: the log only show extra-volumes for that control-plane? like this
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubeadm 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
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubeadm 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
/area kubeadm /kind cleanup /sig cluster-lifecycle
what version of kubeadm are you using?
this minor issue is in master too. the fix is in this PR:
Change:
if len(meta.UID) == 0 { meta.UID = old.UID } <del> if meta.CreationTimestamp.IsZero() { </del> <ins> // ignore changes to timestamp if old.CreationTimestamp.IsZero() { old.CreationTimestamp = meta.CreationTimestamp } else { </ins> meta.CreationTimestamp = old.CreationTimestamp }

Discussion:
After the DST change: We should be ignoring creationTimestamp on update.
Could you please explain the cause of the failure in more detail? Do we not normalize the timezone in the representation used in the API?
When we serialize to JSON we are using a value that has a timezone embedded in it (time.Time). As a result the representation changed. We should normalize it as well during serialization, but in general creationTimestamp should not prevent an update since it can safely be ignored.
I think we should allow creationTimestamp to be empty and also convert time to UTC() before marshaling.
More specifically: We'd also want to change: to and to
Makes sense to me - clients should always control their timezone and with distributed masters you might see different values. ----- Original Message -----
I'll own the follow up on this. ----- Original Message -----
+1 for UTC serialization
Opened to marshal to utc when serializing
Change:
return []string{devicePath}, nil } <ins> func fakeFilepathGlob2(devicePath string) (globs []string, err error) { return []string{ "/dev/disk/by-path/pci-0000:00:00.0-ip-127.0.0.1:3260-iqn.2014-12.com.example:test.tgt00-lun-0", }, nil } </ins> func TestExtractTransportname(t *testing.T) { fakeIscsiadmOutput := []string{ "# BEGIN RECORD 2.0-873n" +

Discussion:
Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.0-beta.1", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2017-06-08T13:08:32Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-10T15:38:08Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: Bare-Metal, HP SE316M, 2x X5675, 144GB, iSCSI/RDMA/iSer OS: CentOS 7 Kernel: Linux at-host-18 4.9.31 SMP Wed Jun 7 22:40:40 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others: What happened: I want to mount a iSCSI volume via iSER (RDMA over Infiniband) in this case the iSCSI iface is "iser" and not tcp, therefore the glob path for device mount is selected (), which then is passed to the fsck and mount commands without globbing the path (e.g. calling filepath.Glob) Therefore the iSCSI volume is not mounted and the pod cannot be started. Logs: What you expected to happen: To successfully mount the volume. How to reproduce it (as minimally and precisely as possible): Setup an iSCSI via RDMA (iSER) environment without multipath and try to mount a volume for a pod. Anything else we need to know: I believe it's just needed to add the globbing at line 259 like so: devicePaths = append(devicePaths, filepath.Glob(devicePath)) As I'm not a go programmer and have no experience with it, probably somebody could create a commit which I would gladly test!
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 storage
I'll take a look.
/sig storage
on a local build that fixed the issue: (e.g. it compiles)
I don't want to add filepath.Glob to that general path because that line is also executed "tcp" case. I'm considering the fix below. Pretty similar.
does that work from a go specific point? is that devicePath passed by reference? (from general c/c++/php/node/c# knowledge I would say that this would have no effect on the devicePath variable .. )
Can we suppose that filepath.Glob(devicePath) always only return one device path if transport is "tcp"?
does that work from a go specific point? is that devicePath passed by reference? (from general c/c++/php/node/c# knowledge I would say that this would have no effect on the devicePath variable .. ) Thank you for above comment. I updated the logic. Could you confirm the fix on the PR?
Pretty sure that tcp transport will always only have one path - and it will exist (there's no glob in the check path)
Change:
-o "${tmp_kube_env}"  http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env # Convert the yaml format file into a shell-style file. <del> eval "$(python3 -c ''' </del> <ins> eval "$(${PYTHON} -c ''' </ins> import pipes,sys,yaml <del> items = yaml.load(sys.stdin, Loader=yaml.BaseLoader).items() </del> <ins> # check version of python and call methods appropriate for that version if sys.version_info[0] < 3: items = yaml.load(sys.stdin).iteritems() else: items = yaml.load(sys.stdin, Loader=yaml.BaseLoader).items() </ins> for k, v in items: print("readonly {var}={value}".format(var=k, value=pipes.quote(str(v)))) ''' < "${tmp_kube_env}" > "${KUBE_HOME}/kube-env")"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gce-device-plugin-gpu Cluster up Apr 23 8:30PM PDT Taken from: From a , there are supposed to be three worker/minion nodes set up as well. Started failing after -- so maybe related to ? /cc /sig testing More examples of failing runs: /priority critical-urgent (this is a job on the release/master-blocking board)
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
It uses image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu as node image kubekins-e2e image is built from Base image is bootstrap image is built from with debian:buster and install python3.
The node image gke-1134-gke-rc5-cos-69--138-0-v190320-pre-nvda-gpu has no python3. We need to upgrade it.
Thanks for catching this and sending revert. Separately, we should definitely upgrade that image, cos-69 is super old and not supported anymore: /cc regarding GPU image
Change:
``` --api-version="": api-version for the cluster entry in kubeconfig --certificate-authority="": path to certificate-authority for the cluster entry in kubeconfig <del> --embed-certs=false: embed-certs for the cluster entry in kubeconfig --insecure-skip-tls-verify=false: insecure-skip-tls-verify for the cluster entry in kubeconfig </del> <ins> --embed-certs[=false]: embed-certs for the cluster entry in kubeconfig --insecure-skip-tls-verify[=false]: insecure-skip-tls-verify for the cluster entry in kubeconfig </ins> --server="": server for the cluster entry in kubeconfig ```

Discussion:
It acts like a boolean flag but requires an argument, unlike boolean flag is pretty much every environment. We need to find a better way to express the things that this is expressing. Maybe a add a tristate to the pflag lib that behaves the same way but doesn't demand an argument?
cc
The handles "true", "false", "unset" and has a default value. I seem to recall you were looking at changing it, but we needed to preserve the value. The complain here is that you have to do instead of just . /cc
fixing is really easy....
Change:
return err.HTTPStatusCode == http.StatusTooManyRequests || err.RetryAfter.After(now()) } <ins> // IsNotFound returns true the if the requested object wasn't found func (err *Error) IsNotFound() bool { if err == nil { return false } return err.HTTPStatusCode == http.StatusNotFound } </ins> // NewError creates a new Error. func NewError(retriable bool, err error) *Error { return &Error{

Discussion:
What happened: We saw several occurrences of kube-controller-manager failing to check a k8s node existence after we deleted that node's parent VMSS (and by extension, cloud instance). The leaked k8s nodes remained present in the cluster until manually deleted. Cloud provider retries caused a VMSS VMs API call surge, degenerating in hard throttling for the whole subscription. In those situations, kube-controller-manager would continuously log errors like the following: Looking at Azure cloud-provider implementation shows that all the VMSS API calls errors (including a 404/not found on the VMSS object) are bubbled up as generic errors, and never used as an indication of a missing instance. What you expected to happen: k8s nodes being removed as their VMSS went missing. How to reproduce it (as minimally and precisely as possible): Create and delete many VMSS providing instances registering to a cluster. Environment: Kubernetes version (use ): 1.19.0 Cloud provider or hardware configuration: Azure (self managed cluster, non AKS, ) OS (e.g: ): Linux, Ubuntu Focal 20.04.1 LTS Kernel (e.g. ): 5.4.0-1022-azure /sig cloud-provider /area provider/azure
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
Change:
"k8s.io/apimachinery/pkg/util/uuid" netutils "k8s.io/utils/net" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" </ins> kubefeatures "k8s.io/kubernetes/pkg/features" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
4 other Test Failures in ci-crio-cgroupv1-node-e2e-features. Test has failed 61 times (no passing result found). Earliest failure found at commit/ (Thu Oct 19 21:41 PDT). /cc { failed [FAILED] Error creating Pod: pods "pod-dualstack-host-ips9ddb9810-134c-4d35-a0c6-" is forbidden: violates PodSecurity "restricted:latest": host namespaces (hostNetwork=true) In [It] at: @ 10/23/23 01:38:06.024 } No response_ /sig network node
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
is also failing on these tests
the test has a bug, it checks the contrary
, let's start over, 1 commit for the e2e test, other for the promotion, and let's validate everything is alright before merging
Change:
verbs: - create - get <ins> - list - watch </ins> - apiGroups: - "" - events.k8s.io

Discussion:
When OwnerReferencesPermissionEnforcement admission plugin is used the PVCs are not deleted and KCM logs show PVCs should have ownerReferences set and the PVCs should be garbage collected on scale down 3 of 6 of the following tests fail when OwnerReferencesPermissionEnforcement admission plugin is turned on No response <details</details<detailsNA </details<details</details<details</details<details</details<details</details
/sig apps /triage accepted
Change:
match: k8s.gcr.io/pause:d+.d+ - path: test/utils/image/manifest.go match: configs[Pause] = Config{gcRegistry, "pause", "d+.d+"} <ins> # metadata-concealment: bump this one first - name: "metadata-concealment" version: "1.6" refPaths: - path: test/images/metadata-concealment/VERSION match: d.d # then after merge and successful postsubmit image push / promotion, bump this - name: "metadata-concealment: dependents" version: "1.6" refPaths: - path: test/utils/image/manifest.go match: configs[CheckMetadataConcealment] = Config{promoterE2eRegistry, "metadata-concealment", "d+.d+"} </ins>

Discussion:
Warning: The v0.1 and v1beta1 metadata server endpoints are deprecated and scheduled for shutdown on September 30, 2020. This test (which runs in most e2e jobs that run on GCE): Schedules a container that runs this: Resulting in a number of legacy metadata endpoints getting hit. To see if this test is going to start failing across all release branches on Sep 30th, we could try disabling the endpoints ahead of time via: In fact and support for expecting different results based on whether is set. My concern is the test expects 200 for some root endpoints, and 403 for disabled endpoints. However the e-mail I received as a GCP customer tells me any legacy endpoints may return 404. I'm inclined to suggest we remove the legacy endpoints from the check, bump the image version, and cherry-pick use of the new image version back to all release-branches. WDYT since you were involved with the earlier PRs /sig auth /sig cloud-provider /provider gcp /sig testing /priority important-soon (I'm tempted to critical-urgent this but it's not drop-everything yet) /milestone v1.20
/kind cleanup
Heyho I wanted to check how it is going? The code freeze is starting 12.11.2020 (about 3-4 weeks from now) and while there is still plenty of time, we want to ensure that each relevant issue has a chance to be considered. As the issue is tagged for 1.20, is it still planned for this release?
Bug Triage here, we're pretty late into code freeze and it doesn't look like there has been much activity recently. I am going to clear the milestone on this issue. /milestone clear
any update here?
Try to cleanup the legacy endpoints in
/milestone v1.21
/reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: )
Reopened this issue. <detailsIn response to : /reopen This needs to stay open until the new image has been verified to work and has been promoted (ref: ) 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
/triage accepted /assign