jiebi/CodeConvo huggingface dataset:
Change:
MountPath: "/subpath_mount", }, { <del> Name:      "workdir2", </del> <ins> Name:      "workdir1", </ins> MountPath: "/volume_mount", }, },

Discussion:
/kind cleanup /sig storage /sig node /sig testing Description: Change e2e tests to use EmptyDir instead of HostPath as pre-requisite to promoting VolumeSubpathEnvExpansion to Conformance. Related Issues: Conformance Tests:
/cc
/assign
Change:
import ( "fmt" "sort" <del> "time" </del> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime"

Discussion:
What happened: On a resource with managedFields populated, a no-op patch modified the serialization order of managedFields. What you expected to happen: No-op patches do not result in a write to etcd. How to reproduce it (as minimally and precisely as possible): contains: the initial ADDED event from kubectl MODIFIED events from kube-controller-manager one MODIFIED event corresponding to the kubectl patch (from resourceVersion 1704 in 1.txt to resourceVersion 1718 in 2.txt) shows the kubectl and kube-controller-manager managed field sets swapped order: second patch was a no-op ( is empty) Anything else we need to know?: This was easiest to reproduce with server-side apply enabled at 100% /assign
/sig api-machinery
/wg apply
Can you print the before/after fieldmanager? I can't quite figure out what the actual values are. The code that sorts these lists is located
updated to unified diff and attached:
If you explicitly set the field manager to something unique, does it happen every time?
hm, no, it's definitely an ordering swap
is not sorted properly, since should come before .
We seem to also sort it in a second place:
Theory: the first time it goes through, the time is accurate to the nanosecond; the second time, it's accurate to the second
Yeah OK I'm pretty sure that's it, both times are the same second. Serialization drops the fractional part.
Change:
} } <del> func (c *cacheWatcher) nextBookmarkTime(now time.Time) (time.Time, bool) { // For now we return 2s before deadline (and maybe +infinity is now already passed this time) // but it gives us extensibility for the future(false when deadline is not set). </del> <ins> // bookmarkHeartbeatFrequency defines how frequently bookmarks should be // under regular conditions. const bookmarkHeartbeatFrequency = time.Minute func (c *cacheWatcher) nextBookmarkTime(now time.Time) time.Time { // We try to send bookmarks: // (a) roughly every minute // (b) right before the watcher timeout - for now we simply set it 2s before //     the deadline // The former gives us periodicity if the watch breaks due to unexpected // conditions, the later ensures that on timeout the watcher is as close to // now as possible - this covers 99% of cases. heartbeatTime := now.Add(bookmarkHeartbeatFrequency) </ins> if c.deadline.IsZero() { <del> return c.deadline, false </del> <ins> return heartbeatTime } if pretimeoutTime := c.deadline.Add(-2 * time.Second); pretimeoutTime.Before(heartbeatTime) { return pretimeoutTime </ins> } <del> return c.deadline.Add(-2 * time.Second), true </del> <ins> return heartbeatTime </ins> } func getEventObject(object runtime.Object) runtime.Object {

Discussion:
Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.
Change:
return } <ins> // Redirect requests of the form "/{resource}/{name}" to "/{resource}/{name}/" // This is essentially a hack for https://github.com/GoogleCloudPlatform/kubernetes/issues/4958. // Note: Keep this code after tryUpgrade to not break that flow. if len(parts) == 2 && !strings.HasSuffix(req.URL.Path, "/") { w.Header().Set("Location", req.URL.Path+"/") w.WriteHeader(http.StatusMovedPermanently) return } </ins> proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: location.Scheme, Host: location.Host}) if transport == nil { prepend := path.Join(r.prefix, resource, id)

