jiebi/CodeConvo huggingface dataset:
Code change:
} } <ins> func TestRollingUpdateApplyRevision(t *testing.T) { set := newStatefulSet(1) set.Status.CollisionCount = new(int32) currentSet := set.DeepCopy() currentRevision, err := newRevision(set, 1, set.Status.CollisionCount) if err != nil { t.Fatal(err) } set.Spec.Template.Spec.Containers[0].Env = []v1.EnvVar{{Name: "foo", Value: "bar"}} updateSet := set.DeepCopy() updateRevision, err := newRevision(set, 2, set.Status.CollisionCount) if err != nil { t.Fatal(err) } restoredCurrentSet, err := ApplyRevision(set, currentRevision) if err != nil { t.Fatal(err) } if !reflect.DeepEqual(currentSet.Spec.Template, restoredCurrentSet.Spec.Template) { t.Errorf("want %v got %v", currentSet.Spec.Template, restoredCurrentSet.Spec.Template) } restoredUpdateSet, err := ApplyRevision(set, updateRevision) if err != nil { t.Fatal(err) } if !reflect.DeepEqual(updateSet.Spec.Template, restoredUpdateSet.Spec.Template) { t.Errorf("want %v got %v", updateSet.Spec.Template, restoredUpdateSet.Spec.Template) } } </ins> func TestGetPersistentVolumeClaims(t *testing.T) { // nil inherits statefulset labels

Related discussion:
text: /unassign Sorry, I do not have enough time for this, anyone interested could take it from here.
I don't think the problem comes from your YAML, the problem comes from the controller that doesn't update the fields properly.
/assign
Code change:
} } <del> func (i *indexedWatchers) terminateAll() { </del> <ins> func (i *indexedWatchers) terminateAll(objectType reflect.Type) { if len(i.allWatchers) > 0 || len(i.valueWatchers) > 0 { glog.Warningf("Terminating all watchers from cacher %v", objectType) } </ins> i.allWatchers.terminateAll() for index, watchers := range i.valueWatchers { watchers.terminateAll()

Related discussion:
text: Multiple, for example: Since See above The test tolerations are now to strict: No response /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
I think it's from if you check the cri-o versions the succeessful one was and the failing was
Working on a fix in
cc
/reopen need to bump in kube as well to fully get the fix
Reopened this issue. <detailsIn response to : /reopen </details
Code change:
}, "required": [ "currentReplicas", <del> "desiredReplicas", "conditions" </del> <ins> "desiredReplicas" </ins> ], "type": "object" },

Related discussion:
text: <!-- 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 --Serializing a v2beta2 HorizontalPodAutoscaler with (and ) produces yaml that cannot be applied due to a ValidationError on the field which is under the optional field . A valid HPA serialized with should be able to be applied to the cluster with no validation errors, without filling out the optional field. Other valid objects (such as Namespaces and Deployments) can be applied directly, without filling out their optional fields. Run this to generate the serialized yaml (same outcome with both and functions) Running the go code should yield this yaml: Writing the above yaml to a file and applying it (with ) will result in: Kubernetes version (use ): Server: v1.20.2, Client: v1.20.4 go version: go1.16 darwin/amd64 has: cc cc
/sig api-machinery /sig autoscaling /sig cli
/assign /triage accepted
marking conditions as +optional in the API type would resolve the client-side apply error
It would remove the validation error, but I'd be concerned about any side effects or unwanted outcomes when moving that field from required to optional. A somewhat analogous field is required. But if you anticipate this won't change much else, that will work.
Client-side validation is non-authoritative, and problematic for the reasons described in this issue ... the client is disallowing a request the server would actually have no problems with. No field the server would permit to be empty (e.g. succeeds with ) should be marked as required for this reason. fwiw, openapi schema generation marks fields tagged as as optional:
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
Code change:
}, "required": [ "currentReplicas", <del> "desiredReplicas", "conditions" </del> <ins> "desiredReplicas" </ins> ], "type": "object" },

