jiebi/CodeConvo huggingface dataset:
Change:
} // AttachDisk attaches a vhd to vm. The vhd must exist, can be identified by diskName, diskURI. <del> func (c *controllerCommon) AttachDisk(isManagedDisk bool, diskName, diskURI string, nodeName types.NodeName, cachingMode compute.CachingTypes) error { </del> <ins> // return (lun, error) func (c *controllerCommon) AttachDisk(isManagedDisk bool, diskName, diskURI string, nodeName types.NodeName, cachingMode compute.CachingTypes) (int32, error) { </ins> vmset, err := c.getNodeVMSet(nodeName) if err != nil { <del> return err </del> <ins> return -1, err </ins> } instanceid, err := c.cloud.InstanceID(context.TODO(), nodeName) if err != nil { klog.Warningf("failed to get azure instance id (%v)", err) <del> return fmt.Errorf("failed to get azure instance id for node %q (%v)", nodeName, err) </del> <ins> return -1, fmt.Errorf("failed to get azure instance id for node %q (%v)", nodeName, err) </ins> } diskOpMutex.LockKey(instanceid)

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: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig azure /assign
Change:
cert  *x509.Certificate } <del> func (cr fakecertificateReadWriter) Exists() bool { return cr.exist </del> <ins> func (cr fakecertificateReadWriter) Exists() (bool, error) { return cr.exist, nil </ins> } func (cr fakecertificateReadWriter) Read() (*x509.Certificate, error) {

Discussion:
When the command is run with superuser privileges, it prints the requested information. Print a warning that files could not be read due to insufficient permission, or that information was missing (e.g., when the /etc/kubernetes directory is not initialized). When the directory is readable, it works as expected: where OS and kubeadm version detail was: Issue the command as a normal user when the directory /etc/kubernetes/pki exists but not readable. No response <details</details<detailsBare metal </details<details</details<detailsapt-get install kubeadm (source repo: ) </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 cluster-lifecycle
Change:
"-c", cmd, } <del> return framework.RunKubectl(args...) </del> <ins> containerName := pod.Spec.Containers[0].Name var err error result.Stdout, result.Stderr, err = h.Framework.ExecWithOptions(framework.ExecOptions{ Command:            args, Namespace:          pod.Namespace, PodName:            pod.Name, ContainerName:      containerName, Stdin:              nil, CaptureStdout:      true, CaptureStderr:      true, PreserveWhitespace: true, }) return result, err } // IssueCommandWithResult issues command on the given node and returns stdout as // result. It returns error if there are some issues executing the command or // the command exits non-zero. func (h *hostExecutor) IssueCommandWithResult(cmd string, node *v1.Node) (string, error) { result, err := h.exec(cmd, node) return result.Stdout, err </ins> } // IssueCommand works like IssueCommandWithResult, but discards result.

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : separate stdout and stderr command exit code: remove kubectl dependency: Why is this needed: to replace
/assign
/sig storage HostExec was originally written for local PV tests. If we want to replace SSH in e2e, some features must be supported and I’d like to help on this. cc
Change:
"crypto/tls" "errors" "fmt" <del> "io/ioutil" </del> "math/rand" "net" "net/http"

Discussion:
Forked from To make debian-based node compatible with docker 1.11.X, I updated both /proc/sys/kernel/keys/rootmaxkey and /proc/sys/kernel/keys/rootmaxbytes. Also other kubernetes components do the similar thing. For example, kube_proxy: We should clean up those configurations into one common place.
cc/
Is this looking for an owner? It seems the ask is to generalize these types of settings in a module.
Yeah. We update quite a few kernel settings in kubelet itself. We should move the ones mentioned in this issue to kubelet if it is applicable to other distros too. want to own this?
Sure, I'll start poking.
Test results so far for a few distributions' default settings Operating SystemValue --- --- Debian Jessie 8.7.5200 --- --- --- Ubuntu 14. --- --- --- Ubuntu 16. --- --- --- CentOS --- --- --- Fedora --- --- --- Redhat Atomic --- --- --- CoreOS stable1000000 --- --- undefined --- undefined
Change:
} klog.Errorf("error: az.EnsureHostInPool(%s), az.VMSet.GetPrimaryInterface.Get(%s, %s), err=%v", nodeName, vmName, vmSetName, err) <del> return "", "", "", nil, err </del> <ins> if err != cloudprovider.InstanceNotFound { return "", "", "", nil, err } </ins> } if nic.ProvisioningState != nil && *nic.ProvisioningState == nicFailedState {

Discussion:
When upgrade cluster to kubernetes 1.20.15 on Azure platform, I still hit "instance not found" error when ensureHostInPool, and this leads to one of the backend pool members missing since then, users have to add the member back manually. Below is the error: The Detected change in list of current cluster nodes should be in size of 90, but actually it only has 89 nodes here. The symptom matches issue and the But the fix may be incomplete. I expected the "instance not found" error will not affect backend pool members management, and it's ignored somewhere in either or (1.20.15) By upgrading the cluster and trigger the VM recreation, and this may not be easy to reproduce, but it indeed happens several times in our environment <details20.15 </details<detailslegacy Azure cloud provider </details
Hi as you previously worked on the similar issue, could you please kindly help take a look? Thank you in advance!
/sig cloud-provider /area provider/azure /priority critical-urgent
20.x is not a supported version. Could you upgrade to latest supported version?
Hi thank you for reply! Do you mean that this could be already fixed in latest version? I'm not sure if my understanding is correct, but if the issue exists in 1.20.x, even latest version does not ignore this error in the specific place.
yes, please upgrade the version to 1.22 or above with out-of-tree cloud provider
Hi sorry, I don't mean AKS by Azure platform, in fact this is a VMware product built upon Azure, is it possible to port the fix to in-tree cloud provider? That would be great if it's doable, if not, or could you please help point out the fix, maybe we could rase a PR for the in-tree cloud provider. Thank you!
We're still on in-tree cloud provider even if it's upgraded to 1.22.
The error we saw is thrown in this code it appears in out-of-tree code, this still could lead to the issue.
/remove-priority critical-urgent please don't set priorities, those are meant to be used by the community members that triage the issue
Sorry, I copied from previous issue.
are you using VMSS, VMAS or standalone VM?
this is our config, sorry, how do I know which kind of it is?

primaryAvailabilitySetName means the cluster is using VMAS. Per the codes , the issue probably still exists. could you help for the fix? /assign
Thank you for confirming! That's what I'm worried about.
/triage accepted
Change:
func TestUploadConfiguration(t *testing.T) { tests := []struct { name           string <del> errOnCreate    error errOnUpdate    error </del> updateExisting bool <del> errExpected    bool </del> verifyResult   bool }{ {

Discussion:
What happened: Running fails consistently with timeout errors What you expected to happen: Unit tests should complete without any errors. If this was a configuration problem (e.g. unsupported go version), then I should see a meaningful error rather than just a timeout error. How to reproduce it (as minimally and precisely as possible): Run Anything else we need to know?: This issue has been present in my system for months. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 20.04 LTS (Focal Fossa) Kernel (e.g. ): Linux desktop 5.4.0-37-generic -Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others: go version go1.13.12 linux/amd64 (snap)
/sig testing
/assign
Issues targeted at the specific problematic packages and responsible SIGs will be more effective in getting this addressed
/remove-sig testing Unless we expect some broad testing change (like reconfiguring go test) this isn't SIG testing. This is SIG storage, node, and cluster lifecycle
/sig node /sig cluster-lifecycle /sig storage tagged the right sigs, though per-package issues are far more likely to drive getting this fixed
fix for cmd/kubeadm/app/phases/uploadconfig:
I'm going to open two more issues for the other two packages and work on them
sounds good, in that case please close this one.
New issues for reconciler and csi packages: ,
Closing. This problem has come up in the past, the solution is to just increase the timeout. I missed this the first time I read the doc.
Change:
}) }) <del> ginkgo.Context("when querying /metrics", func() { </del> <ins> ginkgo.Context("when querying /metrics [NodeConformance]", func() { </ins> ginkgo.BeforeEach(func(ctx context.Context) { // ensure APIs have been called at least once endpoint, err := util.LocalEndpoint(defaultPodResourcesPath, podresources.Socket)

Discussion:
We have already quite a few podresources-related e2e tests. We should promote some among the most stable subset of them as NodeConformance. This is especially useful considering the plans to move . According to testgrid some possible candidates are: [sig-node] POD Resources [Serial] [Feature:PodResources][NodeFeature:PodResources] when querying /metrics should report the values for the podresources metrics [sig-node] POD Resources [Serial] [Feature:PodResources][NodeFeature:PodResources] without SRIOV devices in the system with CPU manager None policy should return the expected responses As part of the we want to enable the endpoint also on windows, where . Windows lanes run tests. We already have some podresources e2e tests, and promoting them to will enables us to both ensuring the code keeps working on windows, where it was exercised way less, and increase the stability of the codebase.
/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
Thanks for the quick review! I'll keep an eye on the lanes and prep the trivial revert in cause of any issue.
Change:
### Create POD valid-pod in specific namespace # Pre-condition: no POD is running <del> kube::test::get_object_assert 'pods --namespace=other' '{{range.items}}{{.id}}:{{end}}' '' </del> <ins> kube::test::get_object_assert 'pods --namespace=other' "{{range.items}}{{.$id_field}}:{{end}}" '' </ins> # Command kubectl create "${kube_flags[@]}" --namespace=other -f examples/limitrange/valid-pod.json # Post-condition: valid-pod POD is running <del> kube::test::get_object_assert 'pods --namespace=other' '{{range.items}}{{.id}}:{{end}}' 'valid-pod:' </del> <ins> kube::test::get_object_assert 'pods --namespace=other' "{{range.items}}{{.$id_field}}:{{end}}" 'valid-pod:' </ins> ### Delete POD valid-pod in specific namespace # Pre-condition: valid-pod POD is running <del> kube::test::get_object_assert 'pods --namespace=other' '{{range.items}}{{.id}}:{{end}}' 'valid-pod:' </del> <ins> kube::test::get_object_assert 'pods --namespace=other' "{{range.items}}{{.$id_field}}:{{end}}" 'valid-pod:' </ins> # Command kubectl delete "${kube_flags[@]}" pod --namespace=other valid-pod # Post-condition: no POD is running <del> kube::test::get_object_assert 'pods --namespace=other' '{{range.items}}{{.id}}:{{end}}' '' </del> <ins> kube::test::get_object_assert 'pods --namespace=other' "{{range.items}}{{.$id_field}}:{{end}}" '' </ins> ############

Discussion:
This works: Are we using /var/run for testing?
Curiously travis shows a similar error message regarding /var/run/kubernetes, but it isn't failing: I suspect the /var/run/kubernetes issue is not what's causing the failure here.
However, I am able to reproduce the failure on my machine. I note that in your case, the fatal error says For me, it says The ip addresses showing through here (which appear to be in the GCE space?) are worrying.
It seems it still failing. I've run it locally and it failed with the following error: The aforementioned line: I think it is expected that there are some pods started by k8s (e.g. elasticsearch). Does it mean the test has a bug?
Strangely the same code () passes tests on travis (https://travis-)
I think you're reading it backwards. The test is expecting no pods to be started, but finding the k8s add-on pods, which is normal if it were running against a normal master. In Travis, it's a synthetic environment with no add-ons. This should be assigned to whoever the checks (on mobile.. I know I merged the PR but don't remember who :)). We need to exclude the add-ons (perhaps by finally getting around to putting them in a separate namespace).
the assertions, so CC'ing for comment.
I looked into this with and it seems that test- may fail locally depending on the kubeconfig. Some commands are using defaults for kubectl and thus sometimes they contact another cluster. I'll send a PR to fix this.
Change:
Timeout:   svc.Timeout, } <del> // Test Flags >= 0x2, valid Flags ranges [0x2, 0x3] </del> <ins> // Test FlagHashed (0x2). A valid flag must include FlagHashed </ins> if svc.Flags&FlagHashed == 0 { <del> return nil, fmt.Errorf("Flags of successfully created IPVS service should be >= %d since every service is hashed into the service table", FlagHashed) </del> <ins> return nil, fmt.Errorf("Flags of successfully created IPVS service should enable the flag (%x) since every service is hashed into the service table", FlagHashed) </ins> } // Sub Flags to 0x2 // 011 -> 001, 010 -> 000

Discussion:
The current support of the load distribution method and in kube-proxy ipvs mode only performs hashing of source IP address to select endpoints. As a result, all connections from a single client (i.e. from a particular source IP) are always forwarded to only one endpoint matching with the hash value of this source IP. If the client opens a vast majority of connections to the k8s cluster, it will result in traffic imbalance as only one endpoint located on one node handles the connections while the remaining endpoints/nodes are idle. Here is an example of the problem when using method for kube-proxy Deploy a service with 4 endpoints located on 4 nodes.Open 200 connections from a client to node IP of any node (e.g. telnet 192.168.1.1 ). All connections receive replies from only one single endpoint.The distribution printout also shows that all connections are forwarded to the endpoint (e.g. 1.0.4.2:5001 in this example)Similar issue is seen with method Connections from a client should be evenly distributed to all endpoints like to avoid unbalanced load distribution between cluster nodes and endpoints. This can be easily done by enabling the source port hash flag that IPVS supports for the methods which performs hashing on both source IP and source port when selecting the target endpoint.
/sig network /area kube-proxy /area ipvs
This issue was raised based on the discussion of the issue
triage/accepted /assign
/triage/accepted
/triage accepted (damn it!)
Change:
# See the License for the specific language governing permissions and # limitations under the License. <del> .PHONY: all push push-legacy container clean orphan </del> <ins> .PHONY: all push container clean orphan all-push push-manifest include ../../hack/make-rules/Makefile.manifest </ins> REGISTRY ?= gcr.io/google_containers <del> IMAGE = $(REGISTRY)/pause-$(ARCH) LEGACY_AMD64_IMAGE = $(REGISTRY)/pause </del> <ins> IMAGE = $(REGISTRY)/pause IMAGE_WITH_ARCH = $(IMAGE)-$(ARCH) </ins> TAG = 3.1 REV = $(shell git describe --contains --always --match='v*')

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 feature This issue if for tracking the work related to pushing manifest list for kubernetes images(infra and test) List of images for which manifest need to be created: - [x] kubernetes to use manifest pause image - [x] dns - - - - - [ ] dashboard [x] Manifest images for k8s release images -
/assign
/cc
/sig cluster-lifecycle
/sig testing
/area test-infra /sig release
/reopen
I'd add dashboard to this as well, based off the issue at
can you provide a status update on this issue? I'd really want this fully working in v1.10... :)
I've created one more PR for pushing manifest for few more images, reference - I'll try my best to push into v1.10 release
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
/remove-lifecycle stale
/remove-lifecycle rotten
A problem related to manifests and was addressed here:
An update of this issue would be welcomed to track the status of all affected images, since I think at least some of the linked issues have progressed.
/sig testing
all the k8s core images are now fat manifest, hence closing this task. Will create a separate task for creating manifest for ecosystem images(e.g dashboard, metric-server etc...)
did you have a issue open tracking other images? I noticed today that kube-addon-manager (cluster/addons/addon-manager) is multi-arch but not using a manifest list yet.
Change:
} cfg.Profiles = completedProfiles <del> if len(fileName) > 0 { // Since the default component config lists all the default plugins as enabled // without disabling them, we must explicitly disable all the plugins for each // extension point using the "*" expression to ensure that the generated config // file is usable disabledPlugins := []config.Plugin{{Name: "*"}} for i := range cfg.Profiles { if cfg.Profiles[i].Plugins == nil { continue } cfg.Profiles[i].Plugins.QueueSort.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreFilter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Filter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PostFilter.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreScore.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Score.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Reserve.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Permit.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PreBind.Disabled = disabledPlugins cfg.Profiles[i].Plugins.Bind.Disabled = disabledPlugins cfg.Profiles[i].Plugins.PostBind.Disabled = disabledPlugins } } </del> buf, err := encodeConfig(cfg) if err != nil { return err

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 --Recent commit: import an issue when multiple custom plugin configured in scheduler config file, and those plugins are default plugins too. It was manipulating slice with index, but the slice is updated while index is not, which will cause the index out of range, see the exceptions listed below, config file should be handled properly without such exception override multiple default plugin in scheduler's config file. Kubernetes version (use ): latest (1.22) Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign
/sig scheduling /triage accepted
Change:
klog.V(4).InfoS("FindExpandablePluginBySpec -> returning noopExpandableVolumePluginInstance", "specName", spec.Name()) return &noopExpandableVolumePluginInstance{spec}, nil } <ins> if errors.Is(err, ErrNoPluiginMatched) { return nil, nil } </ins> klog.V(4).InfoS("FindExpandablePluginBySpec -> err", "specName", spec.Name(), "err", err) return nil, err }

Discussion:
In the events , the PVC has been successfully resized, but a warning-level log is still printed. And by checking the logs of kube-controller-manager, can see the following output. Do not print events with warning level. To expand a a CSI PVC, and then use "kubectl describe pvc" to view its events. (I am using xsky CSI to expand pvc, but based on my understanding of Kubernetes code, this issue can occur with any CSI.) ! ! Based on Kubernetes v1.27.3, I some logs in the func located in . These logs printed all the plugins before expansion, and I noticed that was not among them. In my understanding, it is normal for CSI to be absent from the plugins here because CSI expansion is scheduled through external-resizer instead of kube-controller-manager. Therefore, there should not be any warning-level logs printed here either. v1.27.3 (In version 1.18, the issue can also be reproduced) <details</detailsLinux debian-hk 5.10.0-23-amd64 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux kind v0.20.0 <details</details<details</details
/sig storage
We can change the ExternalExpanding event from Warning to Info. are you interested in making this change?
/triage accepted
Yes, I will submit the pull request in the next few days.
Hi Have you submitted the PR? I have a bugfix branch tested on v1.29.1. I would like to cherry-pick it to master if this is not fixed yet or not started.
You can go do it. Thank you!
Change:
ALREADY_UP=${1:-0} LEAVE_UP=${2:-0} <del> # Exit on error set -e </del> HAVE_JQ=$(which jq) if [[ -z ${HAVE_JQ} ]]; then echo "Please install jq, e.g.: 'sudo apt-get install jq' or, "

Discussion:
It shouldn't: But my shell-fu is weak, maybe there's something wrong with that?
I think it's missing some quotes. I'll make a PR.