jiebi/CodeConvo huggingface dataset:
Change:
"strings" "time" <del> "context" </del> "k8s.io/klog" api "k8s.io/api/core/v1"

Discussion:
What happened: Upgraded from 1.16.6 to 1.17.2 and will no longer start on control-plane hosts. It fails with: What you expected to happen: to start, static pods to launch, to connect to in the static pod How to reproduce it (as minimally and precisely as possible): Have the , , , etc in the static pod manifest folder. Try to start the with the container images not preloaded on the host. Just in case it is needed: is used as the backend is run using Anything else we need to know?: This looks to be two things interacting poorly: 1- It takes a long time for static pods to be created for the first time when the can't talk to yet. 2- The new CSI migration code force terminates causing these log lines to appear in : It looks like introduced this new fatal error. Environment: Kubernetes version (use ): 1.17.2 Cloud provider or hardware configuration: Bare-metal OS (e.g: ): Fedora 31..1 (CoreOS preview)" Kernel (e.g. ): 5.3.12-300.fc31.x86_64 Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cluster-lifecycle
Actually, probably: /sig node
The referenced PR was in 1.14, so that interaction is not new. What is likely new is the size increase of hyperkube in 1.17 (xref ). When not pre-pulled, this can increase the time it takes to start hyperkube for the first time. Does the image pull make progress as the kubelet restarts/retries?
It might make sense for the initializeCSINode() method to: first wait to successfully talk to the kube apiserver at all, perhaps indefinitely after successfully talking to the kube apiserver, then try to register the CSINode object with backoff, and fail if it cannot do that successfully
/sig storage /remove-sig cluster-lifecycle
It doesn't seem to. Once the connection to containerd is closed, it cancels the context. Otherwise I would expect this to succeed eventually if the pull happened in the background. That sounds reasonable to me assuming it isn't blocking the static pod creation code. Do you happen to know why it takes a very long time for the static pod creation code to be called?

