jiebi/CodeConvo huggingface dataset:
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 --Following link on sig-network page () is broken Link should be working Kubernetes version (use ):1.21 Cloud provider or hardware configuration:None OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig-network
/sig network
/triage accepted

Related discussion:
text: return nil, nil, fmt.Errorf("could not access credential file %v - %v", pemFile, err) } <del> t := jwt.NewToken(*serviceAccount, authScope, pemBytes) token, err := t.Assert(&http.Client{}) </del> <ins> jwtConfig := &jwt.Config{ Email:      *serviceAccount, Scopes:     []string{authScope}, PrivateKey: pemBytes, TokenURL:   "https://accounts.google.com/o/oauth2/token", } token, err := jwtConfig.TokenSource(oauth2.NoContext).Token() </ins> if err != nil { <del> fmt.Printf("Invalid token: %vn", err) </del> return nil, nil, err } <del> config := &oauth.Config{ ClientId:     *clientId, ClientSecret: *clientSecret, Scope:        authScope, AuthURL:      "https://accounts.google.com/o/oauth2/auth", TokenURL:     "https://accounts.google.com/o/oauth2/token", </del> <ins> if !token.Valid() { return nil, nil, fmt.Errorf("invalid token for BigQuery oauth") </ins> } <del> transport := &oauth.Transport{ Token:  token, Config: config, </del> <ins> config := &oauth2.Config{ ClientID:     *clientId, ClientSecret: *clientSecret, Scopes:       []string{authScope}, Endpoint: oauth2.Endpoint{ AuthURL:  "https://accounts.google.com/o/oauth2/auth", TokenURL: "https://accounts.google.com/o/oauth2/token", }, </ins> } <del> client := transport.Client() </del> <ins> client := config.Client(oauth2.NoContext, token) </ins> service, err := bigquery.New(client) if err != nil {
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 --Following link on sig-network page () is broken Link should be working Kubernetes version (use ):1.21 Cloud provider or hardware configuration:None OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig-network
/sig network
/triage accepted

Related discussion:
text: } // Refresh expired token. <del> if c.token.Expired() { </del> <ins> if !c.token.Valid() { </ins> token, service, err := connect() if err != nil { return nil, err
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 --As described in issue , we found kubernetes have been running normally, but the control-plane nodes's metrics value of startTime is similar to the timestamp. Get the correct metrics of node As described in issue anything else we need to provide? As described in issue 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:
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 node
/remove-sig node /sig instrumentation /assign
I think the issue is about Summary API having start time for node metric, but this timestamp is incorrect. This is node issue, not instrumentation. /sig node /remove-sig instrumentation /unassign
When discussing adding node start time metric to /metrics/resource endpoint I remember that SIG Node response to this was that there is no good way to define node start time. I don't think we will be able to provide correct value here. As summary API is technically deprecated, it makes no sense to fix it. We should warn users against using it and wait for removal of Summary API.
Okay, let's wait for the release of metrics-server v0.6.0
Do you know if this is fixed in metrics server?
/triage needs-information Can you please add info on name of timeserias and other steps to repro ti understand exactly what is needed here. Thank you!
in metrics server v0.6.0, we will use /metrics/resource Kubelet endpoint instead summary API
as issue described , the result is: for example : the startup time of the node test-us-west-1-control-plane-577lp is "startTime": "2021-08-03T19:33:50Z",, and timestamp reported by metrics is "2021-08-03T19:34:36Z", but as described, output from control plane node

Related discussion:
text: apiVersion: apps/v1 kind: Deployment metadata: <del> name: metrics-server-v0.5.0 </del> <ins> name: metrics-server-v0.5.1 </ins> namespace: kube-system labels: k8s-app: metrics-server addonmanager.kubernetes.io/mode: Reconcile <del> version: v0.5.0 </del> <ins> version: v0.5.1 </ins> spec: selector: matchLabels: k8s-app: metrics-server <del> version: v0.5.0 </del> <ins> version: v0.5.1 </ins> template: metadata: name: metrics-server labels: k8s-app: metrics-server <del> version: v0.5.0 </del> <ins> version: v0.5.1 </ins> spec: securityContext: seccompProfile:
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 --As described in issue , we found kubernetes have been running normally, but the control-plane nodes's metrics value of startTime is similar to the timestamp. Get the correct metrics of node As described in issue anything else we need to provide? As described in issue 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:
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 node
/remove-sig node /sig instrumentation /assign
I think the issue is about Summary API having start time for node metric, but this timestamp is incorrect. This is node issue, not instrumentation. /sig node /remove-sig instrumentation /unassign
When discussing adding node start time metric to /metrics/resource endpoint I remember that SIG Node response to this was that there is no good way to define node start time. I don't think we will be able to provide correct value here. As summary API is technically deprecated, it makes no sense to fix it. We should warn users against using it and wait for removal of Summary API.
Okay, let's wait for the release of metrics-server v0.6.0
Do you know if this is fixed in metrics server?
/triage needs-information Can you please add info on name of timeserias and other steps to repro ti understand exactly what is needed here. Thank you!
in metrics server v0.6.0, we will use /metrics/resource Kubelet endpoint instead summary API
as issue described , the result is: for example : the startup time of the node test-us-west-1-control-plane-577lp is "startTime": "2021-08-03T19:33:50Z",, and timestamp reported by metrics is "2021-08-03T19:34:36Z", but as described, output from control plane node

Related discussion:
text: kubernetes.io/os: linux containers: - name: metrics-server <del> image: k8s.gcr.io/metrics-server/metrics-server:v0.5.0 </del> <ins> image: k8s.gcr.io/metrics-server/metrics-server:v0.5.1 </ins> command: - /metrics-server - --metric-resolution=30s
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 --As described in issue , we found kubernetes have been running normally, but the control-plane nodes's metrics value of startTime is similar to the timestamp. Get the correct metrics of node As described in issue anything else we need to provide? As described in issue 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:
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 node
/remove-sig node /sig instrumentation /assign
I think the issue is about Summary API having start time for node metric, but this timestamp is incorrect. This is node issue, not instrumentation. /sig node /remove-sig instrumentation /unassign
When discussing adding node start time metric to /metrics/resource endpoint I remember that SIG Node response to this was that there is no good way to define node start time. I don't think we will be able to provide correct value here. As summary API is technically deprecated, it makes no sense to fix it. We should warn users against using it and wait for removal of Summary API.
Okay, let's wait for the release of metrics-server v0.6.0
Do you know if this is fixed in metrics server?
/triage needs-information Can you please add info on name of timeserias and other steps to repro ti understand exactly what is needed here. Thank you!
in metrics server v0.6.0, we will use /metrics/resource Kubelet endpoint instead summary API
as issue described , the result is: for example : the startup time of the node test-us-west-1-control-plane-577lp is "startTime": "2021-08-03T19:33:50Z",, and timestamp reported by metrics is "2021-08-03T19:34:36Z", but as described, output from control plane node

Related discussion:
text: - --memory={{ base_metrics_server_memory }} - --extra-memory={{ metrics_server_memory_per_node }}Mi - --threshold=5 <del> - --deployment=metrics-server-v0.5.0 </del> <ins> - --deployment=metrics-server-v0.5.1 </ins> - --container=metrics-server - --poll-period=30000 - --estimator=exponential
Code change:
I'm seeing a panic in kube apiserver (see stack trace below). It appears to be linked to the migration away from Hashicorp's LRU implementation to in The Hashicorp implementation is thread-safe, however the forked copy in utils is not. See the comment here Looking at the utils PR, I see there's actually a wrapper around the thread unsafe LRU cache, and that's being used here: The LRU isn't a lot of code and I think I've convinced myself the locking works fine, so not sure why the element Value is coming back as nil instead of *entry. Stack trace: Not to panic Not sure, but I see it in our CI fairly often Kubernetes version (use ): 1.22Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
/sig api-machinery
if Add(key, nil) was called, that could set the value to nil in an existing object... does that happen?
The nil value we're hitting is on the linked list element, which is managed by the LRU code, not the user-facing value given in -- that gets saved The panic we hit is , where it tries to re-cast the LL element value back to the lru entry type. I don't see how that can happen.
The actual cache is perfectly happy with nil values:
From is mutating since it moves an element to the front when it's accessed. Thanks !
would you consider sending a PR to fix it? /assign /triage accepted
is the PR to fix

Related discussion:
text: log.Printf("Error parsing response (%#v): %s", response, err) return err } <del> log.Printf("Got initial state from etcd: %+v", manifests) </del> <ins> log.Printf("Got state from etcd: %+v", manifests) </ins> updateChannel <- manifestUpdate{etcdSource, manifests} return nil }
Code change:
I'm seeing a panic in kube apiserver (see stack trace below). It appears to be linked to the migration away from Hashicorp's LRU implementation to in The Hashicorp implementation is thread-safe, however the forked copy in utils is not. See the comment here Looking at the utils PR, I see there's actually a wrapper around the thread unsafe LRU cache, and that's being used here: The LRU isn't a lot of code and I think I've convinced myself the locking works fine, so not sure why the element Value is coming back as nil instead of *entry. Stack trace: Not to panic Not sure, but I see it in our CI fairly often Kubernetes version (use ): 1.22Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
/sig api-machinery
if Add(key, nil) was called, that could set the value to nil in an existing object... does that happen?
The nil value we're hitting is on the linked list element, which is managed by the LRU code, not the user-facing value given in -- that gets saved The panic we hit is , where it tries to re-cast the LL element value back to the lru entry type. I don't see how that can happen.
The actual cache is perfectly happy with nil values:
From is mutating since it moves an element to the front when it's accessed. Thanks !
would you consider sending a PR to fix it? /assign /triage accepted
is the PR to fix

