jiebi/CodeConvo huggingface dataset:
Change:
} // dsFromManifest reads a .json/yaml file and returns the daemonset in it. <del> func dsFromManifest(fileName string) *extensions.DaemonSet { </del> <ins> func dsFromManifest(url string) *extensions.DaemonSet { </ins> var controller extensions.DaemonSet <del> framework.Logf("Parsing ds from %v", fileName) data := generated.ReadOrDie(fileName) </del> <ins> framework.Logf("Parsing ds from %v", url) var response *http.Response var err error for i := 1; i <= 5; i++ { response, err = http.Get(url) if err == nil && response.StatusCode == 200 { break } time.Sleep(time.Duration(i) * time.Second) } Expect(err).NotTo(HaveOccurred()) Expect(response.StatusCode).To(Equal(200)) defer response.Body.Close() data, err := ioutil.ReadAll(response.Body) Expect(err).NotTo(HaveOccurred()) </ins> json, err := utilyaml.ToJSON(data) Expect(err).NotTo(HaveOccurred())

Discussion:
xref: /sig node /area test
I am working on this.
Can you update this with the types of tests that you are adding? Is this similar to ?
No, this is for running the existing GPU e2e tests on GKE which are currently running on only GCE.
The referenced PRs appear to have merged, closing.
Change:
// create new iface out, err = b.exec.Run("iscsiadm", "-m", "iface", "-I", newIface, "-o", "new") if err != nil { <del> lastErr = fmt.Errorf("iscsi: failed to create new iface: %s (%v)", string(out), err) return lastErr </del> <ins> exit, ok := err.(utilexec.ExitError) if ok && exit.ExitStatus() == iscsiadmErrorSessExists { klog.Infof("iscsi: there is a session already logged in with iface %s", newIface) } else { lastErr = fmt.Errorf("iscsi: failed to create new iface: %s (%v)", string(out), err) return lastErr } </ins> } // update new iface records for key, val := range params {