Discussion:
This works: but this does not: We should somehow emphasize the need for the trailing slash for now, and then work out what is going wrong (client side scripting?) to fix this (our fault in the proxy or Grafana's?)
Likewise for Kibana.
For the Kibana case, I observe a sequence of correctly proxied GETs e.g. to: but then I see: which fails because I assume what was really needed is: and a curl against that gives a pile of plausible Javascript.
After a little thought, I think what's going on here is that web clients can't tell that is a directory without the trailing slash. One thing we could potentially do to help is to redirect (301) from to , since I don't think the former is useful for anyone.
cc
How are we generating that URL? Can we append a "/" at the end while generating the URL? Doing a redirect or auto-adding "/" in the proxy for all requests could break other requests.
The URL is not generated anywhere. It is assumed that '/proxy/service/<service name' would work. , Nikhil Jindal wrote:
I discussed this with and To clarify, proxy server does not require a trailing slash. It works as expected (gives the same response with or without a trailing slash) The client code, on the other hand, expects it to be rendered on a path with a trailing slash and breaks when that is not the case. Ideally, we should fix the client code. For now, we decided to update proxy to send a 301 redirect from a path without a trailing slash to a path with a trailing slash. I will send a PR for this.
By "client code" do you mean things like Elasticsearch and Kibana?
Yes. The code being rendered on those paths.
I agree with what said, I just want to clarify that it's not necessarily a "broken" client, just one with different expectations. Adding the 301 redirect seems like an easy way to satisfy such clients and reduce user pain.
Not fixed because of
On GCE, the redirection is still not happening because the request is upgraded before we get a chance to redirect On localhost, the redirection works fine but we are unable to load the css and js files because of
Is proxy still supported in v1beta3? I vaguely remember that we wanted to remove it.

I tried this: but got NotFound error.
Access to cluster-level logging components depends on the proxy so avoid making ELBs. Elasticsearch and Kibana are accessed via the v1beta3 service proxy.
Although the trailing slashes are no longer required.
Change:
// TaintNodeUnreachable would be automatically added by node controller // when node becomes unreachable (corresponding to NodeReady status ConditionUnknown) // and removed when node becomes reachable (NodeReady status ConditionTrue). <del> TaintNodeUnreachable = "node.alpha.kubernetes.io/unreachable" </del> <ins> TaintNodeUnreachable = "node.kubernetes.io/unreachable" // DeprecatedTaintNodeUnreachable is the deprecated version of TaintNodeUnreachable. // It is deprecated since 1.9 DeprecatedTaintNodeUnreachable = "node.alpha.kubernetes.io/unreachable" </ins> // When feature-gate for TaintBasedEvictions=true flag is enabled, // TaintNodeOutOfDisk would be automatically added by node controller

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: When discussing issue in , I noticed: although is using key , it has actually been changed to in for quite a while. I am thinking we may need to fix this inconsistency in 1.9, by moving out of alpha. Anything else we need to know?: Task tracker: [x] update [x] update kubernetes doc
/sig scheduling
Change:
// It returns a list of containers, or an error if one occurs. func eventToPods(ev watch.Event) ([]api.BoundPod, error) { pods := []api.BoundPod{} <ins> if ev.Object == nil { return pods, nil } </ins> boundPods, ok := ev.Object.(*api.BoundPods) if !ok { return pods, errors.New("unable to parse response as BoundPods")

Discussion:
To reproduce: Start a cluster via hack/local-up- Start some pods Kill the cluster "docker ps -a" should show the pod containers running still Start the cluster again "etcdctl ls /registry" should show that there is no boundpods directory -- only minions and services "docker ps -a" should show the old pod containers still running Start a new pod After, say, 10s, "docker ps -a" should show the old containers dead /cc
I suspect the cause of this might be : which guarantees that the pod sync logic is never called if is nil. Need to get a repro to confirm.
Change:
server.Close() } } <ins> func TestGetServerPreferredResourcesRetries(t *testing.T) { stable := unversioned.APIResourceList{ GroupVersion: "v1", APIResources: []unversioned.APIResource{ {Name: "pods", Namespaced: true, Kind: "Pod"}, }, } beta := unversioned.APIResourceList{ GroupVersion: "extensions/v1", APIResources: []unversioned.APIResource{ {Name: "deployments", Namespaced: true, Kind: "Deployment"}, }, } response := func(numErrors int) http.HandlerFunc { var i = 0 return func(w http.ResponseWriter, req *http.Request) { var list interface{} switch req.URL.Path { case "/apis/extensions/v1beta1": if i < numErrors { i++ w.WriteHeader(http.StatusInternalServerError) return } list = &beta case "/api/v1": list = &stable case "/api": list = &unversioned.APIVersions{ Versions: []string{ "v1", }, } case "/apis": list = &unversioned.APIGroupList{ Groups: []unversioned.APIGroup{ { Name: "extensions", Versions: []unversioned.GroupVersionForDiscovery{ {GroupVersion: "extensions/v1beta1"}, }, PreferredVersion: unversioned.GroupVersionForDiscovery{ GroupVersion: "extensions/v1beta1", Version:      "v1beta1", }, }, }, } default: t.Logf("unexpected request: %s", req.URL.Path) w.WriteHeader(http.StatusNotFound) return } output, err := json.Marshal(list) if err != nil { t.Errorf("unexpected encoding error: %v", err) return } w.Header().Set("Content-Type", "application/json") w.WriteHeader(http.StatusOK) w.Write(output) } } tests := []struct { responseErrors  int expectResources int expectedError   func(err error) bool }{ { responseErrors:  1, expectResources: 2, expectedError: func(err error) bool { return err == nil }, }, { responseErrors:  2, expectResources: 1, expectedError:   IsGroupDiscoveryFailedError, }, } for i, tc := range tests { server := httptest.NewServer(http.HandlerFunc(response(tc.responseErrors))) defer server.Close() client := NewDiscoveryClientForConfigOrDie(&restclient.Config{Host: server.URL}) got, err := client.ServerPreferredResources() if !tc.expectedError(err) { t.Errorf("case %d: unexpected error: %v", i, err) } if len(got) != tc.expectResources { t.Errorf("case %d: expect %d resources, got %#v", i, tc.expectResources, got) } server.Close() } } </ins>