Related discussion:
text: defer util.HandleCrash() for { watchResponse := <-watchChannel <del> log.Printf("Got change: %#v", watchResponse) </del> // This means the channel has been closed. if watchResponse == nil { return } <ins> log.Printf("Got etcd change: %#v", watchResponse) </ins> manifests, err := kl.extractFromEtcd(watchResponse) if err != nil { log.Printf("Error handling response from etcd: %#v", err)
Code change:
I'm seeing a panic in kube apiserver (see stack trace below). It appears to be linked to the migration away from Hashicorp's LRU implementation to in The Hashicorp implementation is thread-safe, however the forked copy in utils is not. See the comment here Looking at the utils PR, I see there's actually a wrapper around the thread unsafe LRU cache, and that's being used here: The LRU isn't a lot of code and I think I've convinced myself the locking works fine, so not sure why the element Value is coming back as nil instead of *entry. Stack trace: Not to panic Not sure, but I see it in our CI fairly often Kubernetes version (use ): 1.22Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
/sig api-machinery
if Add(key, nil) was called, that could set the value to nil in an existing object... does that happen?
The nil value we're hitting is on the linked list element, which is managed by the LRU code, not the user-facing value given in -- that gets saved The panic we hit is , where it tries to re-cast the LL element value back to the lru entry type. I don't see how that can happen.
The actual cache is perfectly happy with nil values:
From is mutating since it moves an element to the front when it's accessed. Thanks !
would you consider sending a PR to fix it? /assign /triage accepted
is the PR to fix

Related discussion:
text: // Sync the configured list of containers (desired state) with the host current state func (kl *Kubelet) SyncManifests(config []api.ContainerManifest) error { <del> log.Printf("Desired:%#v", config) </del> <ins> log.Printf("Desired: %#v", config) </ins> var err error desired := map[string]bool{} for _, manifest := range config {
Code change:
I'm seeing a panic in kube apiserver (see stack trace below). It appears to be linked to the migration away from Hashicorp's LRU implementation to in The Hashicorp implementation is thread-safe, however the forked copy in utils is not. See the comment here Looking at the utils PR, I see there's actually a wrapper around the thread unsafe LRU cache, and that's being used here: The LRU isn't a lot of code and I think I've convinced myself the locking works fine, so not sure why the element Value is coming back as nil instead of *entry. Stack trace: Not to panic Not sure, but I see it in our CI fairly often Kubernetes version (use ): 1.22Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
/sig api-machinery
if Add(key, nil) was called, that could set the value to nil in an existing object... does that happen?
The nil value we're hitting is on the linked list element, which is managed by the LRU code, not the user-facing value given in -- that gets saved The panic we hit is , where it tries to re-cast the LL element value back to the lru entry type. I don't see how that can happen.
The actual cache is perfectly happy with nil values:
From is mutating since it moves an element to the front when it's accessed. Thanks !
would you consider sending a PR to fix it? /assign /triage accepted
is the PR to fix

Related discussion:
text: continue } if !exists { <del> log.Printf("Network container doesn't exit, creating") </del> <ins> log.Printf("Network container doesn't exist, creating") </ins> netName, err = kl.createNetworkContainer(&manifest) if err != nil { log.Printf("Failed to create network container: %#v", err)
Code change:
I'm seeing a panic in kube apiserver (see stack trace below). It appears to be linked to the migration away from Hashicorp's LRU implementation to in The Hashicorp implementation is thread-safe, however the forked copy in utils is not. See the comment here Looking at the utils PR, I see there's actually a wrapper around the thread unsafe LRU cache, and that's being used here: The LRU isn't a lot of code and I think I've convinced myself the locking works fine, so not sure why the element Value is coming back as nil instead of *entry. Stack trace: Not to panic Not sure, but I see it in our CI fairly often Kubernetes version (use ): 1.22Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
/sig api-machinery
if Add(key, nil) was called, that could set the value to nil in an existing object... does that happen?
The nil value we're hitting is on the linked list element, which is managed by the LRU code, not the user-facing value given in -- that gets saved The panic we hit is , where it tries to re-cast the LL element value back to the lru entry type. I don't see how that can happen.
The actual cache is perfectly happy with nil values:
From is mutating since it moves an element to the front when it's accessed. Thanks !
would you consider sending a PR to fix it? /assign /triage accepted
is the PR to fix

Related discussion:
text: } } existingContainers, _ := kl.ListContainers() <del> log.Printf("Existing:n%#v Desired: %#v", existingContainers, desired) </del> <ins> log.Printf("Existing: %#v Desired: %#v", existingContainers, desired) </ins> for _, container := range existingContainers { // Skip containers that we didn't create to allow users to manually // spin up their own containers if they want.
Code change:
SSH'ed into a GKE node running on GCP and was welcomed by following MOTD message: a) Noticed download link is not working, I suspect this storage bucket is no longer used (?) b) Link to get Kuberntes source version does not work: This should be following (without ) Working links :) This is defined in the "configure-" file bellow: As this seems GCP specific (IIUC), I think filtering "-gke.501" will fix part a) For b) I am not sure what the correct download link should be Kubernetes version: Kubernetes v1.18.20-gke.501 Cloud provider: GCP OS: COS
Pull request to remove "-gke." from link to Github to make it valid. Regarding the wrong download link to GKE source code release, I noticed that: When running on GKE the link has (GCS storage bucket name) while in OOS Kubernetes it is . (So GKE is patched here) I think is depreciated and replaced by but in either case link don' work. It's unclear how one can download the source code.
/sig cloud-provider release for triagingnot sure if the link is maintained by release team /area provider/gcp
Was able to confirm the right download location ( GCS bucket) to download GKE source release. Submitted separate PR to fix the URL.
/assign /triage accepted
This is an related to the GKE product. I've filed this to the public :
/close
Closing this issue. <detailsIn response to : /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

Related discussion:
text: https://storage.googleapis.com/kubernetes-release/release/${version}/kubernetes-src.tar.gz It is based on the Kubernetes source at: <del> https://github.com/kubernetes/kubernetes/tree/${gitref} </del> <ins> https://github.com/kubernetes/kubernetes/tree/${gitref/-gke.*/} </ins> ${devel} For Kubernetes copyright and licensing information, see: /home/kubernetes/LICENSES
Code change:
N/A [sig-node] NodeProblemDetector: N/A https://prow- Not cgroupv2 compatible when access cpu and memory data
/sig node
Hi, can i work on this ?
Sure. Thanks
/assign
/triage accepted
/priority important-soon
/cc
are you still working on this? Were you able to setup environment to repro the test failure? Let us know if you need any help. Thanks!
Sorry for the delay, I followed the wrong guide and ended up getting stuck. But now I have managed to set it up. Please give me few more days to work on it.
Thanks Feel free to reach out here or on slack if you need any help, thanks for working on this!
/retitle Make nodeproblemdetector test cgroupv2 compatible
Failing job:
Testgrid:

Related discussion:
text: } func getMemoryStat(f *framework.Framework, host string) (rss, workingSet float64) { <del> memCmd := "cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.usage_in_bytes && cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.stat" </del> <ins> var memCmd string isCgroupV2 := isHostRunningCgroupV2(f, host) if isCgroupV2 { memCmd = "cat /sys/fs/cgroup/system.slice/node-problem-detector.service/memory.current && cat /sys/fs/cgroup/system.slice/node-problem-detector.service/memory.stat" } else { memCmd = "cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.usage_in_bytes && cat /sys/fs/cgroup/memory/system.slice/node-problem-detector.service/memory.stat" } </ins> result, err := e2essh.SSH(memCmd, host, framework.TestContext.Provider) framework.ExpectNoError(err) framework.ExpectEqual(result.Code, 0)