jiebi/CodeConvo huggingface dataset:
Change:
} quotaLock.Lock() defer quotaLock.Unlock() <del> // Current policy is to set individual quotas on each volumes. </del> <ins> // Current policy is to set individual quotas on each volume, // for each new volume we generate a random UUID and we use that as // the internal pod uid. // From fsquota point of view each volume is attached to a // single unique pod. </ins> // If we decide later that we want to assign one quota for all <del> // volumes in a pod, we can simply remove this line of code. </del> <ins> // volumes in a pod, we can simply use poduid parameter directly </ins> // If and when we decide permanently that we're going to adopt // one quota per volume, we can rip all of the pod code out. <del> volumeuid := types.UID(uuid.NewUUID()) if pod, ok := dirPodMap[path]; ok && pod != volumeuid { return fmt.Errorf("requesting quota on existing directory %s but different pod %s %s", path, pod, volumeuid) </del> <ins> externalPodUid := poduid internalPodUid, ok := dirPodMap[path] if ok { if podUidMap[internalPodUid] != externalPodUid { return fmt.Errorf("requesting quota on existing directory %s but different pod %s %s", path, podUidMap[internalPodUid], externalPodUid) } } else { internalPodUid = types.UID(uuid.NewUUID()) </ins> } <del> oid, ok := podQuotaMap[volumeuid] </del> <ins> oid, ok := podQuotaMap[internalPodUid] </ins> if ok { if quotaSizeMap[oid] != ibytes { return fmt.Errorf("requesting quota of different size: old %v new %v", quotaSizeMap[oid], bytes) } <ins> if _, ok := dirPodMap[path]; ok { return nil } </ins> } else { oid = common.BadQuotaID }

Discussion:
I have kubernetes 1.24.7. I tried to use on formated volume. It works until first reboot. After reboot, I get messages: I expect that project quota can be assigned even after reboot. Use xfs for /var/lib/containerd with discard,quota,prjquota No response <details</details<detailsbaremetal </details<details</details<details</details<detailsrke2 </details<details</details
/sig node Can this be reproduced? Can this pod be recreated correctly if you force delete the pod?
/triage accepted
It can be reproduced. Pod is created if I remove . I can test force delete.
/assign we are looking into gate to understand if we need to keep it or deprecate it.
If I force delete pod, it does not start again:
/assign Let me check on the latest code with the fix
Change:
// generator pick up manually written conversion funcs from external packages. ExtraPeerDirs []string <ins> // Additional dirs to parse and load, but not consider for peers.  This is // useful when packages depend on other packages and want to call // conversions across them. ExtraDirs []string </ins> // SkipUnsafe indicates whether to generate unsafe conversions to improve the efficiency // of these operations. The unsafe operation is a direct pointer assignment via unsafe // (within the allowed uses of unsafe) and is equivalent to a proposed Golang change to

Discussion:
In the codegenerator we have: So basically we process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator. This is problematic, when regenerating conversions, we simply pass to input directories only those that were changed in the meantime: We should fix that - probably by passing all CONVERSIONDIRS as inputs to conversion-gen /kind-bug
I think this caused Not sure if was related yet.
It's the other way around - this is the main bug and root cause and the other that you linked is a consequence.
Also - FYI
I actually already started looking into it - so let me assign this.
is out for review
/triage accepted
Change:
}, "generateName": { SchemaProps: spec.SchemaProps{ <del> Description: "GenerateName is an optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided. If this field is used, the name returned to the client will be different than the name passed. This value will also be combined with a unique suffix. The provided value has the same validation rules as the Name field, and may be truncated by the length of the suffix required to make the value unique on the server.nnIf this field is specified and the generated name exists, the server will NOT return a 409 - instead, it will either return 201 Created or 500 with Reason ServerTimeout indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header).nnApplied only if Name is not specified. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency", </del> <ins> Description: "GenerateName is an optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided. If this field is used, the name returned to the client will be different than the name passed. This value will also be combined with a unique suffix. The provided value has the same validation rules as the Name field, and may be truncated by the length of the suffix required to make the value unique on the server.nnIf this field is specified and the generated name exists, the server will return a 409.nnApplied only if Name is not specified. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#idempotency", </ins> Type:        []string{"string"}, Format:      "", },

Discussion:
The error code of is 409. Is this an expected behavior? The doc seems to say no: NOT return a 409 - instead, it will either return 201 Created or 500 with Reason ServerTimeout indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header). seems to create which error code is 409. The error code of isn't 409. Or, the doc doesn't say "If this field is specified and the generated name exists, the server will NOT return a 409". Create a large number of Pods with generateName, and cause name conflicts. Just question: if the API is correct in returning 409 for a GenerateName-conflict, how do we determine that error? We want to retry when GenerateName conflict returns in most cases because the retry may solve this conflict. latest master (maybe after ) <details</details<details</details<details</details<details</details<details</details
Sorry if not an appropriate SIG. /sig api-machinery
/assign
It seems related to . If it's expected behavior, the document isn't correct..?
is a mistake. /unassign
Hi do you think this is a good first issue to tackle? If so, I would like to try contributing here.
/assign /triage accepted
Forgive me to ping other people who might know. /cc /cc /cc
I suspect we just failed to update the documentation.
Thanks Okay. I'll create the PR for that. /kind documentation /assign
Change:
if objectMeta.GetGeneration() > 0 { objectMeta.SetGeneration(objectMeta.GetGeneration() + 1) } return true, false, nil }

