jiebi/CodeConvo huggingface dataset:
Code change:
// according to the corresponding EndpointSlice addressType field. Consumers // must handle different types of addresses in the context of their own // capabilities. This must contain at least one address but no more than <del> // 100. </del> <ins> // 100. These are all assumed to be fungible and clients may choose to only // use the first element. Refer to: https://issue.k8s.io/106267 </ins> // +listType=set repeated string addresses = 1;

Related discussion:
text: On Wed, Nov 24, 2021, 5:45 PM Cyclinder
so we should change the API doc? Or It's just that documenting it will only use the first address in the , like you said above
I'd like some of the others to comment, but it's this a US holiday, so it might be a few days..
So maybe we should just declare that the array is essentially a bug, and only the first address is used? Maybe something should warn if you ever set additional addresses? (FTR, the context that I noticed this in was that I was adding unit tests, and was creating EndpointSlices with a single Endpoint and multiple Addresses, which doesn't work; you need multiple Endpoints with a single Address each.)
I think the simplest and most compat approach is to say "these are all assumed to be fungible and clients may choose to only use the first element". Thoughts?
I think the simplest and most compat approach is to say "these are all assumed to be fungible and clients may choose to only use the first element". Big +1 to that approach. I don't think it's necessarily invalid to set multiple addresses here, there may actually be some use cases for it, but adding this kind of statement should help clear things up significantly.
hmm as we push for multi homed pod this will make a lot of sense. There might also be a chance for community to provide a drop-in replacement for proxy that does much more than we do now. I think we should update the docs and don't modify anything for now.
Note that this API doesn't include per-IP metadata, so a multi-homed pod would be challenging with this mechanic. I think it's maybe time to reconsider multi-net more holistically. On Mon, Dec 13, 2021, 10:24 AM Khaled Henidak (Kal) <
:thinking:
If they're fungible, then "clients may choose to use only one of the elements" (or "only a subset"?). No reason to call out the first one specifically.
That's fair On Tue, Dec 14, 2021, 6:09 AM Dan Winship
I would like to add to this issue that it would makes sense to have kube-proxy reduce the subset of endpoints in the endpointslice based on the label of the node and the & attributes of the endpoint.
Code change:
// according to the corresponding EndpointSlice addressType field. Consumers // must handle different types of addresses in the context of their own // capabilities. This must contain at least one address but no more than <del> // 100. </del> <ins> // 100. These are all assumed to be fungible and clients may choose to only // use the first element. Refer to: https://issue.k8s.io/106267 </ins> // +listType=set repeated string addresses = 1;

Related discussion:
text: Taking only into consideration the first endpoint which is in the same zone of the node or has no zone dependency and is ready for serving. & Would it make sense to reopen this issue?
I don't follow entirely what you are suggesting, can you elaborate?
kube-proxy should understand which zone a node is in and prefer endpoints in the same zone.
but that is unrelated to this issue, topology is considered See KEPs related, topology-aware-routing was replaced by topology-aware-hints
thank you for clarifying. It seems ambiguous to me to have a zone attribute and a hint attribute. I fail to implement the hinting on a service in v1.23.8, but this is urelated to this issue.
heh, don't worry, this topic is complex and we went through different solutions, you have more historical context on the KEPs I linked above and this thread in the mailing list
Code change:
glog.Errorf("Failed to create directory %q: %v", ContainerLogsDir, err) } } <del> // Start the plugin watcher if err := kl.pluginWatcher.Start(); err != nil { return fmt.Errorf("failed to start Plugin Watcher. err: %v", err) </del> <ins> if kl.enablePluginsWatcher { // Start the plugin watcher if err := kl.pluginWatcher.Start(); err != nil { return fmt.Errorf("failed to start Plugin Watcher. err: %v", err) } </ins> } // Start the image manager.

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: PR introduced a new kubelet plugin registration mechanism. It is not flag gated. What you expected to happen: Since this feature is alpha, it should be flag gated and disabled by default (opt-in). 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: CC
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code slush, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 3 days during code slush. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
Expect(len(endPod.Status.InitContainerStatuses)).To(Equal(2)) }) <del> It("should not start app containers and fail the pod if init containers fail on a RestartNever pod", func() { </del> <ins> /* Release: v1.12 Testname: init-container-fails-stops-app-restartnever-pod Description: Ensure that app container is not started when atleast one InitContainer fails to start and Pod has restart policy as RestartNever. */ framework.ConformanceIt("should not start app containers and fail the pod if init containers fail on a RestartNever pod", func() { </ins> By("creating the pod") name := "pod-init-" + string(uuid.NewUUID()) value := strconv.Itoa(time.Now().Nanosecond())

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Evaluating e2e tests based on available options which are covering important aspects with user scenarios and eligible to promote for conformance. What you expected to happen: These 4 e2e tests evaluate different and based on . [NodeConformance] should invoke init containers on a RestartNever pod [NodeConformance] should invoke init containers on a RestartAlways pod [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod Anything else we need to know?: comment, Are these tests good to promote for conformance or do we need to look on other aspects as well ? are observed api endpoint hits during tests execution. (API coverage improvement) - InitContainer [NodeConformance] should invoke init containers on a RestartNever pod InitContainer [NodeConformance] should invoke init containers on a RestartAlways pod InitContainer [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod InitContainer [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod /area conformance cc
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Go ahead and open a PR to ask this question. Yes == PR is merged, no == PR is closed (or amended to doc the reason these tests can't be promoted)
Code change:
**Note: this is a design doc, which describes features that have not been completely implemented. User documentation of the current state is [here](../user-guide/compute-resources.md).  The tracking issue for implementation of this model is <del> [#168](http://issue.k8s.io/168).  Currently, only memory and cpu limits on containers (not pods) are supported.  "memory" is in bytes and "cpu" is in </del> <ins> [#168](http://issue.k8s.io/168).  Currently, both limits and requests of memory and cpu on containers (not pods) are supported.  "memory" is in bytes and "cpu" is in </ins> milli-cores.** # The Kubernetes resource model

Related discussion:
text: did which addresses some of them, but turns up a lot more.
Alright, I will do that.
Code change:
// StartContainer starts the container. func (ds *dockerService) StartContainer(containerID string) error { err := ds.client.StartContainer(containerID) <del> if err != nil { err = transformStartContainerError(err) return fmt.Errorf("failed to start container %q: %v", containerID, err) } // Create container log symlink. if err := ds.createContainerLogSymlink(containerID); err != nil { </del> <ins> // Create container log symlink for all containers (including failed ones). if linkError := ds.createContainerLogSymlink(containerID); linkError != nil { </ins> // Do not stop the container if we failed to create symlink because: //   1. This is not a critical failure. //   2. We don't have enough information to properly stop container here. // Kubelet will surface this error to user via an event. <del> return err </del> <ins> return linkError </ins> } <ins> if err != nil { err = transformStartContainerError(err) return fmt.Errorf("failed to start container %q: %v", containerID, err) } </ins> return nil }

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The pods are stuck in with this error: What you expected to happen: I expect the pods to start. How to reproduce it (as minimally and precisely as possible): Running this daemon set on a GCE cluster on (both master and nodes): Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-21T08:23:22Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"windows/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-08-03T06:43:48Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Google Container Engine OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
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
/assign
Confirmed the bug in dockershim, filed to fix this.
Changed a environment and didn't make to reproduce the log problem. With provided manifests, the pod did fail in CrashLoopBackOff, but it is because not found in busybox image: And in container status, there is indeed errors of reading container logs: ! After changing the to , it should run properly. Although didn't fix the crash problem, it still helps on termination messages.
Yeah, that's what I thought. The log stuff is not the cause of the crashloop.
Code change:
// StartContainer starts the container. func (ds *dockerService) StartContainer(containerID string) error { err := ds.client.StartContainer(containerID) <del> if err != nil { err = transformStartContainerError(err) return fmt.Errorf("failed to start container %q: %v", containerID, err) } // Create container log symlink. if err := ds.createContainerLogSymlink(containerID); err != nil { </del> <ins> // Create container log symlink for all containers (including failed ones). if linkError := ds.createContainerLogSymlink(containerID); linkError != nil { </ins> // Do not stop the container if we failed to create symlink because: //   1. This is not a critical failure. //   2. We don't have enough information to properly stop container here. // Kubelet will surface this error to user via an event. <del> return err </del> <ins> return linkError </ins> } <ins> if err != nil { err = transformStartContainerError(err) return fmt.Errorf("failed to start container %q: %v", containerID, err) } </ins> return nil }

Related discussion:
text: Even you create symlink after fail to start container, it still doesn't fix the problem completely. After create the container, there is not log, and if is called at that time, you will still have this error. So the problem is not that we should create symlink after start failure, we should let tolerant log file not exist. Another problem with this issue is that I saw the termination message policy is . Why does kubelet still try to read message from the log?
Maybe we should return empty if the log file doesn't exist? This is because kubelet always fallback to logs if it fails to get from terminationMessagePath (see ).
That if block definitely doesn't belong there...
Or rather, I'm wondering if we should not be reporting the error at all when it's File.
We should never fall back to logs if it is File. Which code would do that (fallbackToLogs or false is always returned)
Opened a change to correctly fall back to logs if the termination message path file does not exist (as we do if the file is empty). While this may actually hide other errors (like ) it matches the intent of FallbackToLogsOnError.
did this work for you? I'm experiencing the same problem and opened an issue here:
these are my logs i am getting in kubernetes.. i am running from jenkins by using kubernetes-plugin making base image as jenkins/jnlp-slave whats this means exactly .. this error? failed to open log file "/var/log/pods/-ebf7-11e7-867e-": open /var/log/pods/-ebf7-11e7-867e- no such file or directory
Maybe you're here because you made the same mistake as I did: My image was trying to execute an ENTRYPOINT in a file that didn't exist. I discovered that by executing:
Code change:
if err != nil { return TestServer{}, err } namedFlagSets := opts.Flags() for _, f := range namedFlagSets.FlagSets { fs.AddFlagSet(f) } fs.Parse(customFlags) <ins> if err := opts.Complete(&namedFlagSets); err != nil { return TestServer{}, err } </ins> if opts.SecureServing.BindPort != 0 { opts.SecureServing.Listener, opts.SecureServing.BindPort, err = createListenerOnFreePort() if err != nil {

Related discussion:
text: ci-kubernetes-e2e-gci-gce-alpha-features kubetest.Up Jul 02 2021, 01:26:42 UTC+0200 /sig release
based on testgrid probably cc <img width="1203" alt="Screen Shot 2021-07-02 at 4 24 25 PM" src="https://user-"
/cc working on it
/assign
the scheduler fails to start with this error: it seems the feature gates from the command line does not take effect in the defaulting phrase, do you know how to fix it?
ah, found there is a cycle here: The scheduler options , but the default config's default values depend on the feature gates options. I think this disables other feature gate controlled logic in the defaulting too:
I tried to fix it by updating the component config after the CLI flags (including the feature gates) are parsed: PTAL
fixed the flake. is back green now.
thanks!
Code change:
fileServer := http.FileServer(&assetfs.AssetFS{Asset: Asset, AssetDir: AssetDir, Prefix: "www"}) prefix := "/static/" mux.Handle(prefix, http.StripPrefix(prefix, fileServer)) <ins> prefix = "/ui/" mux.HandleFunc(prefix, func(w http.ResponseWriter, r *http.Request) { http.Redirect(w, r, dashboardPath, http.StatusTemporaryRedirect) }) </ins> if enableSwaggerSupport { // Expose files in third_party/swagger-ui/ on <host>/swagger-ui

Related discussion:
text: I follow the instruction to start the kubernetes web UI. It's 404 when I open http://127.0.0.1:8080 . Finally I knew that the correct directory is http://127.0.0.1:8080/static/app/#/dashboard/ . We should start the web ui in root directory(I mean http://127.0.0.1:8080) so that anyone like me will not be confused.
/sub
I agree the UI isn't very discoverable. We should redirect from to the correct path. (Assuming that the UI is working well enough to expose it at all.)
I can do this if no one else is on it. Should we redirect and for all requests or just requests with specific user-agents or MIME types?
We return a list of resource paths on currently: We could either redirect for certain user-agents, or choose another, simpler, more obvious, top-level path, like or , which would at least show up in the list of valid paths.
That's great!
Great job :+1:
Code change:
readonly KUBE_TEST_TARGETS=( cmd/e2e cmd/integration <ins> cmd/gendocs </ins> ) readonly KUBE_TEST_BINARIES=("${KUBE_TEST_TARGETS[@]##*/}") readonly KUBE_TEST_BINARIES_WIN=("${KUBE_TEST_BINARIES[@]/%/.exe}")

Related discussion:
text: Manually updated docs have a tendency to drift from actual implementation. It shouldn't be too hard to add a script to generate the markdown from a . We could then run the script manually or as a commit hook when changes are made to pkg/kubectl.
A big chunk of that is cut/paste from the help output anyway.. Brendan On Jan 9, 2015 4:20 PM, "Jeff Lowdermilk" wrote:
Why are we including the help output? Seems like cobra should do that, or we should just tell the user to ask for help if they want it.
It's useful to see generated markdown of help output for the full command tree, e.g. if you want to link to the syntax on irc or something. Anyway, this was quite easy to do, I'll have a PR shortly.
Code change:
ginkgo.It("should grab all metrics from a Scheduler.", func() { ginkgo.By("Proxying to Pod through the API server") <del> // Check if master Node is registered nodes, err := c.CoreV1().Nodes().List(context.TODO(), metav1.ListOptions{}) framework.ExpectNoError(err) var masterRegistered = false for _, node := range nodes.Items { if strings.HasSuffix(node.Name, "master") { masterRegistered = true } } </del> if !masterRegistered { framework.Logf("Master is node api.Registry. Skipping testing Scheduler metrics.") return

Related discussion:
text: MetricsGrabber tests failing when scheduler & controller-manager not visible. In managed offerings, like GKE, scheduler and controller-manager are not visible causing BeforeSuite of MetricsGrabber to fail. Test is failing then control plane pods can't be found (as on GKE): HasControlPlanePods was in /assign
/sig instrumentation
Just removing this check allows tests to run without problems (some skipped, one passing).
/triage accepted
Code change:
ErrCodeResourceVersionConflicts ErrCodeInvalidObj ErrCodeUnreachable <ins> ErrCodeTimeout </ins> ) var errCodeToMessage = map[int]string{

Related discussion:
text: It is possible to issue a list request which exceeds the duration set by the request-timeout apiserver flag. The request-timeout flag does not appear to be enforced when the apiserver is decoding the response from etcd. Specifically, listing a large number of CRDs from etcd can result in high request latency from using json encoding compared to protobuf encoding. While overall etcd latency is low, the overall listing from storage latency may be over the 1 minute timeout, particularly if the apiserver needs to fetch multiple pages from etcd. We expected the list requests to be subject to the duration specified by the request-timeout flag when this latency is coming from the listing from storage phase of the request. Create 4000 CRs and list all the objects from etcd in 2 pages of 2000 objects. If the time to list 1 page + decode takes around 50s, listing 2 pages will result in the listing from storage phase of the request taking around 1 minute and 40s before the request fails and the client is returned a 500 response code. Logs for apiserver Trace message: Audit log entry: Related issue for supporting protobuf for CRDs: <details</details<detailsAWS </details<details</details<details</details<details</details<details</details
/sig api-machinery CC:
Interesting.. - do you know where exactly we stuck? In the call to storage: we pass the context that has timeout set, so that shouldn't hang. OTOH, for the processing part: (a) I don't know if transformer honors the context - it probably depends on the implementation (b) but the decoding (appendListitem) certainly isn't honoring the context So (b) might definitely be a problem, even independently from from the transformer So I guess what I'm saying is that if listing from etcd finishes fast but the decoding is what takes most of time, then what you described can certainly be a problem. But is that the thing you're observing?
Yes, that is our understanding. Specifically, that the decoding which occurs in appendListItem doesn't respect the context: As a separate follow-up, it would be useful to include decoding time, or at least the overall listing from storage time, as a separate latency annotation, given the audit log entry is only capturing this latency as part of
+1.
Code change:
ErrCodeResourceVersionConflicts ErrCodeInvalidObj ErrCodeUnreachable <ins> ErrCodeTimeout </ins> ) var errCodeToMessage = map[int]string{

Related discussion:
text: We need more granular latency tracker especially on the latency spent on decoding. Right now, it only captures etcd round trip and transformer latency.
I would be supportive for both and would be happy to review it if someone opens up a PR for it.
/triage accepted
/assign
/reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it
Reopened this issue. <detailsIn response to : /reopen I think we need to reopen it to document how we resolved the unit test failures brought on by adding it 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:
return nil } <ins> // Validate checks validation of ServerRunOptions func (s *ServerRunOptions) Validate() []error { errors := []error{} if s.TargetRAMMB < 0 { errors = append(errors, fmt.Errorf("--target-ram-mb can not be negative value")) } if s.MaxRequestsInFlight < 0 { errors = append(errors, fmt.Errorf("--max-requests-inflight can not be negative value")) } if s.MaxMutatingRequestsInFlight < 0 { errors = append(errors, fmt.Errorf("--min-request-timeout can not be negative value")) } return errors } </ins> // AddFlags adds flags for a specific APIServer to the specified FlagSet func (s *ServerRunOptions) AddUniversalFlags(fs *pflag.FlagSet) { // Note: the weird ""+ in below lines seems to be the only way to get gofmt to

Related discussion:
text: See I think it's the last file that has no validation in pkg . 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 api-machinery