jiebi/CodeConvo huggingface dataset:
Change:
allVMs, rerr := ss.VirtualMachineScaleSetVMsClient.List(ctx, resourceGroup, scaleSetName, string(compute.InstanceView)) if rerr != nil { klog.Errorf("VirtualMachineScaleSetVMsClient.List failed: %v", rerr) <ins> if rerr.IsNotFound() { return nil, cloudprovider.InstanceNotFound } </ins> return nil, rerr.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:
package dockertools import ( <del> "k8s.io/kubernetes/pkg/api" </del> dockertypes "github.com/docker/engine-api/types" <ins> dockercontainer "github.com/docker/engine-api/types/container" "k8s.io/kubernetes/pkg/api" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" </ins> ) <ins> // These two functions are OS specific (for now at least) func updateHostConfig(hc *dockercontainer.HostConfig, opts *kubecontainer.RunContainerOptions) { } func DefaultMemorySwap() int64 { return -1 } </ins> func getContainerIP(container *dockertypes.ContainerJSON) string { return "" }

Discussion:
What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.
Change:
file: test/e2e/common/network/networking.go - testname: Networking, intra pod http, from node codename: '[sig-network] Networking Granular Checks: Pods should function for node-pod <del> communication: http [NodeConformance] [Conformance]' </del> <ins> communication: http [LinuxOnly] [NodeConformance] [Conformance]' </ins> description: Create a hostexec pod that is capable of curl to netcat commands. Create a test Pod that will act as a webserver front end exposing ports 8080 for tcp and 8081 for udp. The netserver service proxies are created on specified number

Discussion:
ci-kubernetes-e2e-capz-master-containerd-windows should function for node-pod communication: http [NodeConformance] should function for node-pod communication: udp [NodeConformance] PR merged on April 4th 2022 Discussed at sig-windows triage meeting as well as regular meeting: This test is passing for flannel overlay: and aks-engine: We plan temporary disable this on the CAPZ test suite while we diagnose what is missing. /sig windows /sig networking /cc
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are failing? should function for node-pod communication: udp [NodeConformance] ### Since when has it been failing? /sig networking 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
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 network Did some looking into this and the tests is not deploying a hostprocess pod for Windows: Following the test flow Creates test pods: Then the hostnetwork is set to true but the windows Hostprocess fields are not set:
This pod being tested has which seems to be causing issues with calico, if I remove that then it works (as the other tests that do pod-pod demonstrate). Once I switched this test to use a hostprocess this test works for on the same host when using Windows overlay. Overlay has this limitation that we have seen before: fail (according to the , it is not mandatory for kubelet to be able to access pods on a different node).
My thoughts are we should disable these two tests for 1.24 because they are not testing what they should be and it requires some tough changes to the framework to make it work as is. These tests also doesn't make sense for . A example of the changes need to make this partially work on l2bridge but not overlay:
Change:
selector := map[string]string{} selector["app"] = o.Name <ins> namespace := "" if o.EnforceNamespace { namespace = o.Namespace } </ins> service := corev1.Service{ ObjectMeta: metav1.ObjectMeta{ <del> Name:   o.Name, Labels: labels, </del> <ins> Name:      o.Name, Labels:    labels, Namespace: namespace, </ins> }, Spec: corev1.ServiceSpec{ <del> Type:         corev1.ServiceType(o.Type), </del> <ins> Type:         o.Type, </ins> Selector:     selector, Ports:        ports, ExternalName: o.ExternalName,

Discussion:
I'm writing a small bash script which generates some k8s resources in a namespace (other than ). When using to generate a service, the yaml which is generated does not include the defined namespace. I've also tried to move around the argument to the beginning (i.e. , but that doesn't work as well. Generated yaml should include the , when it's defined as an option. Kubernetes version (use ): Cloud provider or hardware configuration: n/a (not really important) OS (e.g: ): Kernel (e.g. ): Install tools: kubectl Network plugin and version (if this is a network-related bug): n/a Others: /sig cli
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 cli
/assign
Change:
} // Delete virtual disk <ins> vmDiskPath = removeClusterFromVDiskPath(vmDiskPath) </ins> task, err := virtualDiskManager.DeleteVirtualDisk(ctx, vmDiskPath, dc) if err != nil { return err

Discussion:
With version 1.4.7 I could use a datastore that is in a cluster as a vsphere volume as . When I upgraded to 1.6.0, this same exact path does not work and throws a error. I'm struggling to find what changed, but am guessing it's difference in how the datastore is being looked up in vcenter. Has anyone had luck with this?
We have verified creating pod using static PV and dynamic provisioning, both works fine with Can you post here? cc:
Did that include using a datastore that was in a datastore cluster? That seemed to be working before because the datastore previously (before 1.5) was read out of the global config, which supported datastore path with cluster name. But post 1.5 datastore is parsed from the entry, which if you include the path to the cluster it gets you past the datastore lookup, but then when you go to add the disk it fails because that is not valid to vCenter. It's kind of this weird mixed mode, because to look up the datastore you need the path including the cluster, but to create the file you need the path without the cluster. I presume the PV is working because they use the cloud config values? I was not using a PV but putting a volumePath directly in my deployment yaml. Should I be using a PV to do this? If the deployment is deleted and re-created how do I guarantee that my pod would get the same PV claim? That was why I did not go down that path originally. I'm pretty sure I have narrowed down where in the provider this is happening, but didn't see a good path to get it to work. I have, admittantly, not tried PV/PVCs yet, due to the concern raised above, but could try those to see. The pertinent part of the deployment yaml: The cloud config:
Just confirmed I have the same issue using a PV and PVC....
Here it needs it in format: (which it gets on line 791 by parsing . But here it needs it in true format, without the datastorecluster: Therefore if you do it gets you past line 796 but fails on 802. But if you do then you don't get past line 796.
Thanks for detailed look up. This is the commit which caused this regression. We will work on the fix.

cc:
Ah yes, I see that now. What is the lifecycle of a dynamic disk? Does that disk live on after the PVC is released? After the PV is deleted? It seems like I may just not fully be exercising the power of the volume plugins as well. I would still have the issue with existing volumes as they have data that I need to maintain, but would be interesting for new volumes to look into these more.
RECLAIMPOLICY for PV created using Dynamic Provisioning is Delete PV will get deleted if you delete PVC. Disk also gets deleted from datastore.
Change:
"context" "fmt" "strings" <ins> "time" </ins> "github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2018-10-01/compute" "github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2018-07-01/storage"

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 --What happened: A storageAccount API call blocks kubelet from becoming Ready when there isn't any outbound IP, 1. eventually (after 10mins), the kubelet registers again... there is a call to the ARM API done by which blocks for 10mins, before letting kubelet complete with its starting logic and making the node as details: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.5 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
// different from lastType) including all the rows in the object. It returns the current type // or an error, if any. func printRowsForHandlerEntry(output io.Writer, handler *handlerEntry, obj runtime.Object, options PrintOptions, includeHeaders bool) error { <ins> var results []reflect.Value if handler.printRows { args := []reflect.Value{reflect.ValueOf(obj), reflect.ValueOf(options)} results = handler.printFunc.Call(args) if !results[1].IsNil() { return results[1].Interface().(error) } } </ins> if includeHeaders { var headers []string for _, column := range handler.columnDefinitions {

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?: What happened: 1when error has occurwe should not print header 2 when i get ns use --all-namespaces, i get NAMESPACE column, we should return error: storageclass is not namespaced What you expected to happen: 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:
/assign
/sig cli
Change:
if len(missingPods) > 0 { if usageRatio < 1.0 { <del> // on a scale-down, treat missing pods as using 100% of the resource request </del> <ins> // on a scale-down, treat missing pods as using 100% (all) of the resource request // or the utilization target for targets higher than 100% fallbackUtilization := int64(max(100, targetUtilization)) </ins> for podName := range missingPods { <del> metrics[podName] = metricsclient.PodMetric{Value: requests[podName]} </del> <ins> metrics[podName] = metricsclient.PodMetric{Value: requests[podName] * fallbackUtilization / 100} </ins> } } else if usageRatio > 1.0 { // on a scale-up, treat missing pods as using 0% of the resource request

Discussion:
Change the fallback consumption from to when pod metrics are missing on a scale down. Background from : The fallback value of 100% is supposed to be a safe overestimate of the desired value to dampen the magnitude of a potential scale down. However, if a metric target is set to more than 100% then this fallback typically becomes an underestimate that amplifies a potential scale down. Note that a metric target of over 100% is a valid HPA configuration. We could choose a fallback of instead. However, any safety margin would be arbitrary and I think it's better to opt for simplicity vs. precision in this corner case.
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 autoscaling
/assign
/assign
Change:
addonmanager.kubernetes.io/mode: Reconcile kubernetes.io/name: "Elasticsearch" spec: <ins> clusterIP: None </ins> ports: <del> - port: 9200 protocol: TCP targetPort: db </del> <ins> - name: db port: 9200 protocol: TCP targetPort: 9200 - name: transport port: 9300 protocol: TCP targetPort: 9300 publishNotReadyAddresses: true </ins> selector: k8s-app: elasticsearch-logging <ins> sessionAffinity: None type: ClusterIP </ins>

Discussion:
What happened: I download fluentd-elasticsearch in addons. The following error occurs then I use "kubectl apply -f es- " Then, i find the elasticsearch-logging pod restart lots of time, and keep status with CrashLoopBackOff. [root ~]# kubectl logs -f elasticsearch-logging-0 -n kube-system export NODENAME=elasticsearch-logging-0 NODENAME=elasticsearch-logging-0 export NODEMASTER=true NODEMASTER=true export NODEDATA=true NODEDATA=true export HTTPPORT=9200 HTTPPORT=9200 export TRANSPORTPORT=9300 TRANSPORTPORT=9300 export MINIMUMMASTERNODES=2 MINIMUMMASTERNODES=2 chown -R elasticsearch:elasticsearch /data ./bin/elasticsearchloggingdiscovery I0902 14:25:06. 9 ] Kubernetes Elasticsearch logging discovery I0902 14:25:06. 9 ] Found [] I0902 14:25:16. 9 ] Found [] I0902 14:25:26. 9 ] Found [] I0902 14:25:36. 9 ] Found [] I0902 14:25:46. 9 ] Found [] I0902 14:25:56. 9 ] Found []
unclear whether the addon is up to date and supported at this point. /sig instrumentation
cc
/assign I will take a look this week.
I have the same problem k8s version:v1.18.8
same
I've pushed a change to the stateful set that should unblock people as there was a 1.18 compatibility problem. however, please make sure you are also creating the service via , the discovery program finds the other elasticsearch nodes via service registration.
please feel free to re-open this issue if the latest version doesn't work for you.
Why was this PR to v1.20?
probably because that is the next release. most people who use this addon do so from master. Do you need this packaged in some other way?
Change:
Memory: &statsapi.MemoryStats{ WorkingSetBytes: &workingSetBytes, }, <ins> VolumeStats: []statsapi.VolumeStats{ { FsStats: statsapi.FsStats{ UsedBytes: &workingSetBytes, }, Name: "local-volume", }, }, Containers: []statsapi.ContainerStats{ { Name: pod.Name, Logs: &statsapi.FsStats{ UsedBytes: &workingSetBytes, }, Rootfs: &statsapi.FsStats{UsedBytes: &workingSetBytes}, }, }, EphemeralStorage: &statsapi.FsStats{UsedBytes: &workingSetBytes}, </ins> } }

Discussion:
As I was reading the test code, I noticed that we are missing a pretty large chunk of logic around localStorageCapacityIsolation. This feature was GA in 1.25 so it would be ideal to have unit test coverage around this code. This code monitors whether or not there is a violation in temporary storage and if there is it would evict the pod. One should be able to intiailize the manager with of true and then write some test cases to verify this behavior. /help /sig node /good-first-issue /kind bug
/cc do you have any recollection why there weren't tests for this path?
I can help with this. can you assign me after jingxu replies to you?(for more context here)
that would be great !
you're welcome. do you have any context here that why didn't cover localStorageCapacityIsolation?
I don't recall a specific reason. The feature was implemented a while back.
/assign
Hey Are you still working. If not can I take this up?
hi, yes I'm still working on it
hii I am new to k8s , so i wanna know can I use windows os for it? if yes would you show me how to get nodes...
hi, the answer is yes you can use windows and I think if you need support you better open another issue and @ me there, as this issue is not for discuss how to run k8s on windows
/remove-kind bug /kind feature /triage accepted
I see and I am wondering if we have duplicated efforts here. did you end up testing this path in our above PR?
Hey, is someone working on this issue ? or let me know if someone need help
Happy to help with this. Do you still need help
hey, is this currently still unassigned
has a ready for approval. /remove-good-first-issue /remove-help
Change:
statusSize := oldPvc.Status.Capacity["storage"] if !apiequality.Semantic.DeepEqual(newPvcClone.Spec, oldPvcClone.Spec) { <del> specDiff := diff.ObjectDiff(newPvcClone.Spec, oldPvcClone.Spec) </del> <ins> specDiff := cmp.Diff(oldPvcClone.Spec, newPvcClone.Spec) </ins> allErrs = append(allErrs, field.Forbidden(field.NewPath("spec"), fmt.Sprintf("spec is immutable after creation except resources.requests for bound claimsn%v", specDiff))) } if newSize.Cmp(oldSize) < 0 {

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 --pod with nodeSeletor edit pod, delete the nodeSeletor field report error with: ! The errors message should displayed as: Because the nodeSeletor is been deleted with this edit. 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 api
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api 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
/sig api-machinery
/remove-sig api-machinery /sig apps
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle stale
/remove-lifecycle rotten
Change:
// client.authentication.k8s.io/v1beta1, then this field is optional and defaults // to "IfAvailable" when unset. Otherwise, this field is required. // +optional <del> InteractiveMode ExecInteractiveMode </del> <ins> InteractiveMode ExecInteractiveMode `json:"interactiveMode,omitempty"` </ins> // StdinUnavailable indicates whether the exec authenticator can pass standard // input through to this exec plugin. For example, a higher level entity might be using

Discussion:
yaml.Marshal a kubeconfig, as done in the example tests here LocationOfOrigin is not seen in output, as comment says "never serialized." Click "run example" doesn't suffer from this as it does some conversion <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
/assign /triage accepted
is what's known as internal type. It is not intended to be serialized by code. The serialization version is in and does not have this field. I could get behind removing all json tags from the internal version, but I wouldn't refine tags that shouldn't be used.