Discussion:
Use apiserver extension(APIService) interface, impl its method to gracefully control resource deletion, when the field is nil, will lead to panic!! To first check if is nil, then get its value. Use apiserver extension(APIService) strategy, impl this function below will lead to panic: As the field is a int64 pointer, need to be careful when init the struct. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
/triage accepted
Change:
// we have a spurious APIService that we're managing, delete it (5A,6A) case desired == nil: <del> return c.apiServiceClient.APIServices().Delete(curr.Name, nil) </del> <ins> opts := &metav1.DeleteOptions{Preconditions: metav1.NewUIDPreconditions(string(curr.UID))} err := c.apiServiceClient.APIServices().Delete(curr.Name, opts) if apierrors.IsNotFound(err) || apierrors.IsConflict(err) { // deleted or changed in the meantime, we'll get called again return nil } return err </ins> // if the specs already match, nothing for us to do case reflect.DeepEqual(curr.Spec, desired.Spec):

Discussion:
k8s version: v1.9.3 When I create customresourcedefinition, There is error like Operation cannot be fulfilled on "": the object has been modified; please apply your changes to the latest version and try again . apiVersion: kind: CustomResourceDefinition metadata: name: annotations: "": crd-install labels: app: istio-pilot spec: group: names: kind: VirtualService listKind: VirtualServiceList plural: virtualservices singular: virtualservice categories: istio-io networking-istio-io scope: Namespaced version: v1alpha3 So what is the reason of it?
a few questions: where are you seeing the error, in the apiserver log or in the output of the kubectl command? what kubectl command are you using to create the object? are you running HA apiservers?
The log is shown by apiserver. I run k8s in HA apiservers. The command I used is "kubectl apply -f "+file.
API servers attempt to update CRD status to indicate whether the names were available. In an HA apiserver setup, the API servers race to do so, and all but the first lose the race with a resource conflict error. That is not unexpected. Opened to avoid logging normal API responses in that scenario.
Thanks ! But I want to know whether the CRD has been set successfully in HA apiservers ? I use the command " kubectl get crd -o yaml" and get the following results. ! I see its status is true. But when i create a virtualservices, it returns error. Error from server (Timeout): error when creating "cms-api-": Timeout: request did not complete within allowed duration ! So i want to know how to solve this error.
/assign
Excuse me. Do you have some greate ideas to solve this issue??
There is a PR for this sent by
I see your request is timed-out not failed. In HA, I expect the request to fail in the first seconds of the CRD creation, but after that it should go through. I need more logs during this timeout or a consistent way to reproduce it.
Change:
f.t.Errorf("error syncing deployment: %v", err) } <del> actions := f.client.Actions() </del> <ins> actions := filterInformerActions(f.client.Actions()) </ins> informerActions := 0 for i, action := range actions { <del> if len(action.GetNamespace()) == 0 && (action.Matches("list", "pods") || action.Matches("list", "replicasets") || action.Matches("list", "deployments") || action.Matches("watch", "pods") || action.Matches("watch", "replicasets") || action.Matches("watch", "deployments")) { informerActions++ continue } </del> if len(f.actions)+informerActions < i+1 { f.t.Errorf("%d unexpected actions: %+v", len(actions)-len(f.actions), actions[i:]) break

Discussion:
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
did you see this failure by any chance while working on
No. I didn't see that one.
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
Found it. Opened
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
Running this test 8 times in a loop on my workstation, I was able to get a reliable failure signal.
This is still failing. Please take a look into
Change:
. "github.com/onsi/gomega" ) <del> var _ = SIGDescribe("PodPreset", func() { </del> <ins> var _ = SIGDescribe("[Feature:PodPreset] PodPreset", func() { </ins> f := framework.NewDefaultFramework("podpreset") var podClient *framework.PodClient

Discussion:
Need to follow-up on and i assigned it to you because turning off settings/v1alpha1 requires some changes in the tests.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig api-machinery
/assign
did you mean I should add a priority label?
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
"flag" "fmt" "net" <ins> "sort" </ins> "strings" "github.com/golang/glog"

Discussion:
/kind bug What happened: When building kubernetes-1.7.0 packages for openSUSE, results differ for each build in and other man pages. coming from that uses and probably sets do not have any specific order, so it would need to be sorted on output. What you expected to happen: Every build should give identical results. See https://reproducible- for why this matters. How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: Environment: Kubernetes version: 1.7.0 OS (e.g. from /etc/os-release): openSUSE Tumbleweed
/sig release
somehow this bug seems to have been forgotten - can you help getting the right people to have a look?
- can you please confirm that PR works for you?
I tested it and it looks good.
/assign I enjoy reading my highlights to find the issue has already been addressed. :)
Sorry this wasn't addressed sooner. It does seem like it fell into a black hole, and pinging was the right way to resolve that. :)
/area build-release
related to /reopen
Reopening this issue. <detailsIn response to : related 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
Change:
kube::log::status "go.mod: update staging references" # Prune <del> go mod edit -json | jq -r '.Require[]? | select(.Version == "v0.0.0")                 | "-droprequire (.Path)"'     | xargs -L 100 go mod edit -fmt go mod edit -json | jq -r '.Replace[]? | select(.New.Path | startswith("./staging/")) | "-dropreplace (.Old.Path)"' | xargs -L 100 go mod edit -fmt </del> <ins> go mod edit -json  | jq -r '.Require[]? | select(.Version == "v0.0.0")                 | "-droprequire (.Path)"'  | xargs -L 100 go mod edit -fmt go mod edit -json  | jq -r '.Replace[]? | select(.New.Path | startswith("./staging/")) | "-dropreplace (.Old.Path)"'  | xargs -L 100 go mod edit -fmt </ins> # Readd <del> kube::util::list_staging_repos | xargs -n 1 -I {} echo "-require k8s.io/{}@v0.0.0"                  | xargs -L 100 go mod edit -fmt kube::util::list_staging_repos | xargs -n 1 -I {} echo "-replace k8s.io/{}=./staging/src/k8s.io/{}" | xargs -L 100 go mod edit -fmt </del> <ins> kube::util::list_staging_repos  | while read -r X; do echo "-require k8s.io/${X}@v0.0.0"; done  | xargs -L 100 go mod edit -fmt kube::util::list_staging_repos  | while read -r X; do echo "-replace k8s.io/${X}=./staging/src/k8s.io/${X}"; done  | xargs -L 100 go mod edit -fmt </ins> # Phase 3: capture required (minimum) versions from all modules, and replaced (pinned) versions from the root module

Discussion:
I ran update- Not to see a ton of errors Kubernetes version (use ): HEAD of master
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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 architecture (code organization / dependencies) /sig testing (hack scripts)
/triage accepted
Change:
fakeClient := fake.NewSimpleClientset(&networkingv1.Ingress{ ObjectMeta: metav1.ObjectMeta{ <del> Name:      "bar", </del> <ins> Name: "bar", Labels: map[string]string{ "id1": "app1", "id2": "app2", }, </ins> Namespace: "foo", }, Spec: networkingv1.IngressSpec{

Discussion:
When command 'kubectl describe ing' Name: test-ing Namespace: practice Address: 10.10.01.10 Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found) TLS: test terminates Rules: Host Path Backends ---- ---- -------- / test-svc:80 (<none) Annotations: nginx Events: <noneResult has no information about labels. But Pod, Deployment, Service resources has label information like below. Name: test-room-test-mjsbz Namespace: test Priority: 0 Node: aks-test-test-test/22.22.222. Start Time: Fri, 09 Jul 2021 05:45:26 +0000 Labels: app=test pod-template-hash=test role=mediatest Why ingress has no information about labels? Actually when delete ingresss with labels is working correctly. Kubernetes version (use ): 1.18.14 Cloud provider or hardware configuration: AKS (Azure) OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig
/sig
/sig cli
/assign
/assign
/triage accepted /remove-kind bug /kind feature
Change:
podInPendingStateTimeout  = time.Second * 60 // how long to wait for a pod to stay in pending state ) <del> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation][NodeFeature:DynamicResourceAllocation]", func() { </del> <ins> var _ = ginkgo.Describe("[sig-node] DRA [Feature:DynamicResourceAllocation]", func() { </ins> f := framework.NewDefaultFramework("dra-node") f.NamespacePodSecurityEnforceLevel = admissionapi.LevelBaseline

Discussion:
sig-node : DRA related tests are failing and 2 other DRA related tests. Both jobs started failing on 7th June As per the logs DRA plugin is not getting registered to kubelet Jobs started failing after merging As per , CDI is not available out of the box for containerd which may be the reason for failure of the jobs. /sig node
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
/cc
/cc
Looks like I shouldn't have labeled DRA Node tests as NodeFeature. However, re-labeling it NodeAlphaFeature would not work either - would start to fail. I'm going to remove . This should help.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Not fixed yet, pending
Change:
return } fmt.Printf("[bootstrap] Successfully established connection with endpoint %qn", apiEndpoint) // connection established, stop all wait threads <del> close(stopChan) </del> once.Do(func() { <ins> close(stopChan) </ins> clientConfig = ac.clientConfig }) }, retryTimeout*time.Second, stopChan)

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No. What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubeadm join kubeadm join crash kubeadm close of closed channel Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-10-21T02:48:38Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"} kubeadm version (use ): kubeadm version: version.Info{Major:"1", Minor:"5+", GitVersion:"v1.5.0-alpha.2.380+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-11-02T14:58:17Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS Kernel (e.g.

): 3.10.0-327.36.1.el7.x8664 SMP Sun Sep 18 13:04:29 UTC 2016 x8664 x8664 x8664 GNU/Linux Install tools: yum Others: What happened: kubeadm crash when join mulitple API endpoints What you expected to happen: How to reproduce it (as minimally and precisely as possible): join mulitple API endpoints Anything else do we need to know: kubeadm output:
It is already fixed by
seems not fixed, still having this issue with master code
I'm also running into this with a clean build from master kubeadm version kubeadm output kubectl version Environment kernel versionOS version
seems not fixed. I met the same issue . kubeadm version: kernel version: os version: kubectl version: error output by "kubeadm join --token=. 10.47.217.91":
I can also repro this issue - I will work on contributing a fix.
I can also reproduce this issue, following the guide with packaged versions of all the components
Change:
// CreateKubeAPIServerConfig creates all the resources for running the API server, but runs none of them func CreateKubeAPIServerConfig(s *options.ServerRunOptions, nodeTunneler tunneler.Tunneler, proxyTransport http.RoundTripper) (*master.Config, informers.SharedInformerFactory, clientgoinformers.SharedInformerFactory, *kubeserver.InsecureServingInfo, aggregatorapiserver.ServiceResolver, error) { <del> // register all admission plugins RegisterAllAdmissionPlugins(s.Admission.Plugins) </del> // set defaults in the options before trying to create the generic config if err := defaultOptions(s); err != nil { return nil, nil, nil, nil, nil, err

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The current help message from kube-apiserver is wrong. It shows only the 'NamespaceLifecycle' plug-in is available, and the default value is . Users cannot know what are the available plug-ins, and they get confused where comes from. What you expected to happen: The correct output should be this: How to reproduce it (as minimally and precisely as possible): Run using master or at least 1.7.2. Anything else we need to know?: This is a regression introduced when refactoring code into generic server code. Environment: Kubernetes version (use ): 1.7.2+ ? Cloud provider or hardware configuration**: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: Any Others: None
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
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
Yes, it is really exist. If no guys works on this, i will pick it up.
Thanks for confirming this. I'm already working on it. Will submit pr in minutes.
cool. :)