jiebi/CodeConvo huggingface dataset:
Code change:
//	    - ... zero or more // // * every specified field or array in s is also specified outside of value validation. <ins> // * metadata at the root can only restrict the name and generateName, and not be specified at all in nested contexts. </ins> // * additionalProperties at the root is not allowed. func ValidateStructural(s *Structural, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{}

Related discussion:
text: We allow CRD authors to write . Currently we don't restrict writing validation for , which means people can have . For example, people can have additive name constraints (require CR to be ) with the following schema: This brings us two questions: do we if "metadata" is included in the schema: simplest option is to publish standard metav1.ObjectMeta schema info, and use any CRD-specified "metadata" properties as additive validation (just like in-tree types do, publishing standard ObjectMeta schema info, and implementing type-specific name validation internally) alternatively, we can try merging user-specified metadata schema with the standard one. Technically people should only add extra validation to existing metadata properties (adding new fields to metadata won't work since they will be pruned by built-in validation first), but it's unclear to me how arbitrary people may want the metadata validation to be term question is whether to allow people specifying metadata validation at all, or just allow a subset (like name validation) in CRD v1 /sig api-machinery /area custom-resources cc
What is the difference between these two? I mean the end result is the same right? The only thing that can be is validation. Nothing else works unless you are considering extensions?
The former means we drop/hide user-specified metadata schema when we publish CRD OpenAPI. We still validate user-specified constraints on server side, but client-side validation won't see them. The latter enables client-side user-specified metadata validation.
If it's possible to merge with standard metadata schema info, or at the cost of not publishing the standard schema. My inclination would be to publish the complete standard schema for metadata/apiVersion/kind, which we know is complete and accurate, and use and user-specified schema for those fields as addition validations server side
Code change:
kr.CustomMustRegister(cs...) } <ins> // BuildVersion is a helper function that can be easily mocked. var BuildVersion = version.Get </ins> func newKubeRegistry(v apimachineryversion.Info) *kubeRegistry { r := &kubeRegistry{ PromRegistry:     prometheus.NewRegistry(),

Related discussion:
text: What would you like to be : Once a metric be deprecated, we should update the unit test accordingly if there is any. We need to work out a way for a unit test freely select codebase version, and also should make sure the unit test won't fail in the subsequent release. Why is this needed: Deprecated also needs to be protected. /sig instrumentation /assign
Code change:
// Store in cache c.lock.Lock() <ins> defer c.lock.Unlock() </ins> c.cache[key] = data <del> c.lock.Unlock() </del> // Remove in flight entry c.inFlightLock.Lock() <ins> defer c.inFlightLock.Unlock() </ins> delete(c.inFlight, key) <del> c.inFlightLock.Unlock() </del> }() return result }