I would expect the pods to be created very soon after the kubelet is started.
Pulling the image and starting the processes for those pods happens immediately (from the containerd logs, you can see the image pull happening... it just doesn't complete in time before the independent kubelet logic to register the CSI node info times out).
Ah, yes. I just upgraded a couple of days ago so I didn't check whether I still saw the 2 minute delay in creating the "pod sandboxes" (this is before the pull even happens). It now is only a 23 second delay: containerd: kubelet:
ack, I like the idea Will work on a fix today and cherry-pick it as necessary
Change:
klog.Fatalf("%v", err) } lastScheduledCount := len(podsScheduled) <ins> ticker := time.NewTicker(throughputSampleFrequency) defer ticker.Stop() </ins> for { select { case <-ctx.Done(): return <del> // TODO(#94665): use time.Ticker instead case <-time.After(throughputSampleFrequency): </del> <ins> case <-ticker.C: </ins> podsScheduled, err := getScheduledPods(tc.podInformer, tc.namespaces...) if err != nil { klog.Fatalf("%v", err)

Discussion:
/sig scheduling /sig testing /assign
/kind cleanup
May I give a try?
please go ahead. Un-assigning myself.
/assign What should I do just replace with ?
please see the go docs for and the example they have there: They do a better job than I possibly can :)
Change:
ctx, cancel := context.WithCancel(context.Background()) defer cancel() // 3. Populate vcToZoneHostsMap and vcToHostDatastoresMap <del> for _, nodeInfo := range nameToNodeInfo { </del> <ins> for _, nodeInfo := range nm.nameToNodeInfo { </ins> vc := nodeInfo.VSphere.Config.Hostname host := nodeInfo.HostSystemRef.Value for _, zone := range nodeInfo.Zones {

Discussion:
Command run: vSphere intree volume test suite occasionally failed with the following error: The test suite should always pass. We may have a chance to hit this by running ` No response binary version: 1.27.4 </details<detailsvsphere </details<details</details<details</details<details</details<details</details
/assign
/sig testing storage ?
/triage accepted
Change:
INDIRECT=$$(go list -e                                 -f '{{range .Deps}}{{.}}{{"n"}}{{end}}'           ./cmd/libs/go2idl/conversion-gen                   <del> | grep "^$(PRJ_SRC_PATH)"                          </del> <ins> | grep --color=never "^$(PRJ_SRC_PATH)"            </ins> | sed 's|^$(PRJ_SRC_PATH)|./|'                     | xargs go list -e -f '{{.Dir}} {{.Dir}}/*.go');   echo $$DIRECT $$INDIRECT                              

Discussion:
Using the grep from OSX, fails when GREPOPTIONS/GREPCOLOR is set as shown below (). Workaround : unset GREPOPTIONS/GREPCOLOR Note that using GNU grep using brew install will show that GREPOPTIONS shows immediately that GREP_OPTIONS may be interfering with make ()
oh, here's badly manged conversion-
Will look, thanks. For make-related bugs, please @ me directly.
Will do. thanks
This breaks building kubernetes inside Alpine Linux:
I'm pressing more and more on the idea that the only supported build is the dockerized build. Trying to accomodate every random environment is just too taxing. , Marc Villacorta wrote:
I agree with We can support the stuff in to run on mac to get you dockerized but everything else is only supported in there. I've worked around a few BSD/OSX things in but it isn't fun. We should try to keep that stuff isolated.
I agree, with the usual caveat that we need to be doing all of the build in one container with as little as possible happening outside. OS X tends to have old and broken versions of important programs, which is terrible. We discussed setting up CI for it but it's not going to happen in the near term. Alpine/Busybox purposefully omit features from their versions for good reasons, but it's still more work to support than it's worth.
Ok, I will re-think my workflow.
How did you find yourself building in Alpine, in I may ask? , Marc Villacorta wrote:
nothing is forcing me to use Alpine I just like the distro. I run stuff on CoreOS and my aim is to solve the build-deliver-run pipeline with a single small container. By the way, I have the problem installing the GNU package :-)
Change:
if [[ -x ./hack/jenkins/upload-to-gcs.sh ]]; then ./hack/jenkins/upload-to-gcs.sh else <del> curl -fsS --retry 3 "https://raw.githubusercontent.com/kubernetes/kubernetes/master/hack/jenkins/upload-to-gcs.sh" | bash - </del> <ins> curl -fsS --retry 3 --keepalive-time 2 "https://raw.githubusercontent.com/kubernetes/kubernetes/master/hack/jenkins/upload-to-gcs.sh" | bash - </ins> fi

Discussion:
http://pr- Seems like a flake? Could probably retry this, but not sure whether it's worth it.
we most definitely want to retry! Will you send a PR?
I just hit this in PR
We should close this, should be fixed by:
that didn't actually solve the problem. Per the docs, only works on "transient" errors, which the manpage defines as We might want to try passing , which some googling suggests might help. The default is 60s, which may be too long.
Please reactive this if you see it after June 15
Change:
return *s } <del> // convertStatusToAPIStatus creates an api PodStatus for the given pod from // the given internal pod status.  It is purely transformative and does not // alter the kubelet state at all. func (kl *Kubelet) convertStatusToAPIStatus(pod *v1.Pod, podStatus *kubecontainer.PodStatus) *v1.PodStatus { var apiPodStatus v1.PodStatus // The runtime pod status may have an arbitrary number of IPs, in an arbitrary // order. Pick out the first returned IP of the same IP family as the node IP // first, followed by the first IP of the opposite IP family (if any). podIPs := make([]v1.PodIP, 0, len(podStatus.IPs)) </del> <ins> // sortPodIPs return the PodIPs sorted and truncated by the cluster IP family preference. // The runtime pod status may have an arbitrary number of IPs, in an arbitrary order. // PodIPs are obtained by: func (m *kubeGenericRuntimeManager) determinePodSandboxIPs() // Pick out the first returned IP of the same IP family as the node IP // first, followed by the first IP of the opposite IP family (if any) // and use them for the Pod.Status.PodIPs and the Downward API environment variables func (kl *Kubelet) sortPodIPs(podIPs []string) []string { ips := make([]string, 0, 2) </ins> var validPrimaryIP, validSecondaryIP func(ip string) bool if len(kl.nodeIPs) == 0 || utilnet.IsIPv4(kl.nodeIPs[0]) { validPrimaryIP = utilnet.IsIPv4String

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 --In a dual-stack cluster with IPv4 as default family (first kubelet IP), a container is created with a env var set to . When the container is running, properly contains the IPv4 But at runtime, this env var (used in container args) is expanded to the pod IPv6 instead of the IPv4. When using , it should always return the value actually exposed as and not something else. Kubernetes version:Cloud provider or hardware configuration: Bare metal cluster OS (e.g: ): Ubuntu 20.04 Kernel (e.g. ): Linux 5.8.0-59-generic 66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x8664 x8664 x86_64 GNU/Linux Network plugin and version (if this is a network-related bug): cilium 1.10 Others: CRI-O 1.21 + crun.
Note: I have a configuration that matches the ones that had IP ordering issue before was fixed. So it may be related.
/sig network
Just a guess, but I wonder if it may be caused by
That's it. The fix from properly sort IP when computing the Pod status, but the sorted IPs are then replaced by computed IPs as this log shows.
/triage accepted Thanks for the detailed report
/assign
Change:
"google.golang.org/grpc" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/klog/v2" pluginapi "k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1" watcherapi "k8s.io/kubelet/pkg/apis/pluginregistration/v1"

Discussion:
Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: TestDevicePluginReRegistrationProbeMode Testgrid link: Reason for failure: Anything else we need to know: Reproduce with /sig node
/assign
See
not sure this is actually fixed, I see a failure from today
Change:
return nodes == 1 }, time.Minute, time.Second).Should(gomega.BeTrue()) <ins> v1alphaPodResources, err = getV1alpha1NodeDevices() framework.ExpectNoError(err, "should get node local podresources by accessing the (v1alpha) podresources API endpoint") v1PodResources, err = getV1NodeDevices() framework.ExpectNoError(err, "should get node local podresources by accessing the (v1) podresources API endpoint") // Before we run the device plugin test, we need to ensure // that the cluster is in a clean state and there are no // pods running on this node. gomega.Expect(v1alphaPodResources.PodResources).To(gomega.BeEmpty(), "should have no pod resources") gomega.Expect(v1PodResources.PodResources).To(gomega.BeEmpty(), "should have no pod resources") </ins> ginkgo.By("Scheduling a sample device plugin pod") data, err := e2etestfiles.Read(SampleDevicePluginDSYAML) if err != nil {

Discussion:
Device Plugin [Feature:DevicePluginProbe][NodeFeature:DevicePluginProbe][Serial] DevicePlugin [Serial] [Disruptive] Can schedule a pod that requires a device It appears a bit flaky on testgrid, but more recently been failing more often No response example - No response /sig node
/cc
/triage accepted /assign /priority important-soon
I ran this test locally 15 times back to back and did not run into this failure. The test passed locally. I suspect this to be a case where pod cleanup is not happening properly. In this test, we are relying on the number of PodResources and based on the error it looks like we have an addtional pod running other than the two expected pods (device plugin pod and test pod requesting device) but can't be 100% sure because we don't have enough logs to support that claim. Going to add more logs to expose output obtained from the podresource API endpoint.
Change:
// the provided timer until the provided context is cancelled, the condition returns // true, or the condition returns an error. If sliding is true, the period is computed // after condition runs. If it is false then period includes the runtime for condition. <del> // If immediate is false the first delay happens before any call to condition. The // returned error is the error returned by the last condition or the context error if // the context was terminated. </del> <ins> // If immediate is false the first delay happens before any call to condition, if // immediate is true the condition will be invoked before waiting and guarantees that // the condition is invoked at least once, regardless of whether the context has been // cancelled. The returned error is the error returned by the last condition or the // context error if the context was terminated. </ins> // // This is the common loop construct for all polling in the wait package. func loopConditionUntilContext(ctx context.Context, t Timer, immediate, sliding bool, condition ConditionWithContextFunc) error {

Discussion:
Calling wait.PollUntilContextTimeout with immediate=true does not invoke the passed condition function if context has already been cancelled. wait.PollUntilContextTimeout with immediate=true should invoke the passed condition function at least once even if context has already been cancelled as wait.PollUntilContextCancel documentation says: Note that wait.PollUntilContextTimeout wraps wait.PollUntilContextCancel, so the above should be applied to wait.PollUntilContextTimeout as well. This program panics because context ctx.Err is checked before invoking the passed function. The deprecated wait.PollImmediateWithContext does not have this kind of issue. If wait.PollUntilContextTimeout is the replacement of wait.PollImmediateWithContext, it should exhibit the same behavior. k8s v1.27.2 <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
TestloopConditionUntilContextsemantic also has an issue that immediate and sliding are not tested as expected. immediate and sliding are loop variable, but they are not used in the test. The ones that are used are in testcase struct which are always false.
/assign
ok, it seems this would do it
/assign
/triage accepted
Change:
func (handler *fakeIOHandler) ReadDir(dirname string) ([]os.FileInfo, error) { switch dirname { case "/dev/disk/by-path/": <del> f := &fakeFileInfo{ </del> <ins> f1 := &fakeFileInfo{ </ins> name: "pci-0000:41:00.0-fc-0x500a0981891b8dc5-lun-0", } <del> return []os.FileInfo{f}, nil </del> <ins> f2 := &fakeFileInfo{ name: "fc-0x5005076810213b32-lun-2", } f3 := &fakeFileInfo{ name: "abc-0000:41:00.0-fc-0x5005076810213404-lun-0", } return []os.FileInfo{f1, f2, f3}, nil </ins> case "/sys/block/": f := &fakeFileInfo{ name: "dm-1",

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: Currently, we have logic here to look for the disk names with but this fails when we have devices which are starting with e.g: on ppc64le architecture, NPIV based fc disks are discovered as follows: and here is the udev information for one of the disk: Because of the existing logic k8s fails to detect the disk because it does not start with instead starts with , so pod creation fails with the following error: What you expected to happen: FC disk should get attached properly to the pod How to reproduce it (as minimally and precisely as possible): sample pod yaml on a machine with path names starts with Anything else we need to know?: Environment:
/sig storage
/triage accepted
Change:
func TestPathBuilderWithMultiple(t *testing.T) { b := NewBuilder(latest.RESTMapper, api.Scheme, fakeClient()). FilenameParam(false, "../../../examples/guestbook/redis-master-controller.yaml"). <del> FilenameParam(false, "../../../examples/guestbook/redis-master-controller.yaml"). </del> <ins> FilenameParam(false, "../../../examples/pod"). </ins> NamespaceParam("test").DefaultNamespace() test := &testVisitor{}

Discussion:
It works when I pipe but not with filename.
broke in this commit cc
Did you try to add an extension .json to the file? We filter for file extensions
ahhh ok. so working as intended. it used to autodetect :( ... thanks
That was unintended. The file extensions should only be used for deciding which files in a directory to process. For a single file, any extension should be allowed. We don't actually infer the content type from the extensions. For stdin and http sources, for instance, there are no extensions. cc
Fix is pretty straightforward (ignore file extensions when dealing with single file); I have it working with manual test, just adding unit test. Will send shortly.
Thanks, but this is v1.0-post, so no rush
Change:
podLimits := sum(containerLimits) for k, v := range limit.Min { if err := minConstraint(limitType, k, v, podRequests, podLimits); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } for k, v := range limit.Max { if err := maxConstraint(limitType, k, v, podRequests, podLimits); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } for k, v := range limit.MaxLimitRequestRatio { if err := limitRequestRatioConstraint(limitType, k, v, podRequests, podLimits); err != nil { <del> return err </del> <ins> errs = append(errs, err) </ins> } } } } <del> return nil </del> <ins> return errors.NewAggregate(errs) </ins> }

Discussion:
When a resource violates the limitrange, both for cpu and memory, only one error will be returned at a time. That means when a user is creating such a resource, first it will fail and return something like , them user may edit the cpu usage and create again, then fail again and get . It seem admission controls want to reject the request as fast as possible, if error occurs. But in this case, it may give users a bad experience. Would it be better to aggregate all errors and return them at one time. Also, the error message may cause misunderstanding. , it means the resource requested is 3, it may also cause a confusion that it is limited to 3.
Closing since it's fixed
Change:
origStateIsCurrent = true continue } <del> return decode(s.codec, s.versioner, origState.data, out, origState.rev) </del> <ins> if len(txnResp.Responses) == 0 || txnResp.Responses[0].GetResponseDeleteRange() == nil { return errors.New(fmt.Sprintf("invalid DeleteRange response: %v", txnResp.Responses)) } deleteResp := txnResp.Responses[0].GetResponseDeleteRange() if deleteResp.Header == nil { return errors.New("invalid DeleteRange response - nil header") } return decode(s.codec, s.versioner, origState.data, out, deleteResp.Header.Revision) </ins> } }

Discussion:
While working on generalizing tests to somehow better define spec for storage interface (and share them across all implementation of storage.interface - in particular etcd3 and watchcache), I found an unexpected inconsistency in Delete operation in etcd3. What is happening is that it effectively returns the state of the object from just before the deletion: However, this is inconsistent with how our watch is working, which is returning the state of the object from just before the deletion, but it sets the RV to the moment of deletion (which Delete call isn't doing). This sounds like a bug to me, but given this is a long-standing behavior we may need to take additional care when fixing this. /kind bug /sig api-machinery /priority important-soon /cc
I opened as a fix for it.
/triage accepted
Change:
} else if err != nil { t.Errorf("%d: expected nil error, got %v", i, err) } <del> if !reflect.DeepEqual(s, test.expected) { t.Errorf("%d: expected %+v, got %+v", i, test.expected, s) </del> <ins> if !reflect.DeepEqual(*v.value, test.expected) { t.Errorf("%d: expected %+v, got %+v", i, test.expected, *v.value) </ins> } if v.changed != test.changed { t.Errorf("%d: expected %t got %t", i, test.changed, v.changed)

Discussion:
I ran and it panicked: no panic The panic was introduced by . I submitted as an attempt to fix this, but review led to the realization that there were further bugs and I don't know what the right fix is cc
/assign
/sig testing /sig cloud-provider
/triage accepted
Change:
"apiVersion": "v1beta1", "id": "service-${version}-test", "port": 80, <del> "protocol": "TCP", "selector": { "version": "old" } </del> <ins> "protocol": "TCP" </ins> } __EOF__ # Post-condition:redis-master-service service is running kube::test::get_object_assert services '{{range.items}}{{.id}}:{{end}}' 'kubernetes:kubernetes-ro:redis-master:service-.*-test:' <del> ### Update selector of service-${version}-test # Pre-condition: selector.version == old kube::test::get_object_assert "service service-${version}-test" "{{range.selector}}{{.}}{{end}}" 'old' </del> # Command <del> kubectl update service "${kube_flags[@]}" service-${version}-test --patch="{"selector":{"version":"${version}"},"apiVersion":"${version}"}" </del> <ins> kubectl update service "${kube_flags[@]}" service-${version}-test --patch="{"selector":{"my":"test-label"},"apiVersion":"v1beta1"}" </ins> # Post-condition: selector.version == ${version} # This test works only in v1beta1 and v1beta2 # https://github.com/GoogleCloudPlatform/kubernetes/issues/4771 <del> if [[ "$version" != "" ]] && [[ "$version" != "v1beta3" ]]; then kube::test::get_object_assert "service service-${version}-test" "{{range.selector}}{{.}}{{end}}" "${version}" fi </del> <ins> kube::test::get_object_assert "service service-${version}-test" "{{range.selector}}{{.}}{{end}}" "test-label" </ins> ### Identity kubectl get service "${kube_flags[@]}" service-${version}-test -o json | kubectl update "${kube_flags[@]}" -f -

Discussion:
contains a list of commands to test. Those commands are run in a loop of API version. Among those commands, there is the following one: This command is supposed to update the version selector of the service. The command that is just after shows: The on the first and last lines indicate that the update failed.
I can look at this.
For the case where ${version}="" the patch is which is invalid as there is no apiversion. For the case where ${version}="v1beta3" the patch is which is a valid patch but has been moved to in the v1beta3 api, so the patch doesn't actually change the service object. Test is fixed with attached PR. The error for the first is easily caught by validating a patch has an api version. The second is less easy as json.Unmarshal() doesn't error when there are fields in the json that are not present in the struct. The test is fixed by treating the patch json how we treat the service json: keep the apiVersion invariant over the loops so we don't have to worry about changes in the api schema.
Change:
glog.Errorf("Unable to convert pod manifest: %v", err) } <del> events, _ := d.Events(namespace).Search(pod) </del> <ins> var events *api.EventList if ref, err := api.GetReference(pod); err != nil { glog.Errorf("Unable to construct reference to '%#v': %v", pod, err) } else { ref.Kind = "" // Find BoundPod objects, too! events, _ = d.Events(namespace).Search(ref) } </ins> return tabbedString(func(out io.Writer) error { fmt.Fprintf(out, "Name:t%sn", pod.Name)

Discussion:
We introduced UID / UUID to provide time-based uniqueness, but UID / UUID are not user friendly. We are going to have this kind of issues in general at client side.
Yeah, describe does a "get" first, so it has the UID available.
Pretty sure this is a feature until we have a way to lookup dead pods. On Nov 21, 2014 2:47 PM, "Daniel Smith" wrote: