jiebi/CodeConvo huggingface dataset:
Change:
boilerplate="$2" shift 2 ;; <ins> "--extra-peer-dir") extra_peers+=("$2") shift 2 ;; </ins> *) echo "unknown argument: $1" >&2 return 1

Discussion:
Earlier it was possible to pass flag to while calling script. Now with the new script, is called under which doesnot support any other flags apart from , and . As it can be seen here there is no option to pass flag to conversion-gen Earlier in the script, it was considering all the inputs passed flag is supported by under the hood, but the function in script is not allowing the flag.
/cc
/sig api-machinery
/assign for code generation /triage accepted
/assign
Can you explain why you need this flag? What I found in k/k was that we don't actually need it at all.
You know what, my memory was faulty. We do use it (until I fix that, which is in a development branch, not merged). But we don't use it in any of the "submodule" configs.
A lot of the "magic" behind the conversion logic is very brittle. Can you help me understand where / how this impacts you?
I whipped up a quick patch but have not tested much:
We are using the flag several places in our script On removal of the flag, the autoConvert functions in. files has the error : Althoug I can see the function is already present at . But there is also a comment like Hence, I think there is a need for the in order to use this pkg.
I see. The component-base is something I didn't account for. If you apply the above patch, does the new argument to work for you?
Above patch throws an error for the cases when flag is not passed to function. Instead I followed this approach :
I'd rather not accumulate into a string - can you tell me what error it throws? Note, mine wants Also - is the argument here a dir (e.g. /home/me/src/foo/bar) or a pkg (e.g. ) ? I think it's actually a pkg, right?
You implementation throws error for the cases when we don't specify the option while calling , as shown below: For such cases I am getting following error
It seems to be an old-bash problem. Try this one?
Yes this is working fine.
OK. I'll prep a PR soon.
Thank you
Change:
len_sec=$((end_sec-start_sec)) set -o errexit kube::test::if_has_string "${output_message}" 'timed out waiting for the condition ' <del> kube::test::if_has_string "${len_sec}" '1' </del> <ins> test $len_sec -ge 1 && test $len_sec -le 2 </ins> # Clean deployment kubectl delete deployment dtest set +o nounset set +o errexit <del> } </del>  No newline at end of file <ins> } </ins>

Discussion:
test-cmd: runwaittests Dec 20 2022, 14:53:53 UTC+0100 No response No response /sig cli
/triage accepted /assign
Change:
}) } <del> // Ignore changes that only affect managed fields // timestamps. FieldManager can't know about changes // like normalized fields, defaulted fields and other // mutations. // Only makes sense when SSA field manager is being used if scope.FieldManager != nil { transformers = append(transformers, fieldmanager.IgnoreManagedFieldsTimestampsTransformer) } </del> createAuthorizerAttributes := authorizer.AttributesRecord{ User:            userInfo, ResourceRequest: true,