Discussion:
What happened: In order to communicate with the target, the iscsi plugin creates a new iface. If for some reason an iface with the same name already exists in the node, this command will re-create it and no error will be reported. However, if the iface already exists and is being used by a session, this command will fail and report the error code 15 (). That's because it can't re-create the iface while it's in use by a session. What you expected to happen: The plugin could go ahead and use the existing iface instead of failing. How to reproduce it (as minimally and precisely as possible): pod1 pod2 Here, will re-use the session/iface from the step above. pod1 At this point, k8s will try to delete the session/iface used by pv1. However, it'll fail because the session is currently in use by pv2. pod1 Here the pod's status will be stuck at : Templates used: Anything else we need to know?: problem happens when a custom initiator is used, and it was reported to me that it's necessary in some set-ups in order to "restrict access to LUNs of the storage". to reproduce manually (assuming there's a session using the iface): /sig storage /CC
/assign
is this related to cc
If iface is reused, wouldn't it try to delete it once last volume (from kubelet perspective) is detached?
No
Change:
klog.Errorf("iscsi: failed to mkdir %s, error", globalPDPath) return err } <ins> if b.volumeMode == v1.PersistentVolumeFilesystem { notMnt, err := b.mounter.IsLikelyNotMountPoint(globalPDPath) if err != nil { return err } if !notMnt { // The volume is already mounted, therefore the previous WaitForAttach must have // persisted the volume metadata. In addition, the metadata is actually *inside* // globalPDPath and we can't write it here, because it was shadowed by the volume // mount. klog.V(4).Infof("Skipping persistISCSI, the volume is already mounted at %s", globalPDPath) return nil } } </ins> // Persist iscsi disk config to json file for DetachDisk path return util.persistISCSIFile(*(b.iscsiDisk), globalPDPath) }

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-soon 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
/priority important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.
Change:
netConf, cniNet := network.NetworkConfig, network.CNIConfig glog.V(4).Infof("About to del CNI network %v (type=%v)", netConf.Name, netConf.Plugins[0].Network.Type) err = cniNet.DelNetworkList(netConf, rt) <del> if err != nil { </del> <ins> // The pod may not get deleted successfully at the first time. // Ignore "no such file or directory" error in case the network has already been deleted in previous attempts. if err != nil && !strings.Contains(err.Error(), "no such file or directory") { </ins> glog.Errorf("Error deleting network: %v", err) return err }

Discussion:
/kind bug What happened: During pod teardown, we sometimes see the following error-level kubelet logs: What you expected to happen: Clean pod shutdown, no error-level logs. How to reproduce it (as minimally and precisely as possible): We've got two kube crons that run every minute, across 12 regions in production -- so related pods daily -- and we see this about 3-12 times per day. Anything else we need to know?: Relevant kubelet log context of a cron pod that manifested this error: Controller manager for the pod: Scheduler for the pod: Cron yaml: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Bare metal OS (e.g. from /etc/os-release): 16.04.1 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-89-generic -Ubuntu Install tools: N/A Others: N/A
/sig network
Same problem here. Every time I try to of my deploy, the old pod cannot be terminated successfully. below is output of
Have you checked the ns net files of those failed-to-deleted pods? /cc Could we just ignore these errors?
Sorry, yeah, that seems like a fair point to note -- the directories are in fact being deleted. Seems like it's either functionally succeeding yet generating error-level logs, or perhaps generating error-level logs and then succeeding on internal retry.
I prefer the later one. Perhaps kubelet does not kill the pod completely at the first time. Such error may occur during a retry.
So this is just an overly scary log message?
Yes, I think so. In the first attempt to delete the pod, the ns network file has already been deleted. But the pod does not get deleted successfully. Then "no such file or directory" will be raised in the second attempt.
Change:
NonMergingIntList []int MergeItemPtr      *MergeItem `patchStrategy:"merge" patchMergeKey:"name"` SimpleMap         map[string]string <ins> ReplacingItem     runtime.RawExtension `patchStrategy:"replace"` </ins> } var mergeItem MergeItem

Discussion:
Extracted from The RawExtension type allows an API object to inline arbitrary JSON. strategicpatch.CreateTwoWayMergePatch returns an error trying to map that inlined JSON to struct fields. It should be able to compute a patch for an object containing a field of that type.
cc
We need to decide what strategic merge patch should do in the following scenarios: unknown fields (can be encountered when the API or a user-defined object has a new field the compiled-in struct doesn't have yet) unmergeable fields (like RawExtension) cc
The current behavior is: unknown fields: trying to merge a unknown field will fail when lookup the metadata in the struct tags unmergeable fields: will be replaced as raw byte array Maybe we can use generic json merge for unmergeable fields?
Did that change since 1.5? In 1.5, we were getting an error during patch computation for objects with a RawExtension field
Sorry. This behavior is in 1.4.7. e.g . It will error in 1.5.
Yeah, the field gets replaced. Even in 1.4.7, an unknown field (like initcontainers in pods) or an object including a RawExtension (anything with a field of type or ) would error
My personal favor would be to instruct the patch to ignore such field, seems the cleanest approach to me. Similarly to how we allow annotating deletion and merging.
wouldn't it be confusing to submit a patch with stuff in that field, have the patch accepted, and have none of your submitted changes take effect? seems like the least surprising thing would be to treat struct fields like or as
How about both, iow. having as a default and as an opt-in. This would allow the resource author to decide how his resource should be treated. Eventually on we could return the ignored fields. Having said that we could start with right away. I think I could work on a patch implementing that if majority agrees (
I think is a good place to start when computing/applying patches for known struct fields like RawExtension. I'll open a separate issue for client-side handling of computing patches for unknown fields
Ignore the field sounds like a really good solution. WDYT of printing a warning to stdeer?
what does ignoring instead of replacing get us?
Sorry I was reading the comment on my phone between other things. Ignore my comment.
Change:
RUN CGO_ENABLED=0 GOOS=linux GO111MODULE=on go build -a -ldflags "-w" -o /elasticsearch_logging_discovery /elasticsearch_logging_discovery.go <del> FROM docker.elastic.co/elasticsearch/elasticsearch-oss:7.1.1 </del> <ins> FROM docker.elastic.co/elasticsearch/elasticsearch-oss:7.2.0 </ins> VOLUME ["/data"] EXPOSE 9200 9300

Discussion:
What happened: On latest fluentd-elasticsearch, the elasticsearch replicas seems failed to form a valid cluster with the service discovery helper written in golang. What you expected to happen: Successfully boot up an elasticsearch cluster I guess. How to reproduce it (as minimally and precisely as possible): Just use the yamls in and the elasticsearch-logging pods will keep spamming warning messages. I think thats because options are deprecated in elasticsearch 7.x.x Anything else we need to know?: IMHO I think thats all. Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig instrumentation
Thanks
Change:
MASTER_SIZE=n1-standard-1 MINION_SIZE=n1-standard-1 NUM_MINIONS=${NUM_MINIONS:-4} <ins> MINION_DISK_TYPE=pd-standard MINION_DISK_SIZE=10GB </ins> # TODO(dchen1107): Filed an internal issue to create an alias # for containervm image, so that gcloud will expand this # to the latest supported image.

Discussion:
The node disk type should be an option in the cluster/gce/config-*.sh files. The nodes get created here:
And also the disk size.
How to do this for aws ? I am stuck at 10GB minion
It . A pull request adding it would be very welcome!
please check this thread
Hello there, can I do something to make this available in the command ? I'd like to us an SSD drive :)
Change:
func (f *fakeVMSet) GetDataDisks(nodeName types.NodeName) ([]compute.DataDisk, error) { return nil, fmt.Errorf("unimplemented") } <ins> func (f *fakeVMSet) GetProvisioningStateByNodeName(name string) (string, error) { return "", fmt.Errorf("unimplemented") } </ins>

Discussion:
Implement proposal for Azure We should implement interface in Azure cloud provider. returns true if the instance is in stopped state to detach volumes. But if instance is deleted we should not return error. Related features: Related proposal: Related PRs: /kind feature /sig azure /cc
- can you assign me on this one ? I already have a PR in flight.
That's great! /assign just loop in for this RP review, thanks.
GitHub didn't allow me to assign the following users: yastij. Note that only and repo collaborators can be assigned. <detailsIn response to : That's great! /assign just loop in for this RP review, thanks. 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
o, you are not a k8s member yet, anyway, you could send out the PR for this feature, related to this issue, thanks.
Thanks, looking forward to your PR.
Change:
tc.runTest(t) } <ins> func TestReplicaCalcMissingMetricsScaleDownTargetOver100(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  4, expectedReplicas: 2, podReadiness:     []v1.ConditionStatus{v1.ConditionFalse, v1.ConditionTrue, v1.ConditionTrue, v1.ConditionTrue}, resource: &resourceInfo{ name:     v1.ResourceCPU, requests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("2.0"), resource.MustParse("2.0")}, levels:   makePodMetricLevels(200, 100, 100), targetUtilization:   300, expectedUtilization: 6, expectedValue:       numContainersPerPod * 100, }, } tc.runTest(t) } </ins> func TestReplicaCalcDuringRollingUpdateWithMaxSurge(t *testing.T) { tc := replicaCalcTestCase{ currentReplicas:  2,

Discussion:
Change the fallback consumption from to when pod metrics are missing on a scale down. Background from : The fallback value of 100% is supposed to be a safe overestimate of the desired value to dampen the magnitude of a potential scale down. However, if a metric target is set to more than 100% then this fallback typically becomes an underestimate that amplifies a potential scale down. Note that a metric target of over 100% is a valid HPA configuration. We could choose a fallback of instead. However, any safety margin would be arbitrary and I think it's better to opt for simplicity vs. precision in this corner case.
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 autoscaling
/assign
/assign
Change:
genericfeatures.APIServerTracing: {Default: true, PreRelease: featuregate.Beta}, <ins> genericfeatures.APIServingWithRoutine: {Default: true, PreRelease: featuregate.Beta}, </ins> genericfeatures.ConsistentListFromCache: {Default: false, PreRelease: featuregate.Alpha}, genericfeatures.CustomResourceValidationExpressions: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.31

Discussion:
Optimize the memory usage of goroutine stack for serving watch requests. According to the of handling a watch request, the stack memory is 0x3768, which is very close to 16 KiB and Golang runtime will double it to 32 KiB once exceeded. In fact, it does exceed if we print the traceback deeper and take the fact that extra stack memory reserved by Golang itself into consideration. A naive optimization is to run as much as preparation handlers in a separate goroutine and then move the actual serving to another goroutine, so the former routine can free the stack memory earlier and make it more memory efficient. Given the extensive use of watch requests, 32 KiB per watch could add up to a very high amount of memory overhead for . A typical watch request commonly lasts for 30s or longer, which means this memory will be active for quite long. I see a great improvement in memory efficiency to do this optimization.
/cc
/sig api-machinery
/cc if you would like to take a look when you have time :) Thank you /triage accepted
Change:
sinkWatcher.Stop() logWatcher.Stop() } <ins> func TestEventfNoNamespace(t *testing.T) { testPod := &api.Pod{ ObjectMeta: api.ObjectMeta{ SelfLink: "/api/version/pods/foo", Name:     "foo", UID:      "bar", }, } testRef, err := api.GetPartialReference(testPod, "desiredState.manifest.containers[2]") if err != nil { t.Fatal(err) } table := []struct { obj          runtime.Object reason       string messageFmt   string elements     []interface{} expect       *api.Event expectLog    string expectUpdate bool }{ { obj:        testRef, reason:     "Started", messageFmt: "some verbose message: %v", elements:   []interface{}{1}, expect: &api.Event{ ObjectMeta: api.ObjectMeta{ Name:      "foo", Namespace: "default", }, InvolvedObject: api.ObjectReference{ Kind:       "Pod", Name:       "foo", Namespace:  "", UID:        "bar", APIVersion: "version", FieldPath:  "desiredState.manifest.containers[2]", }, Reason:  "Started", Message: "some verbose message: 1", Source:  api.EventSource{Component: "eventTest"}, Count:   1, }, expectLog:    `Event(api.ObjectReference{Kind:"Pod", Namespace:"", Name:"foo", UID:"bar", APIVersion:"version", ResourceVersion:"", FieldPath:"desiredState.manifest.containers[2]"}): reason: 'Started' some verbose message: 1`, expectUpdate: false, }, } for _, item := range table { called := make(chan struct{}) testEvents := testEventSink{ OnCreate: func(event *api.Event) (*api.Event, error) { returnEvent, _ := validateEvent(event, item.expect, t) if item.expectUpdate { t.Errorf("Expected event update(), got event create()") } called <- struct{}{} return returnEvent, nil }, OnUpdate: func(event *api.Event) (*api.Event, error) { returnEvent, _ := validateEvent(event, item.expect, t) if !item.expectUpdate { t.Errorf("Expected event create(), got event update()") } called <- struct{}{} return returnEvent, nil }, } eventBroadcaster := NewBroadcaster() sinkWatcher := eventBroadcaster.StartRecordingToSink(&testEvents) logWatcher1 := eventBroadcaster.StartLogging(t.Logf) // Prove that it is useful logWatcher2 := eventBroadcaster.StartLogging(func(formatter string, args ...interface{}) { if e, a := item.expectLog, fmt.Sprintf(formatter, args...); e != a { t.Errorf("Expected '%v', got '%v'", e, a) } called <- struct{}{} }) recorder := eventBroadcaster.NewRecorder(api.EventSource{Component: "eventTest"}) recorder.Eventf(item.obj, item.reason, item.messageFmt, item.elements...) <-called <-called sinkWatcher.Stop() logWatcher1.Stop() logWatcher2.Stop() } } </ins>

Discussion:
Any node object related events from the kubelet does not get recorded in the apiserver. I digged a bit deeper and it looks like kubelet does not sets namespace to be empty and this results in the kubelet trying to post to `/api/<version/events', which a resource that is not exported by the apiserver.
cc
Change:
} config.diagnoseMissingEndpoints(eps) <del> framework.Failf("Failed to find expected endpoints:nTries %dnCommand %vnretrieved %vnexpected %vn", maxTries, cmd, eps, expectedEps) </del> <ins> return fmt.Errorf("failed to find expected endpoints, ntries %dnCommand %vnretrieved %vnexpected %v", maxTries, cmd, eps, expectedEps) </ins> } // GetSelfURL executes a curl against the given path via kubectl exec into a

Discussion:
What happened: final passing output: What you expected to happen: Probably if this test passes, it should be showing several real endpoints. I don't know exactly what it does, but im assuming that the output could be clarified a little. How to reproduce it (as minimally and precisely as possible): run and look at the logs. Anything else we need to know?: Environment: Kubernetes version (use ): 1.20 (sonobuoy)
/sig-network
/assign
/triage accepted
^ an interesting case here was that was but there was no SIG (typo in the command that did). should the label be only if there is label on the ticket? /sig network
the PR that adds triage/accepeted automation () was merged 3 hours ago, but it'll "actually" get rolled out in the next prow bump. Mostly when merges. Thanks for flagging though, appreciate it! :)
sorry, missed the actual question! :woman_facepalming: (need moar coffee!! :coffee: ) I don't think we should require a label for adding the label. In case someone comments with the following, we'd still want it to be valid.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
The above test cleans up the By directives and so on, After reading through the test more its clear that every test sets up a scaffold measures a property of that scaffold sometimes deletes something that is recovered in that scaffold (i.e. a pod that is behind a UDP service) So, the thing that was confusing I guess to me is that we validate empty conditions (i.e. no pods available) once we delete a nodePort svc. Meanwhile also noticed that the original work to clean up error reporting needed to cascade over to these tests as well.Have just finished all that, and also updated comments to reflect the Todo around the statistical computation (we have the ability to do extra polling via but we don't actually have any test that leverages this.As a follow on I guess it would be nice if we did have a test that confirmed that pods were load balanced evenly, esp with the new proliferation of different proxy technologies , I.e. a (or something similar