jiebi/CodeConvo huggingface dataset:
Code change:
What happened: I checked if kubelet () has permissions for with SelfsubjectAccessReviews and I saw that it has. But when I checked its permissions with SelfsubjectRulesReviews it didn't show it. What you expected to happen: I expected that the API SelfsubjectRulesReviews will show that has permssions for . How to reproduce it (as minimally and precisely as possible): You can check it on the master or the worker. Test SelfsubjectAccessReviews: You will get answer that it has permissions: Test SelfsubjectRulesReviews: It won't show the permissions. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ):Install tools: kubeadm /area/api /kind/bug /sig api-machinery
/sig api-machinery
This is a more clean display that show the bug: I think the problem is related to the fact that the file contain the kubelet certificate which is part of the group :
/sig auth
What is the SelfSubjectRulesReview response from the server ()? Note that not all authorizers support enumerating permissions, and the API object status includes an attribute which explicitly indicates the result is incomplete. See
It has Details:
I noticed that it also doesn't show that it has permissions to view and . It probably related to the Node authorizer: Because I assume that these rules doesn't appear in RBAC.
The node authorizer does not enumerate permissions, so it does not contribute to SelfSubjectRulesReview results
fixes setting correctly when the API is requested with a kubelet's credentials

Related discussion:
text: populate(g, nodes, pods, pvs, attachments) identifier := nodeidentifier.NewDefaultNodeIdentifier() <del> authz := NewAuthorizer(g, identifier, bootstrappolicy.NodeRules()).(*NodeAuthorizer) </del> <ins> authz := NewAuthorizer(g, identifier, bootstrappolicy.NodeRules()) </ins> node0 := &user.DefaultInfo{Name: "system:node:node0", Groups: []string{"system:nodes"}}
Code change:
<!-- 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)

Related discussion:
text: // Config contains the configuration for a given Cache. type Config struct { // Maximum size of the history cached in memory. <del> // // DEPRECATED: Cache capacity is dynamic and this field is no longer used. </del> CacheCapacity int // An underlying storage.Interface.
Code change:
<!-- 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)

Related discussion:
text: } watchCache := newWatchCache( <del> config.KeyFunc, cacher.processEvent, config.GetAttrsFunc, config.Versioner, config.Indexers, objType) </del> <ins> config.CacheCapacity, config.KeyFunc, cacher.processEvent, config.GetAttrsFunc, config.Versioner, config.Indexers, objType) </ins> listerWatcher := NewCacherListerWatcher(config.Storage, config.ResourcePrefix, config.NewListFunc) reflectorName := "storage/cacher.go:" + config.ResourcePrefix
Code change:
<!-- 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)

Related discussion:
text: } func newWatchCache( <ins> capacity int, </ins> keyFunc func(runtime.Object) (string, error), eventHandler func(*watchCacheEvent), getAttrsFunc func(runtime.Object) (labels.Set, fields.Set, error),
Code change:
<!-- 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)

Related discussion:
text: 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)),
Code change:
<!-- 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)

Related discussion:
text: } versioner := etcd3.APIObjectVersioner{} mockHandler := func(*watchCacheEvent) {} <del> wc := newWatchCache(keyFunc, mockHandler, getAttrsFunc, versioner, indexers, reflect.TypeOf(&example.Pod{})) // To preserve behavior of tests that assume a given capacity, // resize it to th expected size. wc.capacity = capacity wc.cache = make([]*watchCacheEvent, capacity) wc.lowerBoundCapacity = min(capacity, defaultLowerBoundCapacity) wc.upperBoundCapacity = max(capacity, defaultUpperBoundCapacity) </del> <ins> wc := newWatchCache(capacity, keyFunc, mockHandler, getAttrsFunc, versioner, indexers, reflect.TypeOf(&example.Pod{})) </ins> wc.clock = clock.NewFakeClock(time.Now()) return wc }
Code change:
<!-- 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: UT TestValidateNodeIPParam does not really tests . The first IP and interface are always 127.0.0.1 and lo and will break the loop. So will never be appended into . What you expected to happen: gets tested correctly. 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:
/sig node
/sig node

Related discussion:
text: ip = v.IP } if ip.IsLoopback() || ip.IsLinkLocalUnicast() { <del> break </del> <ins> continue </ins> } successTest := test{ nodeIP:   ip.String(),
Code change:
apiserverrequest (total, latency histogram) metrics are likely the two most important metrics emitted by the kube-apiserver, aggregator, and aggregated-apiserver binaries. has been open for a year regarding some of the issues that have been ongoing problems. I want to open up a discussion on: (1) cleaning this metric up so that it can be used reliably and consistently for many versions addressing as many of the cardinality concerns as possible (2) explicitly defining a set of prescriptions for adding new metrics which may require joins to this very centrally important metric These metrics are critically important because people use them for SLIs/SLOs. In fact we define SLOs for them here (). Yet, due to the fact that people can inject arbitrary webhooks into the request flow process, we can never actually guarantee that the apiserver response time actually meets our stated objectives. Which brings us to the other dimension in which these metrics are flawed. They do not account for apiserver request processing time, exclusive of webhook processing time. As long as we do not break out internal request processing time, it is possible that arbitrary clusters will never be able to meet our internally stated service level objectives given the one metrics we provide.
/sig api-machinery instrumentation /assign
The cardinality issues hit us here pretty badly, just one example for this, I suppose: Soo :100: % agree.
/milestone v1.20
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?
Ah, this is going to be slated for 1.21. /milestone v1.21
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
/remove-lifecycle stale
/open
/re-open
Hello! I am from the Bug Triage team! Friendly reminder that code freeze is starting March 9th, 2021 (today!). As the Issue is tagged for 1.21, and the PRs linked are merged and marked for 1.21, can we close this one?
Yes! :)
Thanks !

