jiebi/CodeConvo huggingface dataset:
Change:
// Add the volumes to ASW rc.updateStates(reconstructedVolumes) <del> // The reconstructed volumes are mounted, hence a previous kubelet must have already put it into node.status.volumesInUse. // Remember to update DSW with this information. rc.volumesNeedReportedInUse = reconstructedVolumeNames </del> // Remember to update devicePath from node.status.volumesAttached rc.volumesNeedUpdateFromNodeStatus = reconstructedVolumeNames }

Discussion:
remove and was introduced in to fix This is to overcome the situation that volume is to DSW at first and then deleted before it is to ASW, which causes mounted volume neither in DSW nor ASW and won't execute unmount/detach: The reason the volume cannot be to ASW in time is , which is . However, there is another PR also solved the issue. What it did is to check whether ASW already has the volume before deleting it from DSW, this makes sure that volume can be detached/unmounted after it is deleted from DSW. I suggest that we can keep the second solution and remove related code to make the reconstruction process and reconcile loop cleaner?
/sig storage
cc
Should I proceed with this issue? Your guidance is appreciated.
I think we'd better wait for the feedback from
cc
Sorry for a late reply. This is how behind we are with reviews :-(. Reading Now that is on by default, it reconstructs volumes first and always puts them to ASW, it should never happen that a reconstructed volume is in DSW and not in ASW, right? So we can remove easily. I would not be so sure without , because the code is 5 years old and who knows all the implications. You could be right though, it may not be necessary there too.
/triage accepted
/assign
Change:
return nil } <ins> // nolint:errcheck   // Ignore the error returned by Register as before </ins> var registry = func() Registry { r := make(Registry) r.Register(scoreWithNormalizePlugin1, newScoreWithNormalizePlugin1) r.Register(scoreWithNormalizePlugin2, newScoreWithNormalizePlugin2) r.Register(scorePlugin1, newScorePlugin1) <ins> r.Register(scorePlugin2, newScorePlugin2) </ins> r.Register(pluginNotImplementingScore, newPluginNotImplementingScore) r.Register(duplicatePluginName, newDuplicatePlugin) r.Register(testPlugin, newTestPlugin)

Discussion:
Scheduler's default plugin returns an invalid score that is not in the range of [0, 100], resulting in no Pods being scheduled: After investigation, I found that there was a bug in the code that built the framework when the scheduler started. When using the plugins declared in the regular extension point to override the plugins declared in the MultiPoint, the traversed variable will be modified in the following loop: This may cause a same scoring plugin (e.g. ) to be loaded multiple times: Further, this results in a node being processed multiple times by a plugin's (e.g. 's) method, resulting in an invalid score that is not in the range of [0, 100]: If the scheduler's MultiPoint feature is used (either through the default plugins or through manual configuration), and the configuration (e.g. the scoring weight) of a certain plugin is overridden in a regular extension point, the plugin will only be loaded once in this extension point, and no illegal scores will be returned. An example KubeSchedulerConfiguration: No response K8s v1.24.15 or higher None <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
/sig scheduling
Can I work on this?
this is being worked on. see
I see, Is there any other task that you are aware of and I can work on? Thanks.
Change:
<del> /* Copyright 2014 Google Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package e2e import ( "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/golang/glog" . "github.com/onsi/ginkgo" . "github.com/onsi/gomega" ) // TestImportantURLs validates that URLs that people depend on haven't moved. // ***IMPORTANT*** Do *not* fix this test just by changing the path.  If you moved a URL // you can break upstream dependencies. func TestImportantURLs(c *client.Client) bool { tests := []struct { path string }{ {path: "/validate"}, {path: "/healthz"}, // TODO: test proxy links here } ok := true for _, test := range tests { glog.Infof("testing: %s", test.path) data, err := c.RESTClient.Get(). AbsPath(test.path). Do(). Raw() if err != nil { glog.Errorf("Failed: %vnBody: %s", err, string(data)) ok = false } } return ok } var _ = Describe("TestImportantURLs", func() { It("should pass", func() { // TODO: Instead of OrDie, client should Fail the test if there's a problem. // In general tests should Fail() instead of glog.Fatalf(). Expect(TestImportantURLs(loadClientOrDie())).To(BeTrue()) }) }) </del>

Discussion:
Create a ginkgo networking test suite and add the following tests to it: TestNetwork TestImportantURLs
Part of the ginkgo-ization of the e2e tests
Change:
runcmd: - modprobe configs <del> - docker run -v /dev:/dev -v /home/kubernetes/bin/nvidia:/rootfs/nvidia -v /etc/os-release:/rootfs/etc/os-release -v /proc/sysrq-trigger:/sysrq -e LAKITU_KERNEL_SHA1=26481563cb3788ad254c2bf2126b843c161c7e48 -e BASE_DIR=/rootfs/nvidia --privileged gcr.io/google_containers/cos-nvidia-driver-install@sha256:ad83ede6e0c6d768bf7cf69a7dec972aa5e8f88778142ca46afd3286ad58cfc8 </del> <ins> - docker run -v /dev:/dev -v /home/kubernetes/bin/nvidia:/rootfs/nvidia -v /etc/os-release:/rootfs/etc/os-release -v /proc/sysrq-trigger:/sysrq -e BASE_DIR=/rootfs/nvidia --privileged gcr.io/google_containers/cos-nvidia-driver-install@sha256:cb55c7971c337fece62f2bfe858662522a01e43ac9984a2dd1dd5c71487d225c </ins> - mount /tmp /tmp -o remount,exec,suid - usermod -a -G docker jenkins - mkdir -p /var/lib/kubelet

Discussion:
xref: /sig node /area test
I am working on this.
Can you update this with the types of tests that you are adding? Is this similar to ?
No, this is for running the existing GPU e2e tests on GKE which are currently running on only GCE.
The referenced PRs appear to have merged, closing.
Change:
framework.ExpectNoError(err, "while getting node status") ginkgo.By("Verifying that the node now supports huge pages with size 3Mi") <del> gomega.Expect(node.Status.Capacity).To(gomega.HaveKeyWithValue("hugepages-3Mi", resource.MustParse("9Mi")), "capacity should contain resource hugepages-3Mi and huge pages with size 3Mi should be supported") </del> <ins> value, ok := node.Status.Capacity["hugepages-3Mi"] if !ok { framework.Failf("capacity should contain resource hugepages-3Mi: %v", node.Status.Capacity) } gomega.Expect(value.String()).To(gomega.Equal("9Mi"), "huge pages with size 3Mi should be supported") </ins> ginkgo.By("restarting the node and verifying that huge pages with size 3Mi are not supported") restartKubelet(true)

Discussion:
The Huge pages test in both containerd/cri is consistently failing. Not sure. No response There was a deprecation for ExpectEqual merged about a week ago on this same line. maybe you could take a look and see why this check is failing? modified this line /sig 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
Change:
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

Discussion:
<!-- 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
Change:
// 1. One or more of the provided EndpointSlices have older generations than the //    corresponding tracked ones. // 2. The tracker is expecting one or more of the provided EndpointSlices to be <del> //    deleted. </del> <ins> //    deleted. (EndpointSlices that have already been marked for deletion are ignored here.) </ins> // 3. The tracker is tracking EndpointSlices that have not been provided. func (est *EndpointSliceTracker) StaleSlices(service *v1.Service, endpointSlices []*discovery.EndpointSlice) bool { est.lock.Lock()

Discussion:
As discussed in , Endpoint(Slice) controllers can get stuck if an Endpoints or EndpointSlice resource is stuck in a terminating state. I don't think there's much we can do for Endpoints here since the same name is reused, but EndpointSlice controllers can ignore EndpointSlices in a terminating state. See No response All supported versions Any Any Any Any Any
/sig network
/triage accepted
deleting a service with a finalizer doesn't affect the endpointslice, it doesn't change its status to termination or unready Repro: finalizer to the service and delete it, it keeps waiting until the finalizer is removed with the deletion timestamp set. the endpoint slice associated Do you mean that when the endpoint slice controller detects that the Service is being deleted should switch the endpoint slice status to Terminating? cc:
I don't think we need to do anything special if the Service is waiting to be deleted. There are many legitimate reasons for this to happen, including waiting for infrastructure to be removed. My main concern with a finalizer was that one on an EndpointSlice could cause the controller to get stuck on a Service. We don't have the same risk with a finalizer on a Service - I don't think that would cause the controller to get stuck in any way.
i was unable to repro the issue on my machine: I was monitoring the logs of , and the endpointslice controller never complained about , when I deleted the service. Though, I was able to get the controller to log this error under a different scenario. If we don't explicitly remove the finalizer from the endpointslice, and instead re-create the pod and service like: From what I can understand, because the endpointslice with the finalizer is owned by a service with a different UID than the new endpointslice, it is marked as expected for deletion . The endpointslice controllers calls , which returns true for the endpointslice with the finalizer, because of the above reason. I might be wrong anywhere here, so please let me know if that is the case. As for further action, I'm not sure what can be done here? We could check the endpointslice for finalizers and then skip them . Keen to hear your thoughts about this.
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry/minion" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry/registrytest" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </del> ) func TestServiceRegistryCreate(t *testing.T) {

Discussion:
We have seen that on VirtualBox in particular kubelet picks first interfaces, which is usually NATed and is of no use. In particular the issue comes up with service IP, which gets mapped to endpoint on the NATed interface.
If this is still a problem, can you explain more - I don't quite understand - and suggest heuristics for better solutions?
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
} return persistentvolumes, nil } <ins> func CreatePVSource(zone string) (*v1.PersistentVolumeSource, error) { diskName, err := CreatePDWithRetryAndZone(zone) if err != nil { return nil, err } if TestContext.Provider == "gce" || TestContext.Provider == "gke" { return &v1.PersistentVolumeSource{ GCEPersistentDisk: &v1.GCEPersistentDiskVolumeSource{ PDName:   diskName, FSType:   "ext3", ReadOnly: false, }, }, nil } else if TestContext.Provider == "aws" { return &v1.PersistentVolumeSource{ AWSElasticBlockStore: &v1.AWSElasticBlockStoreVolumeSource{ VolumeID: diskName, FSType:   "ext3", }, }, nil } else { return nil, fmt.Errorf("Provider not supported") } } func DeletePVSource(pvSource *v1.PersistentVolumeSource) error { if TestContext.Provider == "gce" || TestContext.Provider == "gke" { return DeletePDWithRetry(pvSource.GCEPersistentDisk.PDName) } else if TestContext.Provider == "aws" { return DeletePDWithRetry(pvSource.AWSElasticBlockStore.VolumeID) } else { return fmt.Errorf("Provider not supported") } } </ins>

Discussion:
For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
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
Change:
} } <ins> // doFixDeprecatedTaintKeyPass checks and replaces deprecated taint key with proper key name if needed. func (nc *Controller) doFixDeprecatedTaintKeyPass(node *v1.Node) error { taintsToAdd := []*v1.Taint{} taintsToDel := []*v1.Taint{} for _, taint := range node.Spec.Taints { if taint.Key == algorithm.DeprecatedTaintNodeNotReady { // delete old taint tDel := taint taintsToDel = append(taintsToDel, &tDel) // add right taint tAdd := taint tAdd.Key = algorithm.TaintNodeNotReady taintsToAdd = append(taintsToAdd, &tAdd) glog.Warningf("Detected deprecated taint key: %v on node: %v, will substitute it with %v", algorithm.DeprecatedTaintNodeNotReady, node.GetName(), algorithm.TaintNodeNotReady) break } } if len(taintsToAdd) == 0 && len(taintsToDel) == 0 { return nil } if !util.SwapNodeControllerTaint(nc.kubeClient, taintsToAdd, taintsToDel, node) { return fmt.Errorf("failed to swap taints of node %+v", node) } return nil } </ins> func (nc *Controller) doNoScheduleTaintingPass(node *v1.Node) error { // Map node's condition to Taints. taints := []v1.Taint{}

Discussion:
Almost all style strings use dashes, rather than javascript names. vs .
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Thanks for notification, a quick fix is submitted.
/cc
The PR here isn't merged yet. Can we make that happen please? We're still in alpha, so should be ok
Should I add the v1.8 milestone to this issue?
Hope so. We are pending in , need approve from
I opened with safe changes. "not-ready" change needs to be discussed more, as it's a breaking change. I believe it's best with fixing that to the time we'll be moving to beta, as we'll need to do another breaking change, i.e. remove 'alpha' from the key.
Aren't we doing this at the 11th hour? Is this going to hit 1.8?
Strings like this that are part of the core API should be part of a design doc that is formally reviewed by an API group. We need to find ways to catch this stuff earlier. We should also have an evolving API style guide that lists stuff like this. /cc
Thanks , let me make some summary: quick fix for 1.8 is , will be merged soon. final fix is , we are collaborating to reach a final solution and it's not target 1.8
Agree with Joe, can someone open a PR to that documents that taint names should follow the naming conventions for annotations?
Change:
// ListRoutes in the cloud environment. func (g *Cloud) ListRoutes(ctx context.Context, clusterName string) ([]*cloudprovider.Route, error) { <del> timeoutCtx, cancel := cloud.ContextWithCallTimeout() </del> <ins> timeoutCtx, cancel := context.WithTimeout(ctx, 1*time.Hour) </ins> defer cancel() mc := newRoutesMetricContext("list")

Discussion:
What happened: Ref , there are some GCE wrapper functions that don't properly respect the passed in context, e.g: We need to figure out a better way to handle this, but I'm hesitate to change it right away without enough thinking. File this issue for tracking purpose. cc
/sig cloud-provider /area provider/gcp
How about checking the deadline of the passed in ctx: If the timeout is longer than what cloud.ContextWithCallTimeout expects, create context with 1 hour timeout.
We should consider () as well as deadline. How about monitor user's timeout like this? cancel our context when timeout.
If the time period till ctx.Deadline() is shorter than 1 hour, there is no need to call cloud.ContextWithCallTimeout(). We can use ctx directly in that case.
Another option may be better:
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
Change:
description: "cpu manager add - container update error", regErr:      nil, updateErr:   fmt.Errorf("fake update error"), <del> expErr:      fmt.Errorf("fake update error"), </del> <ins> expErr:      nil, </ins> }, }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: There will always be extra UpdateContainerResources CRI call even when cpu set is empty. This is unneeded. What you expected to happen: Only call UpdateContainerResources when cpu set is set. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node
Change:
<ins> # See the OWNERS docs at https://go.k8s.io/owners reviewers: - dep-reviewers - pacoxu - gautierdelorme approvers: - dep-approvers - pacoxu </ins>

Discussion:
Add a file to track dependencies we want to remove or avoid picking back up. Examples: (as opposed to ) {analysis,spec,strfmt,validate} () and () () Add a presubmit that uses to do the following: if any items in the "unwanted but still present" list are no longer present and prompts to move them to the "absent and not allowed" list if any items in the "absent and not allowed" list are present and fails. Dependency updates often reintroduce problematic dependencies that were previously dropped. /area code-organization /cc
/sig architecture /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig architecture /triage accepted /help 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 may help with it. /assign I checked the code, there is already a logic to check forbidden dependencies. can draw a go mod graph
yeah, that was sort of ad-hoc, and doesn't do the ratcheting bit we want (record a dependency we have but don't want, once we no longer use it, require moving it to the forbidden list)
Change:
function verify-prereqs { for x in gcloud gcutil gsutil; do if [ "$(which $x)" == "" ]; then <del> echo "Can't find $x in PATH, please fix and retry." </del> <ins> echo "Can't find $x in PATH, please fix and retry." 1>&2 </ins> exit 1 fi done

Discussion:
I'm following the documentation on this doc: Everything works until this command: I get this error consistently from different VMs (a Debian and a CoreOS). Maybe I have to edit /etc/hosts to add the "external-ip" with the public IP of some server? Docs don't seem clear. Thanks, Riccardo
Its failing to look up your master correctly. You can try setting KUBERNETES_MASTER=http://<your IP hearBrendan On Sep 21, 2014 5:45 AM, "Riccardo Carlesso" wrote: