jiebi/CodeConvo huggingface dataset:
Code change:
EXPOSE 2379 2380 4001 7001 <ins> WORKDIR C:/usr/local/bin </ins> COPY etcd* etcdctl* /usr/local/bin/ COPY migrate-if-needed.bat /usr/local/bin/ COPY migrate /usr/local/bin/migrate.exe

Related discussion:
text: build only 2 runs are available. ERROR: () build -dd5a-468e-9a7a- completed with status "FAILURE" [33m1 warning found (use --debug to expand): [0m - InvalidDefaultArgInFrom: Default value for ARG ${RUNNERIMAGE} results in empty or invalid base image name (line 16) Dockerfile.windows:22 20 | COPY etcd etcdctl /usr/local/bin/ 21 | COPY migrate-if- /usr/local/bin/ 22 | COPY migrate 23 | 24 | # NOTE(claudiub): docker buildx sets the PATH env variable to a Linux-like PATH, ERROR: failed to solve: mkdir /var/lib/buildkit/runc-overlayfs/cachemounts/buildkit3627953617/usr/local/bin: not a directory make[1]: Leaving directory '/workspace/cluster/images/etcd' make[1]: [Makefile:132: build] Error 1 make: [Makefile:217: sub-push-image-windows-amd64-1809] Error 2 ERROR ERROR: build step 0 "" failed: step exited with non-zero status: 2
2024/07/25 02:39:53 Failed to run some build jobs: [error running [gcloud builds submit --verbosity info --config The etcd 3.5.15 post CI failed to build the image. needs to promote the image: This is post submit CI for /sig release etcd
/cc
can you please try this?
cc Folks, We could use your help fixing the etcd image for windows!
/triage accepted /priority important-soon
actually passed in
Code change:
}{ { expected: api.VolumeMount{ <del> Name:      "pki", </del> <ins> Name:      "k8s", </ins> MountPath: "/etc/kubernetes/", ReadOnly:  true, },

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--What keywords did you search in Kubernetes issues before filing this one? controller /etc/ssl/certs kubeadm /etc/ssl/certs Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): 5 custom built master I also use a custom built hyperkube image instead of the single app images for apiserver, controller, ... Environment: Cloud provider or hardware configuration: azure OS (e.g. from /etc/os-release): CentOS 7.2 Kernel (e.g. ): Linux ma-kub8ms0 3.10.0-327.36.3.el7.x8664 SMP Mon Oct 24 16:09:20 UTC 2016 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm Others: deployed with Azure RM template and ansible What happened: controller is not able to do https, including calls to the Azure RM API What you expected to happen: https should work as usual How to reproduce it (as minimally and precisely as possible): Use kubeadm to install kubernetes on CentOS exec into the controller and try "curl " Anything else do we need to know: It looks like caused this issue. On CentOS, I see these files on the host OS: I suspect the symlinks to /etc/pki/... being the problem here, as they are not available inside the hyperkube Debian image. I also tried to verify this with It seems to not be based on Debian and thus gives a different error: I see 2 possible solutions: of host mounting /etc/ssl/certs into the controller pod, the ca certificates could be installed into the image.
Code change:
}{ { expected: api.VolumeMount{ <del> Name:      "pki", </del> <ins> Name:      "k8s", </ins> MountPath: "/etc/kubernetes/", ReadOnly:  true, },

Related discussion:
text: This is already done for hyperkube and would work out of the box when the host mount would be omitted. could try to figure out if /etc/pki should also be host mounted and add this to the controller manifest if required. I'd be happy to provide a fix by myself, I just need to know which solution you would prefer.
Same problem seems to apply to the apiserver. Not sure however if it actually does https calls.
implements solution 2.
This issue was moved to kubernetes/kubeadm
Code change:
fifo := cache.NewDeltaFIFO(cache.MetaNamespaceKeyFunc, nil, downstream) // Let's do threadsafe output to get predictable test results. <del> outputSetLock := sync.Mutex{} outputSet := util.StringSet{} </del> <ins> deletionCounter := make(chan string, 1000) </ins> cfg := &framework.Config{ Queue:            fifo,

Related discussion:
text: From shippable, I noticed there are several failed cases, for example, E0413 17:34:38. ] watch of *api.Pod ended with: Stop requested --- FAIL: Example (0.61s) got: want: a-hello b-controller c-framework FAIL coverage: 85.9% of statements FAIL 7.652s cc/
another example:
ah-- this is a different thing. I will fix this, too.
I'm seeing this from an unrelated change
Yeah I think that's the one I expected to see.
Code change:
} output, err := json.Marshal(agg) require.NoError(t, err) <del> // Content-type is "aggregated" discovery format. w.Header().Set("Content-Type", AcceptV2Beta1) </del> <ins> // Content-type is "aggregated" discovery format. Add extra parameter // to ensure we are resilient to these extra parameters. w.Header().Set("Content-Type", AcceptV2Beta1+"; charset=utf-8") </ins> w.WriteHeader(http.StatusOK) w.Write(output) }))

Related discussion:
text: We are using (and ) to interact with Kubernetes clusters behind a couple of proxy layers. One of these proxies completes the headers to include character encoding details. This was working fine until recently, when client-go/kubectl have started to fail when interacting with the discovery API. It seems that a recent change has made kubectl more restrictive of the content-type that it expects. I suspect that it is related to this commit: For example, this is an error from a kubectl command: We can of course try to fix it on our end, removing that charset information. However, it is a valid content-type and the way kubectl is handling the content-type there seems like it is relying on implementation details of kube-apiserver (that it does not add metadata to the content-type). I propose to fix this issue in , by properly parsing and handling the content-type.
cc /kind regression /kind bug /sig api-machinery /priority important-soon looks like the switch statement in downloadLegacy() needs to be more tolerant of the variety of content-types it can get from a server (including text/plain or no content-type if old servers could have returned that...)
/transfer kubernetes/kubernetes
Something went wrong or the destination repo kubernetes/kubernetes/kubernetes does not exist. <detailsIn response to : /transfer kubernetes/kubernetes 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
/transfer kubernetes
Yep, the string comparison for the content-type is flimsy, let's address that. Thanks for the report!
/assign
/triage accepted
/cc
The fix is being cherry-picked back to: : :
Code change:
If you have questions or want to start contributing please reach out.  We don't bite! <del> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers).  We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </del> <ins> The Kubernetes team is hanging out on IRC on the [#google-containers channel on freenode.net](http://webchat.freenode.net/?channels=google-containers). This client may be overloaded from time to time. If this happens you can use any [IRC client out there](http://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients) to talk to us. We also have the [google-containers Google Groups mailing list](https://groups.google.com/forum/#!forum/google-containers) for questions and discussion as well as the [kubernetes-announce mailing list](https://groups.google.com/forum/#!forum/kubernetes-announce) for important announcements (low-traffic, no chatter). </ins> If you are a company and are looking for a more formal engagement with Google around Kubernetes and containers at Google as a whole, please fill out [this form](https://docs.google.com/a/google.com/forms/d/1_RfwC8LZU4CKe4vKq32x5xpEJI5QZ-j0ShGmZVv9cm4/viewform) and we'll be in touch.

Related discussion:
text: Thank you Both are OK, I currently use java -xmx instead.I will update in the next version. Preferably v1.21, v1.22 version I will upgrade later.
I've opened as well :)
/remove-triage needs-information /triage accepted /close as this is being tracked as a CRI-O bug
Closing this issue. <detailsIn response to : /remove-triage needs-information /triage accepted 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
Code change:
var notMnt bool var err error if extensiveMountPointCheck { <del> notMnt, err = IsNotMountPoint(mounter, mountPath) </del> <ins> notMnt, err = mounter.IsNotMountPoint(mountPath) </ins> } else { notMnt, err = mounter.IsLikelyNotMountPoint(mountPath) }

Related discussion:
text: <!-- 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!--What happened: There's , and . The former is used by local and nfs volume plugins, while the latter is used by , which is also used by local and nfs volume plugins. What you expected to happen: Can we consolidate these? This is really confusing and could easily be the source of bugs. <!-- DO NOT EDIT BELOW THIS LINE --/kind cleanup
cc
/assign I'd like to clean up code.
Code change:
import ( "fmt" "os" <ins> "sort" </ins> "strings" "github.com/spf13/cobra"

Related discussion:
text: Similar to issue , building kubernetes1.23 resulted in 1 variation: builds should be fully determined by inputs on openSUSE or Debian, This bug was found while working on . <details23.0 </details<details</details<details</details<details</details<details</details<details</details
/sig release /area build-release
/assign
/sig cli
/triage accepted /assign
Code change:
if err != nil { framework.Logf("Failed to delete adapter deployment file: %s", err) } <del> cleanupClusterAdminBinding(namespace) </del> <ins> cleanupClusterAdminBinding() </ins> } <del> func cleanupClusterAdminBinding(namespace string) { stat, err := framework.RunKubectl(namespace, "delete", "clusterrolebinding", ClusterAdminBinding) </del> <ins> func cleanupClusterAdminBinding() { stat, err := framework.RunKubectl("", "delete", "clusterrolebinding", ClusterAdminBinding) </ins> framework.Logf(stat) if err != nil { framework.Logf("Failed to delete cluster admin binding: %s", err)

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign
Code change:
}, }, SchemaProps: spec.SchemaProps{ <del> Description: "List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated.", </del> <ins> Description: "List of ports to expose from the container. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Modifying this array with strategic merge patch may corrupt the data. For more information See https://github.com/kubernetes/kubernetes/issues/108255. Cannot be updated.", </ins> Type:        []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{

Related discussion:
text: The comments in says that : However there are several cases where this is false : When using a Service with a targetPort that references a name in the ports arrays of the pod. Some software (ab)uses this API to get which ports are used (See Although unfixable, my goal is to fix the documentation so other people don't have the same problem). The Azure Load Balancer implementation does this for instance. Some other network/security software might use this information. Also, is it possible to document/reference the above issue in the comment ? Since it is described as informational I expected for the network to work without this information. But it's definitely not the case. Not needed since it's mostly a doc issue. I'm interested in contributing this patch but would like some feedbacks before doing it. :) <details</details<details</details<details</details<details</details<details</details<details</details
/sig network
/triage accepted -- thoughts? I believe the doc are due for a refresh.
I'd take this one. /assign
I didn't see that you wanted to do this patch, I am very sorry and now I unassign it. /unassign
No worries But I'm still not sure where / what to add. Should I only fix the part saying it is only informational ? Is there anything else ? (cc
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]:
/remove-lifecycle stale
Code change:
network_mode: openvswitch networkInterfaceName: eth1 etcd_servers: $MASTER_IP <ins> api_servers: $MASTER_IP </ins> cloud: vagrant cloud_provider: vagrant roles:

Related discussion:
text: is sent as a fix. cc It's a test failure reported by the publishing robot.
The line it fails at:
It looks like a vendor copy vs gopath copy issue.
One possible fix is removing from the vendor/ directory. I'm testing locally.
Confirmed removing from the vendor/ directory fixed the test in robot.
We need to add the "issue filer" feature to the publishing robot, we can't rely on to report robot issues everytime :P I'm just not sure how long the publishing robot will be needed (i.e., when we will get rid of the staging/ directory) so not sure whether we should invest more time on the robot.