Discussion:
Split off from , the thing that actually caused the flakes throughout the system (as opposed to just failing the TPR test) is (https://k8s-) Which I guess means that the discovery client got a list, but then the TPR was gone when it tried to get details? This is not an emergency since we've marked the test flaky, but we should fix it.
The print out of the error message included the message, which was generic 404. So I believe returned a 404 without a JSON body.
Yes. The discovery client returns a partial result when this error occurs, see . I think this behavior is correct. Caller should look into the error and ignore it or retry the discovery.
Change:
<ins> /* Copyright 2023 The Kubernetes Authors. 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 main import ( "fmt" "os" "regexp" "strings" flag "github.com/spf13/pflag" kruntime "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/sets" "k8s.io/klog/v2" ) var ( typeSrc = flag.StringP("type-src", "s", "", "From where we are going to read the types") re      = regexp.MustCompile("`(bw+b)`") ) // kubeTypesMap is a map from field name to its tag name and doc. type kubeTypesMap map[string]kruntime.Pair func main() { flag.Parse() if *typeSrc == "" { klog.Fatalf("Please define -s flag as it is the api type file") } docsForTypes := kruntime.ParseDocumentationFrom(*typeSrc) rc := false for _, ks := range docsForTypes { typesMap := make(kubeTypesMap) for _, p := range ks[1:] { // skip the field with no tag name if p.Name != "" { typesMap[strings.ToLower(p.Name)] = p } } structName := ks[0].Name rc = checkFieldNameAndDoc(structName, "", ks[0].Doc, typesMap) for _, p := range ks[1:] { rc = checkFieldNameAndDoc(structName, p.Name, p.Doc, typesMap) } } if rc { os.Exit(1) } } func checkFieldNameAndDoc(structName, fieldName, doc string, typesMap kubeTypesMap) bool { rc := false visited := sets.Set[string]{} // The rule is: // 1. Get all back-tick quoted names in the doc // 2. Skip the name which is already found mismatched. // 3. Skip the name whose lowercase is different from the lowercase of tag names, //    because some docs use back-tick to quote field value or nil // 4. Check if the name is different from its tag name // TODO: a manual pass adding back-ticks to the doc strings, then update the linter to // check the existence of back-ticks nameGroups := re.FindAllStringSubmatch(doc, -1) for _, nameGroup := range nameGroups { name := nameGroup[1] if visited.Has(name) { continue } if p, ok := typesMap[strings.ToLower(name)]; ok && p.Name != name { rc = true visited.Insert(name) fmt.Fprintf(os.Stderr, "Error: doc for %s", structName) if fieldName != "" { fmt.Fprintf(os.Stderr, ".%s", fieldName) } fmt.Fprintf(os.Stderr, " contains: %s, which should be: %sn", name, p.Name) } } return rc } </ins>

Discussion:
Currently we have inconsistency in most of the API where the field name should be used in description so the generated docs match the API fields people actually set. A linter could be for checking To avoid confusing users
/good-first-issue
/triage accepted
/assign
Hey can you provide some more information for this issue
are you still working on this?
Hey feel free to take it. I am unassigning myself
/triage needs-information /remove-good-first-issue
/sig api-machinery
Change:
return nil } <del> func (ds *dockerService) determinePodIPBySandboxID(uid string, sandbox *dockertypes.ContainerJSON) string { </del> <ins> func (ds *dockerService) determinePodIPBySandboxID(uid string) string { </ins> return "" }

Discussion:
<!-- 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?: What happened: PR tries to reduce CNI calls for sandboxed containers: case is for Windows Server 2016 and for Windows Server version greater than 1709 which use Hyper-V containers. Currently, the CNI on Windows fetches the IP from the containers within the pods regardless of the mode. This should be done only in the non-sandbox mode where the IP of the actual container will be different than the IP of the sandbox container. from the same pod will share the network details of the sandbox container. when this mode is supported. However, for Windows 1709 and 1803 we didnt have the Namespace support in Windows which we are bringing in RS5. So we need this second call to replicate the DNS registry key to the Workload container. This is a platform requirement and removing this will break DNS for the workload containers. IP/Gateway/MAC is set separately than DNS. (Refer ) In Rs5 once we move the namespace model, we will update CRI and CNI to add endpoints and add it to the namespace. So the PR breaks dns for windows containers. We should revert it. /sig windows /kind bug
Since is headed for 1.11, this issue should be similarly milestone 1.11 labeled and approved. /milestone v1.11 /status approved-for-milestone
You must be a member of the github team to set the milestone. <detailsIn response to : Since is headed for 1.11, this issue should be similarly milestone 1.11 labeled and approved. /status approved-for-milestone 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
You must be a member of the github team to add status labels.
/milestone v1.11 /status approved-for-milestone
if you can drop an update here on status of the PR revert of PR , and if there's anything additional that might be happening like a re-fix of what was being attempted in the earlier PR, the 1.11 release team would appreciate the additional context.

PR has been reviewed by but still waiting for sig-node's approval
/priority critical-urgent /status in-progress
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<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
Change:
} pod, containerSpec = restoredPod, restoredContainer } // From this point , pod and container must be non-nil. gracePeriod := int64(minimumGracePeriodInSeconds) switch {

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: I tried to use virtlet with Kubernetes release 1.6.6, but a pod with a VM in it gets stuck in "ContainerCreating" state. This problem does not happen with Kubernetes release 1.6.3. The log of the responsible kubelet shows a panic when trying to restart the container. I do not know why the container is being restarted, but that should not cause a panic in any case. Here is an excerpt from the kubelet's log: It is easy to see a code path that can cause this panic. The offending line in is this: and there is indeed a way for to be nil at this point. Earlier in that function we see the line and there is no intervening statement that checks whether is ; ends with . What you expected to happen: I expected the virtlet to run, like it does with Kubernetes release 1.6.3. How to reproduce it (as minimally and precisely as possible): That would take some work, I hope the diagnosis above makes this moot. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: "bare metal" (really VMs, but who cares?) OS (e.g. from /etc/os-release): Ubuntu 16.04.2 LTS Kernel (e.g. ): Linux n11rdu1ctrl 4.4.0-34-generic -Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x8664 x8664 x8664 GNU/Linux Install tools: I installed Kubernetes and virtlet using some local Ansible Others: I am using a local fork of virtlet
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig node
Reiterating the mentions to trigger a notification: <detailsIn response to : </details
, did you do any update action against that Pods?

I upped the kubelet's to 4, and got an interesting clue when I tried the experiment again. Here is an excerpt from the more verbose log. Note the empty container name in the "Killing unwanted container" entry. That telling log entry comes from these lines in which is soon followed by .
I only created the pod, no updates.
Is there a running container with id something like when the panic occurs? A quick fix is to add checking whether containerSpec is nil as you mentioned. But it's weird that gets a container without name.
Did virtlet set correctly? Seems it is "", which caused the problem.
Create a PR () that checking containerSpec to avoid panic. And it seems there's no UT case for , I'll create related PRs for
The actual Docker containers are all gone now. But here is what I got from shortly before opening this issue: I will look into the question asked.
Change:
meta.Annotations[api.TolerationsAnnotationKey] = string(tolerationsAnnotation) } <del> func SetMasterNodeAffinity(meta *api.ObjectMeta) { </del> <ins> // SetNodeAffinity is a basic helper to set meta.Annotations[api.AffinityAnnotationKey] for one or more api.NodeSelectorRequirement(s) func SetNodeAffinity(meta *api.ObjectMeta, expr ...api.NodeSelectorRequirement) { </ins> nodeAffinity := &api.NodeAffinity{ RequiredDuringSchedulingIgnoredDuringExecution: &api.NodeSelector{ <del> NodeSelectorTerms: []api.NodeSelectorTerm{{ MatchExpressions: []api.NodeSelectorRequirement{{ Key: "kubeadm.alpha.kubernetes.io/role", Operator: api.NodeSelectorOpIn, Values: []string{"master"}, }}, }}, </del> <ins> NodeSelectorTerms: []api.NodeSelectorTerm{{MatchExpressions: expr}}, </ins> }, } affinityAnnotation, _ := json.Marshal(api.Affinity{NodeAffinity: nodeAffinity})

Discussion:
Right now we create 3 daemonsets for in , but will only give use image names for , so this feature is broken. We should only deploy one daemon set for the native architecture, but ensure it has the right label selectors, so we don't try to run pods on nodes of different architecture. We should also make sure all addons have architecture labels, and not just . If user is building heterogeneous clusters, the will need to take about deploying addons for additional architectures, we shouldn't pre-deploy multiple things knowing that they will most likely remain unschedulable.
I have the same issue as well. I tried to create a cluster with x86 (Intel NUC) and arm (Raspberry-Pi) and I see that the kube-proxy is crashing. Here's the log entry from kube-proxy Logs from kube-proxy exec user process caused "exec format error" Attached is the kube-proxy yaml file. I see that its picking up arm image Don't know how to fix this.
Change:
setup run_kube_apiserver run_kube_controller_manager <del> run_kubelet </del> create_node SUPPORTED_RESOURCES=("*") # WARNING: Do not wrap this call in a subshell to capture output, e.g. output=$(runTests)

Discussion:
I am running locally which is failing with the following error: Is this expected? Is there a way to change that path? cc
starts kubelet as a normal user, which doesn't have the permission to create the socket in . I think we can create a new kubelet flag to pass this path. /cc
From test- at "# This command checks that the built commands can function together for simple scenarios. It does not require Docker." In this case, can we update this not require On another hand, why test-cmd requires a working Kubelet which does nothing today?
Yes kubectl tests should not really require kubelet. I think it should be fine to remove it if the tests pass without it. cc who own this I think.
See . It passed locally for me.