Related discussion:
text: Failed due to an apparently unrelated PR: https://travis-
Problem here is that I left a small chance of a double-call in my parallelized cache. Didn't realize this was being tested. Will fix.
Code change:
clientset "k8s.io/client-go/kubernetes" kubeadmapi "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm" kubeadmconstants "k8s.io/kubernetes/cmd/kubeadm/app/constants" <ins> "k8s.io/kubernetes/cmd/kubeadm/app/features" </ins> kubeadmutil "k8s.io/kubernetes/cmd/kubeadm/app/util" "k8s.io/kubernetes/cmd/kubeadm/app/util/apiclient" "k8s.io/kubernetes/pkg/api/legacyscheme"

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Currently, IPVS proxier does not run any e2e test cases. What you expected to happen: I think it's important to create test suite for IPVS in upstream CI which will help a lot in moving IPVS existing alpha. Anything else we need to know?: Let's work together. /sig network
Self /assign
There are to ways to do this work: , but doesn't support any kube-proxy config right now, so I had this pr , and also, need support it too, see this pr: kubernetes/kubernetes-anywhere build cluster. See this pr: kubernetes/test-infra The second way is much easier and faster, but I was told they gonna deprecated the , so in the long term, we still need and 's support. If anybody have better way or have some suggestion about this, please let me know, I'll be really appreciate, Thanks.
Code change:
} func (flunderStrategy) NamespaceScoped() bool { <del> return false </del> <ins> return true </ins> } func (flunderStrategy) PrepareForCreate(ctx genericapirequest.Context, obj runtime.Object) {

Related discussion:
text: 1 tests failed, 11 jobs failed, 241 builds failed. Failure stats cover 1 day time range '17 Aug 2017 22:57 UTC' to '18 Aug 2017 22:57 UTC'.
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
Seeing this failure on the e2e release-master-blocking https://k8s- Example failure https://k8s- Looks like an RBAC issue cc
this is currently blocking the alpha.3 release
looks like this new test was by in which was merged about 6 days ago and is failing consistently
This has started failing again on our GKE test suite https://k8s- https://k8s- cc
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
/assign
Seems to be flaking now with the error: https://k8s-
- we need to determine (today if possible) if this is truly release blocking. If so, please add the release-blocker label. And, if not, how do we best continue work on this for 1.8.x/1.9.0?
this test has two passes and four failures on the same commit I'm seeing gke-specific authz grants in that test that are incorrect: That commit removed the wait for the authz grant to become effective (which can lead to flakes), and granted superuser permissions to all users, which is incorrect and invalidates any other authz-related tests run in parallel with this test
cc
I can add the wait back.
Code change:
} func (flunderStrategy) NamespaceScoped() bool { <del> return false </del> <ins> return true </ins> } func (flunderStrategy) PrepareForCreate(ctx genericapirequest.Context, obj runtime.Object) {

Related discussion:
text: edit: and fix the test given admin to all authenticated users.
Actually after staring at this test for about half an hour I can't figure out what different users exist or what permissions they're being granted. ClientSet, InternalClientset, and AggregatorClient are all initialized from the same config so I don't see how one would be able to create an RBAC binding but another would fail later. any thoughts here?
I honestly think the gke specific BindClusterRole is a red-herring. It is needed so the client has permission to perform one of the setup steps. (I think it was either to create the wardler cluster role or to bind that role to the anonymous user) Once that setup step is complete we no longer need the that cluster role bound and so I don't think its related.
The gke authorizer allows the “bind” verb, so the client can create a binding to the cluster-admin. It cannot create a role directly unless it has permissions via RBAC. Since we don’t have a way to determine the username associated with , binding to all authenticated users is what was done as a workaround.
I agree that the point at which the tests are failing indicate that the previous authorization issues are not the cause.
/open
/reopen
So a lot more information to work with now but the error is still occurring. I am still looking into this.
any update on the investigation?
Friendly v1.8 release team ping. This failure still seems to be happening, is this actively being worked? Does this need to be in the v1.8 milestone?
Code change:
} } <del> func TestHistogramClear(t *testing.T) { samples := []float64{0.5, 0.5, 0.5, 0.5, 1.5, 1.5, 1.5, 1.5, 3, 3, 3, 3, 6, 6, 6, 6} bounds := []float64{1, 2, 4, 8} h := samples2Histogram(samples, bounds) if *h.SampleCount == 0 { t.Errorf("Expected histogram .SampleCount to be non-zero") } if *h.SampleSum == 0 { t.Errorf("Expected histogram .SampleSum to be non-zero") } for _, b := range h.Bucket { if b.CumulativeCount != nil { if *b.CumulativeCount == 0 { t.Errorf("Expected histogram bucket to have non-zero comulative count") } } } h.Clear() if *h.SampleCount != 0 { t.Errorf("Expected histogram .SampleCount to be zero, have %v instead", *h.SampleCount) } if *h.SampleSum != 0 { t.Errorf("Expected histogram .SampleSum to be zero, have %v instead", *h.SampleSum) } for _, b := range h.Bucket { if b.CumulativeCount != nil { if *b.CumulativeCount != 0 { t.Errorf("Expected histogram bucket to have zero comulative count, have %v instead", *b.CumulativeCount) } } if b.UpperBound != nil { *b.UpperBound = 0 } } } </del> func TestHistogramValidate(t *testing.T) { tests := []struct { name string

Related discussion:
text: I would do something like the following: if a step has collectMetrics:false, we wait for them to finish scheduling, and then we take a snapshot of the histogram. Then for the next step that has collectMetrics:true, we take the diff with the latest snapshot to report the results. This might not be perfect, as we don't control if the metrics have finished syncing when we take the snapshot. But I think that's fine. Would doing this be possible? Now, if we have steps that run in parallel, one with collectMetrics:false and another with collectMetrics:true, then this doesn't work. Note that I don't know the details of how the gatherer works.
That adheres to what I have in my mind - we can only manage this on client side. I think it's fine. As we are already fetching the "snapshot" when pods get scheduled when equals true. True. An alternative is to design the case to be like: the step with to employ Pods that are all unschedulable, and then specify a custom metric "schedulere2eschedulingdurationseconds[result="unschedulable"]" to target a particular histogram instead of all histograms (default option) inside a histogramVec. Note this can only be possible when and some subsequent changes get in place.
We might just call Histogram.Clear() method which will clear what has been collected so far at the end of phase: Assuming individual phases have no pods in common and each phase can clear metrics without affecting other phases. Though, as said, it will work only for serial case.
WDYT
I'm afraid doesn't work. That was my initial thought as well, but no luck. I guess it's b/c, theoretically, we cannot reset a metric on the server side - Promoetheus' model doesn't support this. But let me know if I miss anything.
The performance tests assume all the metrics all gathered and accessed in the same binary. As long as that's the case, works.
Code change:
} } <del> func TestHistogramClear(t *testing.T) { samples := []float64{0.5, 0.5, 0.5, 0.5, 1.5, 1.5, 1.5, 1.5, 3, 3, 3, 3, 6, 6, 6, 6} bounds := []float64{1, 2, 4, 8} h := samples2Histogram(samples, bounds) if *h.SampleCount == 0 { t.Errorf("Expected histogram .SampleCount to be non-zero") } if *h.SampleSum == 0 { t.Errorf("Expected histogram .SampleSum to be non-zero") } for _, b := range h.Bucket { if b.CumulativeCount != nil { if *b.CumulativeCount == 0 { t.Errorf("Expected histogram bucket to have non-zero comulative count") } } } h.Clear() if *h.SampleCount != 0 { t.Errorf("Expected histogram .SampleCount to be zero, have %v instead", *h.SampleCount) } if *h.SampleSum != 0 { t.Errorf("Expected histogram .SampleSum to be zero, have %v instead", *h.SampleSum) } for _, b := range h.Bucket { if b.CumulativeCount != nil { if *b.CumulativeCount != 0 { t.Errorf("Expected histogram bucket to have zero comulative count, have %v instead", *b.CumulativeCount) } } if b.UpperBound != nil { *b.UpperBound = 0 } } } </del> func TestHistogramValidate(t *testing.T) { tests := []struct { name string

Related discussion:
text: We already call in the code:
That was my understanding as well, but no luck :( Here is a diff to call in case when "concreteOp.CollectMetrics" is false: <details<summaryDiff:</summary<p</p</detailsAnd below is the output - it's still 1500 (500 init pods plus 1000 measured pods) instead of 1000 being benchmarked: <details<summaryOutput:</summary<p</p</details
Also, if you run the tests and together, the result proves doesn't work as expected:
But I do find a way to fix this: .
Code change:
"net/http" "path" "path/filepath" <ins> "runtime" </ins> "sync" "time"

Related discussion:
text: What happened: I have a Kubernetes Cluster with 2 Windows Server 2019 Core VMs as worker nodes. I upgraded first the cluster, and then the first Windows node following the docs here: Every step ran without issue, but the kubelet service was not started. This was not immediately obvious, since "restart-service kubelet" does not propagate the error. I think "start-service kubelet" would be better advice. The logs said: After changing the value of cgroupDriver manually in from "systemd" to "cgroupfs", the kubelet started successfully. What you expected to happen: One of 2 things: Either the Windows upgrade docs telling me what I need to do to fix this, or the kubeadm not breaking the configuration for windows in the first place. How to reproduce it (as minimally and precisely as possible): a windows node to a Kubernetes v1.19 cluster via kubeadm the cluster via kubeadm the Windows node following the docs Anything else we need to know?: Environment: Kubernetes version (use ): 1.20.1 Cloud provider or hardware configuration: OS (e.g: ): Windows Server 2019 Core Kernel (e.g. ): Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others: /sig windows
this may cause by the default value of defaultCgroupDriver cgroupfs Would you provide the from Windows node?
/assign
kubeadm doesn't do anything about cgroup drivers on Windows because cgroups don't exist on Windows. ideally the kubelet checks about this should be skipped entirely in dockershim for non-Linux.
! However, windows docker return as cgroupfs.
probably 's output is the same structure on all OSes with being a default value. this field should not be checked on Windows at all.
/retitle kubelet: don't check for the Docker cgroup driver on Windows
adding since the PR is favorable. /triage accepted
Code change:
# Cluster Role # ################ <ins> kubectl "${kube_flags[@]}" api-resources </ins> if kube::test::if_supports_resource "${clusterroles}" ; then record_command run_clusterroles_tests fi

Related discussion:
text: As the RBAC role need to be related to resources. I think we could use a command to get the supported resources. ref to
This would be cool.
I thought we a command that listed resources in the discover doc a long time ago.
is just the versions, but principle is the same. We want to list all the types, their resources, and tie that back to "explain".
What's the best way to determine this information currently? I'm having difficulty figuring out the exact set of permissions (and how they would be written in an RBAC role) for any given kubectl command. The documentation for this right now is split across multiple places and certain things are not explained at all. Specifically, it's difficult to determine which "API verb" is used for which operations. Take as an example. It's unclear if the way to allow this is to use the "proxy" subresource of a pod or service with "get"/"create"/etc. verbs, or to use the "proxy" verb with the resource (pod, service) directly. is a similar case. The almost works for this purpose, but it's still difficult. Operations for a given resource are grouped into categories like write, read, status, and proxy, but these things don't obviously correlate with API verbs. Again, proxy is especially confusing as there is no mention of a proxy "verb". The API operations are only shown using their HTTP verbs. One thing that could help on this document would be a section on the right column under "kubectl command" that shows exactly the rule needed in an RBAC role to allow this command via kubectl. And even then, that assumes an exact 1-to-1 mapping between API endpoints and kubectl commands, which I doubt is always the case. (For example, port fowarding to a pod seems to require both a GET on the pod resource and a CREATE on a port forward subresource.) There also needs to be better documentation about how this information could have been determined in the first place. I've resorted to manually looking through API requests made with but even then it's difficult to figure out. Amusingly, I was the one who wrote which is referenced in the original issue description (as well as the table explaining verbs in ).
Code change:
# Cluster Role # ################ <ins> kubectl "${kube_flags[@]}" api-resources </ins> if kube::test::if_supports_resource "${clusterroles}" ; then record_command run_clusterroles_tests fi

Related discussion:
text: tl;dr: It's too difficult right now to go from "I want a user to be able to run " to "here is the RBAC rule to use for that" for any case where there isn't a specific example shown in the docs.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
It seem that relative PR stop updated. If this issue still valuable, i will help fix it
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Code change:
{Type: v1.NodeMemoryPressure, Status: v1.ConditionFalse}, {Type: v1.NodeDiskPressure, Status: v1.ConditionFalse}, {Type: v1.NodeNetworkUnavailable, Status: v1.ConditionFalse}, <del> {Type: v1.NodeInodePressure, Status: v1.ConditionFalse}, </del> } return node }(),

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup What happened: It seems kubelet did not update inode pressure; and only test codes are using . So prefer to deprecate or remove it directly. (seems no node-misc group :). )
Code change:
// +k8s:deepcopy-gen=package <del> package testing </del> <ins> package testing // import "k8s.io/apiserver/pkg/storage/testing" </ins>