Related discussion:
text: // Thus we customize buckets significantly, to empower both usecases. Buckets: []float64{0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.25, 1.5, 1.75, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5, 6, 7, 8, 9, 10, 15, 20, 25, 30, 40, 50, 60}, <del> StabilityLevel: compbasemetrics.ALPHA, </del> <ins> StabilityLevel: compbasemetrics.STABLE, </ins> }, []string{"verb", "dry_run", "group", "version", "resource", "subresource", "scope", "component"}, )
Code change:
apiserverrequest (total, latency histogram) metrics are likely the two most important metrics emitted by the kube-apiserver, aggregator, and aggregated-apiserver binaries. has been open for a year regarding some of the issues that have been ongoing problems. I want to open up a discussion on: (1) cleaning this metric up so that it can be used reliably and consistently for many versions addressing as many of the cardinality concerns as possible (2) explicitly defining a set of prescriptions for adding new metrics which may require joins to this very centrally important metric These metrics are critically important because people use them for SLIs/SLOs. In fact we define SLOs for them here (). Yet, due to the fact that people can inject arbitrary webhooks into the request flow process, we can never actually guarantee that the apiserver response time actually meets our stated objectives. Which brings us to the other dimension in which these metrics are flawed. They do not account for apiserver request processing time, exclusive of webhook processing time. As long as we do not break out internal request processing time, it is possible that arbitrary clusters will never be able to meet our internally stated service level objectives given the one metrics we provide.
/sig api-machinery instrumentation /assign
The cardinality issues hit us here pretty badly, just one example for this, I suppose: Soo :100: % agree.
/milestone v1.20
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?
Ah, this is going to be slated for 1.21. /milestone v1.21
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
/remove-lifecycle stale
/open
/re-open
Hello! I am from the Bug Triage team! Friendly reminder that code freeze is starting March 9th, 2021 (today!). As the Issue is tagged for 1.21, and the PRs linked are merged and marked for 1.21, can we close this one?
Yes! :)
Thanks !

Related discussion:
text: <ins> - name: apiserver_request_duration_seconds help: Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component. type: Histogram stabilityLevel: STABLE labels: - component - dry_run - group - resource - scope - subresource - verb - version buckets: - 0.05 - 0.1 - 0.15 - 0.2 - 0.25 - 0.3 - 0.35 - 0.4 - 0.45 - 0.5 - 0.6 - 0.7 - 0.8 - 0.9 - 1 - 1.25 - 1.5 - 1.75 - 2 - 2.5 - 3 - 3.5 - 4 - 4.5 - 5 - 6 - 7 - 8 - 9 - 10 - 15 - 20 - 25 - 30 - 40 - 50 - 60 </ins> - name: apiserver_request_total help: Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code.
Code change:
What happened: does not handle "holes" in interface device-number correctly, dropping later interfaces. Create instance with eth0, eth1, eth2 ENIs as usual. Remove (eg: by selectively deleting pods) eth1. Only the addresses on eth0 are reported by NodeAddresses. What you expected to happen: Addresses on eth0 and eth2 should be reported.
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍

Related discussion:
text: // We want the IPs to end up in order by interface (in particular, we want eth0's // IPs first), but macs isn't necessarily sorted in that order so we have to // explicitly order by device-number (device-number == the "0" in "eth0"). <del> macIPs := make(map[int]string) </del> <ins> var macIDs []string macDevNum := make(map[string]int) </ins> for _, macID := range strings.Split(macs, "n") { if macID == "" { continue
Code change:
What happened: does not handle "holes" in interface device-number correctly, dropping later interfaces. Create instance with eth0, eth1, eth2 ENIs as usual. Remove (eg: by selectively deleting pods) eth1. Only the addresses on eth0 are reported by NodeAddresses. What you expected to happen: Addresses on eth0 and eth2 should be reported.
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍

Related discussion:
text: klog.Warningf("Bad device-number %q for interface %sn", numStr, macID) continue } <ins> macIDs = append(macIDs, macID) macDevNum[macID] = num } // Sort macIDs by interface device-number sort.Slice(macIDs, func(i, j int) bool { return macDevNum[macIDs[i]] < macDevNum[macIDs[j]] }) for _, macID := range macIDs { </ins> ipPath := path.Join("network/interfaces/macs/", macID, "local-ipv4s") <del> macIPs[num], err = c.metadata.GetMetadata(ipPath) </del> <ins> internalIPs, err := c.metadata.GetMetadata(ipPath) </ins> if err != nil { return nil, fmt.Errorf("error querying AWS metadata for %q: %q", ipPath, err) } <del> } for i := 0; i < len(macIPs); i++ { internalIPs := macIPs[i] if internalIPs == "" { continue } </del> for _, internalIP := range strings.Split(internalIPs, "n") { if internalIP == "" { continue
Code change:
What happened: does not handle "holes" in interface device-number correctly, dropping later interfaces. Create instance with eth0, eth1, eth2 ENIs as usual. Remove (eg: by selectively deleting pods) eth1. Only the addresses on eth0 are reported by NodeAddresses. What you expected to happen: Addresses on eth0 and eth2 should be reported.
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍

Related discussion:
text: if len(keySplit) == 5 && keySplit[4] == "device-number" { for i, macElem := range m.aws.networkInterfacesMacs { if macParam == macElem { <del> return fmt.Sprintf("%dn", i), nil </del> <ins> n := i if n > 0 { // Introduce an artificial gap, just to test eg: [eth0, eth2] n++ } return fmt.Sprintf("%dn", n), nil </ins> } } }