Related discussion:
text: This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Code change:
return encoder.EncodeWithAllocator(obj, w, memAlloc) } } else { <del> klog.V(4).Infof("a memory allocator was provided but the encoder %T doesn't implement the runtime.EncoderWithAllocator, using regular encoder.Encode method") </del> <ins> klog.V(4).Infof("a memory allocator was provided but the encoder %s doesn't implement the runtime.EncoderWithAllocator, using regular encoder.Encode method", c.encoder.Identifier()) </ins> } } switch obj := obj.(type) {

Related discussion:
text: 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
/help wanted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue </details
/assign
Hi , I am new to making contributions in Kubernetes ecosystem. I am happy to start working on this issue. I will reach out to you if I need any clarifications. Best Regards, Umesh
/assign
/assign
Code change:
"github.com/stretchr/testify/require" runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime" <del> "k8s.io/kubernetes/pkg/security/apparmor" </del> "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" <ins> "k8s.io/kubernetes/pkg/security/apparmor" </ins> ) func TestLabelsAndAnnotationsRoundTrip(t *testing.T) {

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?: What happened: We have a private registry configured (where all images including the sandbox one), are hosted. The registry credentials are being pulled by one of k8s credentials providers () With Kubernetes 1.7 sandbox image failed to be pulled with the following error message: Looks like with this only creds from docker config are being evaluated on the sandbox image pull What you expected to happen: Sandbox image pull should be attempted using credentials returned by not just the basic docker credential provider, but other credentials providers registered in the system. How to reproduce it (as minimally and precisely as possible): 1) Register private repo credentials with one of the k8s credential providers (we've tried with rancher). Configure the to use the image from the the private repo. 2) Make sure you are not logged in to this private repo on the kubelet host 3) Try to create a pod. Sandbox image pull will fail with an error mentioned above. Anything else we need to know?: Non-sandbox images from the same private repo were able to download correctly using private repo credentials provider. Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others:
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
/sig node Just tested the same use case against k8s 1.5.x, it worked fine there and sandbox image was pulled using the credentials passed by the credential provider, not from docker config file. So it might have regressed in 1.7.x (haven't tested it on 1.6, so can't tell for sure)
Confirmed a bug introduced in dockershim. Will file a PR to fix this.
Code change:
"github.com/stretchr/testify/require" runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/v1alpha1/runtime" <del> "k8s.io/kubernetes/pkg/security/apparmor" </del> "k8s.io/kubernetes/pkg/kubelet/dockershim/libdocker" <ins> "k8s.io/kubernetes/pkg/security/apparmor" </ins> ) func TestLabelsAndAnnotationsRoundTrip(t *testing.T) {

Related discussion:
text: Could you also verify whether fixed your problem?
tested against your commits cherry-picked on top of 1.8 beta, the fix seems to work
thanks.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: 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</aThe commands available for adding these labels are documented <a href=""here</a</details
Code change:
// Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ <del> string(kubeServicesChain): {{ JumpChain: string(KubeNodePortChain), MatchSet: kubeNodePortSetUDP, }}, </del> string(KubeNodePortChain): {{ <del> JumpChain: string(KubeMarkMasqChain), MatchSet: "", </del> <ins> JumpChain: string(KubeMarkMasqChain), MatchSet: kubeNodePortSetUDP, }}, string(kubeServicesChain): {{ JumpChain: string(KubeNodePortChain), MatchSet: "", </ins> }}, } checkIptables(t, ipt, epIpt)

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /assign I'll make the pull request tomorrow. What happened: start kube-proxy in ipvs mode, create some NodePort services. Then look at the iptables rules. match-set of KUBE-NODE-PORT-TCP is inadequate to be qualified as NodePort traffic. "--dst-type LOCAL" is needed. What you expected to happen: since we have also KUBE-NODE-PORT-UDP, another way would be like this: How to reproduce it (as minimally and precisely as possible): start kube-proxy in ipvs mode, create some NodePort services. Then look at the iptables rules. Anything else we need to know?: Environment: Kubernetes version (use ): commit Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS Linux release 7.2.1511 (Core) Kernel (e.g. ): Linux VM34centos 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: Others:
/sig network /area kube-proxy /area ipvs /assign
/cc i remember this bug fixed, that's right?
, Thanks, seems like necessary. But you have any use case that ipvs proxier will have bugs in current mach rules?
It's already fixed by ? Can we close this issue now?
I don't see how fixed this issue. How about this scenario: k8s cluster A uses node port for service A k8s cluster B uses node port for service B pod (or host) in cluster A tries to access node port on k8s cluster B local node port rule matches the traffic and NATs it to the local node port, pod (or host) cannot reach cluster B's node port. Also, the remote node port could be replaced by any non-k8s host that happens to use port .
Then I think can solve this problem.
Code change:
<ins> /* Copyright 2014 Google Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package main import ( "fmt" "io" "os" "github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl/cmd" "github.com/spf13/cobra" ) func main() { out := os.Stdout // Set environment variables used by kubectl so the output is consistent, // regardless of where we run. os.Setenv("HOME", "/home/username") kubectl := cmd.NewFactory().NewKubectlCommand(out) fmt.Fprintf(out, "## %snn", kubectl.Name()) fmt.Fprintf(out, "%snn", kubectl.Short) fmt.Fprintln(out, "### Commandsn") for _, c := range kubectl.Commands() { genMarkdown(c, nil, out) } } func genMarkdown(command, parent *cobra.Command, out io.Writer) { name := command.Name() if parent != nil { name = fmt.Sprintf("%s %s", parent.Name(), name) } fmt.Fprintf(out, "#### %sn", name) desc := command.Long if len(desc) == 0 { desc = command.Short } fmt.Fprintf(out, "%snn", desc) usage := command.UsageString() fmt.Fprintf(out, "Usage:n```n%sn```nn", usage[9:len(usage)-1]) for _, c := range command.Commands() { genMarkdown(c, command, out) } } </ins>

Related discussion:
text: Manually updated docs have a tendency to drift from actual implementation. It shouldn't be too hard to add a script to generate the markdown from a . We could then run the script manually or as a commit hook when changes are made to pkg/kubectl.
A big chunk of that is cut/paste from the help output anyway.. Brendan On Jan 9, 2015 4:20 PM, "Jeff Lowdermilk" wrote:
Why are we including the help output? Seems like cobra should do that, or we should just tell the user to ask for help if they want it.
It's useful to see generated markdown of help output for the full command tree, e.g. if you want to link to the syntax on irc or something. Anyway, this was quite easy to do, I'll have a PR shortly.
Code change:
// HasPopulatedHints checks whether there are populated hints for a given service in the cache. func (t *TopologyCache) HasPopulatedHints(serviceKey string) bool { <ins> t.lock.Lock() defer t.lock.Unlock() return t.hasPopulatedHintsLocked(serviceKey) } func (t *TopologyCache) hasPopulatedHintsLocked(serviceKey string) bool { </ins> return t.hintsPopulatedByService.Has(serviceKey) }

Related discussion:
text: I noticed that kube-controller-manager terminated with a concurrent map access: No concurrent map access, and no fatal error. No reproducer. I noticed this in an internal CI run. This appears to be an obvious (in retrospect) logic error with a straightforward solution, so I assume that it isn't necessary to provide a reproducer. This is from an OpenShift cluster based on Kubernetes 1.27. AWS. Red Hat Enterprise Linux CoreOS 414.92.-0. No response No response No response
/sig network
/assign
/triage accepted
Code change:
// according to the corresponding EndpointSlice addressType field. Consumers // must handle different types of addresses in the context of their own // capabilities. This must contain at least one address but no more than <del> // 100. </del> <ins> // 100. These are all assumed to be fungible and clients may choose to only // use the first element. Refer to: https://issue.k8s.io/106267 </ins> // +listType=set repeated string addresses = 1;

Related discussion:
text: An can contain up to 1000 , which can each contain up to 100 . Or at least, that's what the docs say, but actually, kube-proxy (or more specifically, ) only looks at the first Address in each Endpoint: (This is compatible with how works, since it would only generate multi-Address Endpoints if a pod had multiple of the same address family, which is not allowed. But it's not compatible with manually-generated EndpointSlices.) Either all are used, or else the docs state that only is used and the field is an array solely for historical reasons.
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 network /priority important-longterm /cc
All addresses in the slice must be of the same type, do you mean creating an Slice with different address types in the Addresses field?
I'm not sure if/how kube-proxy should handle an endpoint with more than 1 address. I think the goal of kube-proxy is to give each endpoint an equivalent probability of being selected. To extend that logic here, I think we'd need to take the probability assigned to an endpoint and divide it by the number of addresses attached to that endpoint. So if an endpoint has a 50% probability of being selected, and it provides 50 addresses, each should end up with a 1% probability of being selected. Of course with the way we need to do descending probabilities, the logic may get a bit complicated. This isn't as clear as it should be, but I don't think kube-proxy or any consumer of the EndpointSlice API needs to commit to supporting every value specified by that API. For example, many may filter by address type, Service, or some other means. I think it's also valid for a consumer to say they only support a single address per family per endpoint. So all of that to say, I'd support either documenting that kube-proxy only selects the first address in an endpoint, or updating kube-proxy to support more than one address per endpoint.
Code change:
// according to the corresponding EndpointSlice addressType field. Consumers // must handle different types of addresses in the context of their own // capabilities. This must contain at least one address but no more than <del> // 100. </del> <ins> // 100. These are all assumed to be fungible and clients may choose to only // use the first element. Refer to: https://issue.k8s.io/106267 </ins> // +listType=set repeated string addresses = 1;

Related discussion:
text: Given the number of changes currently in flight for kube-proxy, documentation seems like a safer initial approach to me.
/assign
can I have this editing only the first address(Address[0]) in Endpoint.Address to be used. The use of an array in this field is based on historical reasons. Isn't that right
thanks for volunteering to help with this one! I know has some big kube-proxy changes/fixes in flight right now, so it would be good to be sure you don't conflict with him. Otherwise, as long as isn't already working on this, I think you're free to have it.
I don't think we agreed that the array is for historical reasons only. We aren't currently using it, but we aren't ready to say that we won't use it in the future at this point. So, the docs should warn that kube-proxy currently ignores additional addresses, but it shouldn't imply that it's actually wrong to have additional addresses I'm not
thanks i will work on this
It was for a reason, but I think that reason was mixed-family slices (before we decided to break it up into single-family slices). What would it mean to have multiple addresses here? Are they assumed to be equivalent? Or do they have different context (like a split-horizon)? If the latter, there isn't any metadata here (i.e. it's not a struct like to allow new fields). I am inclined to believe it was meant as equivalent, and as such it's probably OK to document that assumption clearly. That said, I don't see how anyone could use multiple addresses in a meaningful way - they are either assumed equivalent or they lack enough metadata to distinguish their differences. ?? If we do document the equivalence, it should be generically worded. E.g. "These addresses are assumed to be equivalent and some consumers may choose to ignore all but the first value."
if it was meant as equivalent, why put multiple same addresses into Addresses? I don't understand what the purpose of this is.
The first version of the API had both IP families in a single slice, so it made sense to have multiple addresses. We changed that, though we didn't immediately remove the old support. So my best guess is that we should have converted this to a singular value when we did that, but we missed it.