Related discussion:
text: Look at one of the directories under (Please don't pick more than one directory for one PR as it will cause issues for reviewers) Find all the files named (example find -name ) See the following link it has a this tells tools how this package needs to be imported. So we should ensure that each has an import Add a description appropriate to the package (similar to the one below) Look through sub directories and see if there are any other important directories that are likely to be used by outside users and add a Why are we doing this? We perfer to use vanity urls instead of directly using to refer to code, so this helps ensure that tools honor our wish. See It would be good to have some package level documentation since these directories under staging/ are meant to be for use by folks outside of kubernetes github org. /good-first-issue
/kind documentation /sig architecture
currently working my through Not going to use / assign since there could be a number of PRs for this issue.
/lifecycle active /good-first-issue edit: hmm..
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /lifecycle active /good-first-issue 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
May I try on
IIUC this means that there needs to be a even at the root of the repo? Then how does work? :thinking:
Hi , can I make a PR for this directory ?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .
Code change:
// +k8s:deepcopy-gen=package <del> package testing </del> <ins> package testing // import "k8s.io/apiserver/pkg/storage/testing" </ins>

Related discussion:
text: /lifecycle rotten
I guess this is still not done, was supposed to partially fix this issue. /reopen
Reopened this issue. <detailsIn response to : I guess this is still not done, was supposed to partially fix this issue. 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
/remove-lifecycle rotten /area code-organization
Code change:
<del> kind: ReplicationController apiVersion: v1 </del> <ins> apiVersion: extensions/v1beta1 kind: Deployment </ins> metadata: name: etcd <del> creationTimestamp: </del> spec: strategy: type: Recreate <del> resources: {} triggers: - type: ConfigChange </del> replicas: 3 selector: <del> name: etcd </del> <ins> matchLabels: name: etcd </ins> template: metadata: <del> creationTimestamp: </del> labels: name: etcd spec:

Related discussion:
text: Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Vagrant OS (e.g. from /etc/os-release): CoreOS Kernel (e.g. ):Install tools: Vagrant & Others: What happened: What you expected to happen: Success How to reproduce it (as minimally and precisely as possible): Followed instructions at Tried to run Received: Anything else do we need to know: From googling, it seems several of the fields in the config are for when using OpenShift origin. But creating the replication controller is a prerequisite to launching OpenShift Origin. Chicken & egg problem.