Discussion:
Sending a patch built from a typed client to SSA will force a write to etcd (and bump resourceVersion) since creationTimestamp is serialized to null. This is a follow-up of which doesn't solve the issue properly. Sending a no-op SSA request with creationTimestamp to null shouldn't do anything Kubectl apply an object with creationTimestamp null twice and see that it updates the object. Probably something like this would cause it:
/sig api-machinery /wg api-expression /triage accepted /assign /priority important-soon
Change:
import ( "bytes" <ins> "encoding/json" </ins> "fmt" "io" "strings"

Discussion:
and work in this pattern: first issuing a "GET" to the API server to retrieve the latest object, then adding the label/annotation to the object, and finally issuing an "PUT" with the modified object. The request will fail if the object stored in the server has been updated between the "GET" and "PUT", even if the update has no conflict with the label/annotate request. In such cases, instead of returning an error, should retry without disturbing the end user. There are two ways to implement this: in kubectl: simply retry the label/annotate process several times if the server rejected the request because the object has been updated. The only exception is when the is set, then kubectl shouldn't retry. the strategicMergePatch instead of calling Update at client-side. PATCH is more robust because PATCH does the "get, modify, update" in the server-side, so there is less chance to have a conflict, and PATCH will retry at the server-side (see ). We need to make some adaptions though: kubectl annotate/label has the , when it's false, kubectl should retrieve the latest object to confirm there is no existing annotation/label of the same key, and then proceed with issuing the patch. if the is set, [UPDATE:] we just need to specify the resourVersion in the patch, then it will be treated as a precondition by the UpdateResource() handler in the API server. I plan to take the first approach as an immediate fix.
Immediate need is to fix the flaky e2e test AIUI.
e2e? do we have an issue out there? is an immediate fix to the flake in test-
If this is for 1.1, it needs to be P0 at this point. Should it be?
Fwiw I use annotations both from cmd line as an admin and from scripts, to experiment with loadbalancer settings. In the case of the former, I've never really had a collision, and in the case of the latter my scripts know how to retry like we retry all other updates.
Thank you When used in scripts, the annotate and label commands have collisions frequently, e.g. in the test-, see . IMO, we shouldn't require users to retry in their scripts if we know there is a simple way to avoid the collisions. Anyway, and are sent to fix this.
Change:
ginkgo.It("should reject an unloaded profile", func() { status := runAppArmorTest(f, false, v1.AppArmorBetaProfileNamePrefix+"non-existent-profile") <del> expectSoftRejection(status) </del> <ins> gomega.Expect(status.ContainerStatuses[0].State.Waiting.Message).To(gomega.ContainSubstring("apparmor")) </ins> }) ginkgo.It("should enforce a profile blocking writes", func() { status := runAppArmorTest(f, true, v1.AppArmorBetaProfileNamePrefix+apparmorProfilePrefix+"deny-write")

Discussion:
Also appears to be failing on: Failures as of 01/05. /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon Guessing since all tests with apparmor started failing - maybe app armor config was removed or some PR submitted recently.
/assign
ci-cri-containerd-node-e2e-features Last green run: First failed run:
This () is the only PR merged in kubernetes during the time between: Test started yesterday at 8:11 PM passed after 13m50s. (more info) Test started yesterday at 9:11 PM failed after 16m6s. (more info) And it happens to be related to AppArmor:
Working on a fix in
Change:
var apiPodStatus api.PodStatus var podStatus *kubecontainer.PodStatus <ins> // Always generate the kubecontainer.PodStatus to know whether there are // running containers associated with the pod. podStatusPtr, apiPodStatusPtr, err := kl.containerRuntime.GetPodStatusAndAPIPodStatus(pod) if err != nil { glog.Errorf("Unable to get status for pod %q: %v", format.Pod(pod), err) return err } apiPodStatus = *apiPodStatusPtr podStatus = podStatusPtr </ins> if updateType == kubetypes.SyncPodCreate { // This is the first time we are syncing the pod. Record the latency // since kubelet first saw the pod if firstSeenTime is set. if !firstSeenTime.IsZero() { metrics.PodWorkerStartLatency.Observe(metrics.SinceInMicroseconds(firstSeenTime)) } <ins> // kubelet may have just been restarted. Re-use the last known // apiPodStatus. </ins> apiPodStatus = pod.Status apiPodStatus.StartTime = &unversioned.Time{Time: start} kl.statusManager.SetPodStatus(pod, apiPodStatus) <del> podStatus = &kubecontainer.PodStatus{ ID:        pod.UID, Name:      pod.Name, Namespace: pod.Namespace, } glog.V(3).Infof("Not generating pod status for new pod %q", format.Pod(pod)) } else { podStatusPtr, apiPodStatusPtr, err := kl.containerRuntime.GetPodStatusAndAPIPodStatus(pod) if err != nil { glog.Errorf("Unable to get status for pod %q: %v", format.Pod(pod), err) return err } apiPodStatus = *apiPodStatusPtr podStatus = podStatusPtr </del> <ins> glog.V(3).Infof("Reusing api pod status for new pod %q", format.Pod(pod)) </ins> } pullSecrets, err := kl.getPullSecretsForPod(pod)

Discussion:
As part of promoting TaintBasedEvictions to GA (), the docs around it will need to be updated to reflect the new status. /kind cleanup /sig scheduling
/assign
are you still planning to work on updating these docs?
sry, . assign by mistake. let me unassign.
What's the ETA? Till Friday? /assign
Hi Team - Seth on the 1.18 Docs team here, we have until 2/28 to get placeholder PRs in for docs for this release, please let me know if I can help!
Hi Jan just opened a PR here to reflect this change in the docs: could you please provide review to make sure we've properly listed this as GA?
Change:
} // SplitAndParseResourceRequest separates the users input into a model and fields <del> func SplitAndParseResourceRequest(inResource string, mapper meta.RESTMapper) (string, []string, error) { </del> <ins> func SplitAndParseResourceRequest(inResource string, mapper meta.RESTMapper) (string, string, []string, error) { </ins> inResource, fieldsPath := splitDotNotation(inResource) <ins> group, inResource := splitGroupFromResource(inResource) </ins> inResource, _ = mapper.ResourceSingularizer(expandResourceShortcut(inResource)) <del> return inResource, fieldsPath, nil </del> <ins> return group, inResource, fieldsPath, nil </ins> } // PrintModelDescription prints the description of a specific model or dot path func PrintModelDescription(inModel string, fieldsPath []string, w io.Writer, swaggerSchema *swagger.ApiDeclaration, r bool) error { recursive = r // this is global for convenience <del> apiVer := swaggerSchema.ApiVersion + "." </del> <ins> apiVer := apiutil.GetVersion(swaggerSchema.ApiVersion) + "." </ins> var pointedModel *swagger.NamedModel for i := range swaggerSchema.Models.List {

Discussion:
It would be nice if let me explain experimental resources to aid users ability to experiment.
It's possible this works today, but it was non-obvious how to use. Attempts:
cc
cc
No, this isn't supported, since current implementation only use v1 Client but not experimental Client.
do we need to fix this for 1.1?
How difficult do you think it would be to fix?
It has dependency on ServerAPIVersions(), for which we plan to make a clean-up PR. I guess it needs 3-4 days to get two PRs merged.
With , this can be fixed now. What's the expected behavior of ? I assume in case of , it should search hpa in both v1 and extensions/v1bata1, and determines hpa as a resource in the extensions group? BTW, the use of "api-version" flag is problematic It adds extra meaning to the generic "api-version" flag.
Change:
default: // This is a problem, report it and retry. logger.Error(err, "Creating gRPC stream for node resources failed") <del> // TODO (https://github.com/kubernetes/kubernetes/issues/123689): expontential backoff? </del> select { <del> case <-time.After(5 * time.Second): </del> <ins> case <-time.After(backOff.Get(backOffID)): backOff.Next(backOffID, time.Now()) </ins> case <-ctx.Done(): } }

Discussion:
has to retry after failures. This currently uses a fixed 5 second delay to avoid busy-looping. Exponential backoff might be better. /sig node /triage-accepted /priority important-longterm /lifecycle frozen /assign
/triage accepted
/assign
Change:
"github.com/onsi/ginkgo/v2" "github.com/onsi/gomega" <ins> "github.com/onsi/gomega/gstruct" "github.com/onsi/gomega/types" </ins> "k8s.io/kubernetes/test/e2e/framework" <ins> e2emetrics "k8s.io/kubernetes/test/e2e/framework/metrics" </ins> e2enode "k8s.io/kubernetes/test/e2e/framework/node" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper"

Discussion:
In commit we podresources-related metrics, to make sure the feature was monitoring-friendly. Because of a implementation bug, the metrics have been , they are updated correctly, but they are never registered, so they don't show up when doing like the podresources related metrics should be reported in the endpoint in the kubelet the kubelet, even the simplistic environment of the tests is sufficient sure to enable the and feature gates (on by default in kube = 1.25 at least) the podresources endpoint issuing and calls. The actual output is not relevant the metrics: The bug was introduced in the original commit <details</details<detailsNot relevant. </details<detailsNot relevant </details<detailsNot relevant </details<detailsNot relevant </details<detailsNot relevant </details
/sig node /assign
/cc /triage-accepted
/triage accepted /cc
Change:
"//pkg/security/apparmor:go_default_library", "//pkg/security/podsecuritypolicy/seccomp:go_default_library", "//pkg/security/podsecuritypolicy/util:go_default_library", <ins> "//vendor:k8s.io/apimachinery/pkg/api/equality", </ins> "//vendor:k8s.io/apimachinery/pkg/apis/meta/v1", "//vendor:k8s.io/apimachinery/pkg/apis/meta/v1/validation", "//vendor:k8s.io/apimachinery/pkg/labels",

Discussion:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: DigitalOcean OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others: What happened: when I do: it will run rolling update ONLY if there is a change. In case I do: Each time I run it - it will execute rolling update, which is misleading. What you expected to happen: I would like to have consistent behavior for Deployment and DaemonSet How to reproduce it (as minimally and precisely as possible): Create any DaemonSet with following:
Hmm, it shouldn't happen. TemplateGeneration is updated only when something changed. I will debug it.
I can reproduce this, and the DaemonSet is updated after every , even when nothing is changed. In , old/new DaemonSet template are seen as different with . I tried to change this part to use instead (needed to update code in validation as well), and the DaemonSet templates were then seen as the same, and thus the issue was gone. We used everywhere in the controllers. Is the right way to compare stuffs?
It's very strange. I tried to use pretty.Diff to print the differences but it returns empty slice. apiequality.Semantic.DeepEqual uses forked version of reflect.DeepEqual and it's little different from version in 1.7. will you prepare the patch?
The key of the reported DaemonSet config is its . Note that in the config file, (empty list); however, in the live DaemonSet object (created from the config file), (null list). That's why thinks they're different. If we use in the config file instead, won't change. From the field description, empty list and null list are different. Feel it's api machinery related
protobuf storage isn't able to store , so the object has that field set to when read back from storage. that is causing problems for that field in particular (where and have different meanings) see
cc for behavior of namespaces field
so it's not a DaemonSet bug
Well, still not sure whether Semantic.DeepEqual should be used or not. I'm still concerned with the behavior of the controller for other fields that can be populated with non-null empty lists by users, but serialize back out to null (or set omitempty)
deployments are using Maybe we should also switch?

If empty lists should be treated differently from null list, we should replace with in controller code.
that distinction is going away in all the fields I know of... I'm not super happy with Semantic.DeepEqual masking the difference between those two things, but that's probably the right thing for you to be using
Special meaning of [] was removed in I think a switch to Semantic.DeepEqual is still needed here
Filed
Change:
informers.Extensions().V1beta1().DaemonSets(), nil, // CloudProvider cs, <del> time.Second, // Node monitor grace period </del> <ins> time.Hour,   // Node monitor grace period </ins> time.Second, // Node startup grace period time.Second, // Node monitor period time.Second, // Pod eviction timeout

Discussion:
While lookint into , I spent few minutes looking into this test: And there is a problem that is relatively easy to reproduce. The problem is that we are running its test cases one by one. But nothing in the meantime is ensuring that the current state that the test assumes is reflected in scheduler. In particular the problem that I observed couple time is that: we finished one test case we call cleanupNodes [but we don't ensure that scheduler actually cleaned up this node] we start the next test case we try to schedule a pod that has some toleration (but shouldn't fit on our node) by accident the toleration make it fit on to the previous node so scheduler schedules it on the node from previous test case
/assign
Change:
*(newRS.Spec.Replicas) = newReplicasCount // Set new replica set's annotation <del> deploymentutil.SetNewReplicaSetAnnotations(d, &newRS, newRevision, false) </del> <ins> deploymentutil.SetNewReplicaSetAnnotations(d, &newRS, newRevision, false, maxRevHistoryLengthInChars) </ins> // Create the new ReplicaSet. If it already exists, then we need to check for possible // hash collisions. If there is any other error, we need to report it in the status of // the Deployment.

Discussion:
What happened: We created a Deployment and continuously updated an annotation on it periodically for a week. Eventually, we noticed errors in the controller-manager logs due to the annotation growing too large. Example annotations: controller-manager error: What you expected to happen: that do not change the revision number should not be to the revision history. revision history should be capped at a fixed number of elements, it should not be possible to have unbounded growth for Deployments that are frequently updated. How to reproduce it (as minimally and precisely as possible): a Deployment modify an annotation on it and note that the annotation gets the same number appended every time. Environment: Kubernetes version (use ):
/sig scalability Not 100% sure where this one fits, I couldn't determine which group owns the Deployment/ReplicaSet controllers, but this is a scalability problem
/sig apps
Agree with these, and if the limit is hit, the beginning of the history can be removed.
/assign
Change:
if err := o.Validate(); err != nil { t.Errorf("Unexpected error: %v", err) } <del> // FIXME soltysh: // since we have defaulting to localhost:8080 in staging/src/k8s.io/client-go/tools/clientcmd/client_config.go#getDefaultServer // we need to ignore the localhost:8080 server, when above gets removed this should be dropped too if err := o.Run(); err != nil && !strings.Contains(err.Error(), "localhost:8080") { </del> <ins> if err := o.Run(); err != nil { </ins> t.Errorf("Cannot execute version command: %v", err) } if !strings.Contains(buf.String(), "Client Version") {

Discussion:
/sig cli run (or just ). observe failure: xref:
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
Hi, I have filed to address this issue.
Thank you!
Change:
} } <del> func waitForVolumeAttachedToNode( </del> <ins> func waitForVolumeAttachStateToNode( </ins> t *testing.T, volumeName v1.UniqueVolumeName, nodeName k8stypes.NodeName, <ins> expectedAttachState cache.AttachState, </ins> asw cache.ActualStateOfWorld) { err := retryWithExponentialBackOff( time.Duration(500*time.Millisecond), func() (bool, error) { attachState := asw.GetAttachState(volumeName, nodeName) <del> if attachState == cache.AttachStateAttached { </del> <ins> if attachState == expectedAttachState { </ins> return true, nil } <del> t.Logf( "Warning: Volume <%v> is not attached to node  <%v> yet. Will retry.", volumeName, nodeName) </del> <ins> t.Logf("Warning: expected attach state: %v, actual attach state: %v. Will retry.", expectedAttachState, attachState) </ins> return false, nil }, ) attachState := asw.GetAttachState(volumeName, nodeName) <del> if err != nil && attachState != cache.AttachStateAttached { t.Fatalf( "Volume <%v> is not attached to node  <%v>.", volumeName, nodeName) </del> <ins> if err != nil && attachState != expectedAttachState { t.Fatalf("Volume <%v> is not in expected attach state: %v, actual attach state: %v", volumeName, expectedAttachState, attachState) </ins> } <ins> t.Logf("Volume <%v> is attached to node <%v>: %v", volumeName, nodeName, expectedAttachState) </ins> } func waitForVolumeAddedToNode(

Discussion:
pull-kubernetes-unit reconciler TestRunOneVolumeDetachFailNodeWithReadWriteOnce unknown, maybe recently? No response /sig storage
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
The test is still flaking but it is almost rare. Please see the link below for the test history. The root cause is that the detach operation is not triggered or completed within 100ms. 1) not triggered: 2) triggered but not completed: It seems no better way to fix it unless we increase sleep time in the test. i.e. (100ms -200ms) I'm not sure if it is valuable to fix it. cc what do you think?
any flake should be fixed even if it's rare.
/assign