jiebi/CodeConvo huggingface dataset:
Change:
"google.golang.org/grpc" "google.golang.org/grpc/credentials/insecure" <del> "k8s.io/apimachinery/pkg/util/wait" </del> kmsapi "k8s.io/kms/apis/v2" )

Discussion:
Drop the and dependencies from to keep the import lighter. /sig auth /triage accepted
/assign Hi, , I created a PR to fix this. I am not sure If I am correct due to the repo seems generated. Would you like to provides some hints for me?
This will likely require a new go module in to move the client-go dep and then mark it as internal, ex: . is the only API machinery dep so we can probably come up with some way to re-implement the wait logic locally? Then we drop these lines so that these imports do not come back again:
Whoa, yeah, I'd take a for loop and a time.Sleep in a test to drop those deps
What is kms using client-go for? Tests only?
These were all needed by the KMS repo back when we had a much more complicated reference implementation which required a key hierarchy. Now they are just used in some tests and mock implementations, so we should be able to simplify things.
I found a place for rate limit. #liggitt
that package just delegates to "", switch that mock provider to use that directly?
Change:
} func (server *APIServer) handleIndex(w http.ResponseWriter, req *http.Request) { <ins> if req.URL.Path != "/" && req.URL.Path != "/index.html" { server.notFound(w, req) return } </ins> w.WriteHeader(http.StatusOK) // TODO: serve this out of a file? data := "<html><body>Welcome to Kubernetes</body></html>"

Discussion:
sig-release master-blocking build-masterci-kubernetes-build.Overall 2022-06-01 20:49 CEST, commit No response /sig release cc
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
I'm checking that
/assign
this pr should fix
it looks like it's still failing: https://k8s-
/reopen reopening as this is causing all our CI to run against stale artifacts at: v1.25.0-alpha.0.734+
Reopened this issue. <detailsIn response to : /reopen v1.25.0-alpha.0.734+ </details
my previous fix only fixed one side of the things, missing now job are green ! closing for now /close
Closing this issue. <detailsIn response to : my previous fix only fixed one side of the things, missing now job are green /close 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
thank you !
Change:
1. More intelligent defaulting of fields (e.g., [#2643](https://github.com/GoogleCloudPlatform/kubernetes/issues/2643)) 1. Update preconditions based on the values of arbitrary object fields. 1. Deployment manager compatibility on GCP: [#3685](https://github.com/GoogleCloudPlatform/kubernetes/issues/3685) <ins> 1. Describe multiple objects, multiple kinds of objects [#5905](https://github.com/GoogleCloudPlatform/kubernetes/issues/5905) 1. Support yaml document separator [#5840](https://github.com/GoogleCloudPlatform/kubernetes/issues/5840) </ins> TODO: * watch <del> * ssh [#1513](https://github.com/GoogleCloudPlatform/kubernetes/issues/1513) </del> * attach [#1521](https://github.com/GoogleCloudPlatform/kubernetes/issues/1521) * image/registry commands * do any other server paths make sense? validate? generic curl functionality?

Discussion:
Simple version is done, more complex version needs work. Done, now that readiness corresponds to Running and is tracked by Kubelet status if the readiness hook is set? Done Done Do we want to do a more generic one or a less generic one? OpenShift was looking more at specific topical plugin commands ("add-volume", "set-default-resources"), but not sure how much hand-holding users need. Getting close. Exec has landed and is a replacement for ssh Attach on start remains hard. Implemented
I/we should also file issues for outstanding items without issues, and add lines for newly filed issues (e.g., command flag for run-container). Readiness is not yet used by rollingupdate. With respect to patch on the command line: I was thinking of a generic mechanism, but I could see the case for domain-aware commands, also. I think we need to better factor the command code and library code, and generic functionality vs. domain-aware functionality. Neither should ever convert to the internal representation. Domain-aware functionality (e.g., describe) should target a specific API version. Configuration generators, such as run-container, should be provided as services, or at least as separate plugin commands.
ref
ref
ref
ref
ref
ref
Change:
import ( "bytes" <ins> "errors" </ins> "fmt" "io" "io/ioutil" <ins> "strings" </ins> "testing" "time"

Discussion:
What happened: When using a yaml file for input, silently fails at the first missing resource, not returning any further results. What you expected to happen: Searching with cli arguments properly ignores missing resources and continues the query, eg: Would expect similar results with a file input, eg: How to reproduce it (as minimally and precisely as possible): With an input file of : the command fails at apparently the first missing resource: Note: that rearranging the inputs in (so that the missing resource is last) produces the "expected" output: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: local OS (e.g: ): fedora 30 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: x-ref:
/sig cli
/assign
Got around to reproducing it and can confirm that I'm getting the same behavior. I'm looking into fixing it now
thanks, any updates on this?
I've learned that in the case of a fake entry, kubectl stops sending API get requests altogether. Learned by running kubectl get -f --ignore-not-found --v=10, the result is shown below. Till now I've been looking into the cobra command framework but now I'm trying to find out where kubectl is making these API calls from(working on finding out where this connection is happening from Slack+debugging, I've asked a more detailed question here ). <img width="1440" alt="Screen Shot 2019-08-12 at 4 13 41 PM" src="https://user-"
that's an interesting find, definitely helpful. When I looked into this I got to the section of get's main run function, and it seems like it should be continuing on any errors (see ) but maybe the ResourceBuilder is actually stopping when it hits a 404?
This behavior comes from where the not found errors are being ignored and where the input list is flattened. Errors are ignored here: While flattening occurs here: As the visitor iterates through the objects in the list if an error occurs, such as not found, it will stop iterating over the objects in the list and return that not found error. The logic will then ignore it and continue.

Any objects that came before the not found object in the list will have been visited and will then be included in the output. To make the behavior consistent between the two ways of getting the set of objects, the would need to be updated to support filtering errors.
Just submitted a PR adding that functionality to the FlattenListVisitor. The behavior is now consistent between the two methods.
Change:
return false } <ins> func hasJobCondition(conditions []batch.JobCondition, conditionType batch.JobConditionType) bool { for _, condition := range conditions { if condition.Type == conditionType { return condition.Status == api.ConditionTrue } } return false } </ins> func printPodTemplate(obj *api.PodTemplate, options printers.GenerateOptions) ([]metav1.TableRow, error) { row := metav1.TableRow{ Object: runtime.RawExtension{Object: obj},

Discussion:
Suspend is a GA feature and it is big component of Kueue. It would be nice to display if jobs are suspended when doing . A new column that displays if the job is suspended would be helpful. Improve UX around suspend. Its a bit difficult to know why the job has not created pods unless you know about the suspend field.
/sig cli /wg batch /good-first-issue /help-wanted
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 : /sig cli /wg batch /good-first-issue /help-wanted 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
/cc Just something I noticed as I was testing some job in JobSet. It would be nice to see which jobs are suspended when doing . Hope its not a controversial change.
cc who worked on
Not controversial at all IMO /triage accepted
/assign
Any suggestions on where to place this column? I'm thinking between completions and durations. Or, should this be displayed only when the output is set to wide?
I would put it in the default view as well. Probably before completions
Addressed in the PR:
Change:
return mountErr } <del> if !*volumeSource.ReadOnly { </del> <ins> if volumeSource.ReadOnly == nil || !*volumeSource.ReadOnly { </ins> volume.SetVolumeOwnership(m, fsGroup) }

Discussion:
<!-- 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: I'm running a Redis pod with a PV provisioned as an Azure Managed Disk. It's got an exec readiness probe that calls in the container. At some point it receives a SIGTERM. The kubelet then tries to sync the pod and restart the container, but it panics in (looking over the code, that's the only place where the error from is ignored) As a result, the pod hangs in a state, since the readiness probe cannot be ran in a non existing container. What you expected to happen: The container would successfully restart. How to reproduce it (as minimally and precisely as possible): It's the 2nd time it happens but I haven't yet figured out the conditions to reproduce. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: Azure w/ Managed Disks OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others:
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
Hi could you also share the storageclass, pvc & pod yaml files? I would like to repro, thx
I may insert a nil check statment in this func: But I need to reproduce this bug anyway, so that I could find the root cause of this issue, thx.
Yes, an error check is what I'm hoping for :) I've used the chart. The PV/PVC were created manually, they're set to an empty storage class. I should mention that I've also noticed other pods being terminated/recreated at the time this one failed, however I didn't trace the cause of this yet.
thanks for the reporting, I may have found the root cause, just need a few more debuging time, thx.
GitHub didn't allow me to assign the following users: xiazhang. Note that only can be assigned. <detailsIn response to : /assign xiazhang 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
/assign andyzhangx
- Thanks for the fix!
Change:
}, "io.k8s.api.core.v1.PodAffinityTerm": { "description": "Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key u003ctopologyKeyu003e matches that of any node on which a pod of the set of pods is running", <ins> "required": [ "topologyKey" ], </ins> "properties": { "labelSelector": { "description": "A label query over a set of resources, in this case pods.",

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/kubernetes/pkg/scheduler/apis/config" "k8s.io/kubernetes/pkg/scheduler/metrics" schedulernodeinfo "k8s.io/kubernetes/pkg/scheduler/nodeinfo"

Discussion:
What would you like to be : When the pod is scheduled to the phase and I delete the pod, the pod still remains in the until the plugin allow/reject/timeout(Especially when waiting for a long time). Why is this needed: We need to take the initiative to delete the data in the and terminate the process in waiting state of plugin to ensure data accuracy, if the pod has been deleted /cc /priority important-soon /assign /sig scheduling
I think we can update the event handler for deleting pods to reject the pod. Can you send a PR for that?
OKI will send a pr for it.
Change:
n, err = t.reader.Read(p) if err != nil { if t.o.MaxTries < 0 || t.retries < t.o.MaxTries { <ins> t.retries++ </ins> fmt.Printf("Resuming copy at %d bytes, retry %d/%dn", t.bytesRead, t.retries, t.o.MaxTries) t.initReadFrom(t.bytesRead + 1) err = nil <del> t.retries++ </del> } else { fmt.Printf("Dropping out copy after %d retriesn", t.retries) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Trying to copy a large file from a container via kubectl cp with the new flag results in the following error: I executed the following command: EDIT: The command executes and the file is copied. However, the resulting file is somehow corrupted: However, the files have exactly the same size locally and on the pod: Also, the command exits with non-zero code and thus scripts may stop or abort at this point. What you expected to happen: The large file to be downloaded from the container completely and unharmed. Exit code 0 only if copy was successful How to reproduce it (as minimally and precisely as possible): Add a large file (mine was ~150M) to any location in the pod (preferrably a tar file). Execute kubectl cp to download the large file and use the flag. Try to untar the resulting file Anything else we need to know?: Related to Issue . I only experience this issue if I see kubectl doing at least one retry. Environment: Kubernetes version (use kubectl version): server v1.20.12, client v1.23.1 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Kernel (e.g. uname -a): Install tools: Others:
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 cli
tar: Removing leading `/' from member names so cancel first "/" from "" like this: k cp --retries=-1
Thanks for the hint. The warning is a and I was just ignoring it in my case. This issue is about the error message and the command exiting with a non-zero exit code.
I just updated the issue description, we see the tar files being corrupted after kubectl did at least one retry
/assign atiratree
Is it correct to start at position bytesRead+1? Or should this be bytesRead instead?

For example, if 1 byte was read (position 0), we would want to resume from position 1, not position 2. Just a thought, I haven't really looked at what initReadFrom does.
It should be correct since the byte start of tail (part of implementaion of initReadFrom) and bytes read match. Meaning that when we read 10 bytes we want to start reading 11th one. The actual problem was that we were running a wrong command when -1 retries is used: please see
Change:
var errNotInVMSet = errors.New("vm is not in the vmset") var providerIDRE = regexp.MustCompile(`^` + CloudProviderName + `://(?:.*)/Microsoft.Compute/virtualMachines/(.+)$`) <del> // returns the full identifier of a machine func (az *Cloud) getMachineID(machineName string) string { </del> <ins> // getStandardMachineID returns the full identifier of a virtual machine. func (az *Cloud) getStandardMachineID(machineName string) string { </ins> return fmt.Sprintf( machineIDTemplate, az.SubscriptionID,

Discussion:
<!-- 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: When useInstanceMetadata is set to true for vmss nodes, their providerID is wrong. What you expected to happen: Their providerID should be in format azure:///subscriptions/&lt;subscription-id/resourceGroups/&lt;rg-name/providers/Microsoft.Compute/virtualMachineScaleSets/&lt;scaleset-name/virtualMachines/&lt;instance-id How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
adding priority important-soon so that this issue can stay in 1.10. Please update if incorrect. /priority important-soon
Change:
client, err := f.Client(cmd) checkErr(err) <del> rc, err := client.ReplicationControllers(namespace).Get(args[0]) checkErr(err) </del> generatorName := GetFlagString(cmd, "generator") generator, found := kubectl.Generators[generatorName] if !found {

Discussion:
expose hostnames --port=80 --container-port=9376 --selector="app=hostnames" get se hostnames -o yaml apiVersion: v1beta1 containerPort: "9376" ... obviously, endpoints controller is not happy.
Change:
} for _, addr := range addrs { <del> if addr.Type == v1.NodeInternalIP { </del> <ins> isIPv6 := net.ParseIP(addr.Address).To4() == nil if (addr.Type == v1.NodeInternalIP) && (isIPv6 == needIPv6) { </ins> return addr.Address, nil } } <del> return addrs[0].Address, nil </del> <ins> for _, addr := range addrs { isIPv6 := net.ParseIP(addr.Address).To4() == nil if (addr.Type == v1.NodeExternalIP) && (isIPv6 == needIPv6) { return addr.Address, nil } } // It should never return an address from a different IP Address family than the one needed return "", ErrNoAddressFound </ins> } // getAttachedInterfacesByID returns the node interfaces of the specified instance.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The Kubernetes master created routes in the neutron router that assign an IPv6 nexthop for a IPv4 prefix. This is not possible and causes a reachability problem between the pods. Example route: What you expected to happen: When describing a node the master has the following information It should detect the address type and choose the correct InternalIP How to reproduce it (as minimally and precisely as possible): Deploy on a Openstack cloud with IPv6 enabled using the following playbook Anything else we need to know?: The wrong next hop is coming from calling the function and nowhere is a check if the address is IPv4 or IPv6 Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Openstack OS (e.g. from /etc/os-release): Ubuntu Xenial Kernel (e.g. ):Install tools: Others: /sig openstack
- Thank you for this detailed analysis. Seems to me that the best way to address this would be to add an IP family argument to getAddressByName() to let it know what V4/V6 family to look for for a next-hop address. In the calls to getAddressByName(), this argument could be set based on the family of route.DestinationCIDR.
Issue is probably related.
Change:
s.config.Modeler.LockedAction(func() { bindingStart := time.Now() err := s.config.Binder.Bind(b) <del> metrics.BindingLatency.Observe(metrics.SinceInMicroseconds(bindingStart)) </del> if err != nil { glog.V(1).Infof("Failed to bind pod: %+v", err) s.config.Recorder.Eventf(pod, api.EventTypeNormal, "FailedScheduling", "Binding rejected: %v", err) s.config.Error(pod, err) return } <ins> metrics.BindingLatency.Observe(metrics.SinceInMicroseconds(bindingStart)) </ins> s.config.Recorder.Eventf(pod, api.EventTypeNormal, "Scheduled", "Successfully assigned %v to %v", pod.Name, dest) // tell the model to assume that this binding took effect. assumed := *pod assumed.Spec.NodeName = dest s.config.Modeler.AssumePod(&assumed) }) <ins> metrics.E2eSchedulingLatency.Observe(metrics.SinceInMicroseconds(start)) </ins> }

Discussion:
Currently scheduler latency are observed regardless of failure. For example, binding latency is like: This could be a potential confusion if latency spikes happen because of failure. We should better handle it like separating error case from normal
/cc
I completely agree - are you going to change this?
Yes. I will do it.
Change:
return 0 < port && port < 65536 } <ins> // Now in libcontainer UID/GID limits is 0 ~ 1<<31 - 1 // TODO: once we have a type for UID/GID we should make these that type. const ( minUserID  = 0 maxUserID  = math.MaxInt32 minGroupID = 0 maxGroupID = math.MaxInt32 ) // IsValidGroupId tests that the argument is a valid gids. func IsValidGroupId(gid int64) bool { return minGroupID <= gid && gid <= maxGroupID } // IsValidUserId tests that the argument is a valid uids. func IsValidUserId(uid int64) bool { return minUserID <= uid && uid <= maxUserID } </ins> const doubleHyphensFmt string = ".*(--).*" var doubleHyphensRegexp = regexp.MustCompile("^" + doubleHyphensFmt + "$")

Discussion:
Help review this, thanks.
Are you asking for better validation on pod creation? I'm not really sure what you mean when you say "tip".
Yes, I mean it's better validate the pod when create. The tip mean the validation info response from server and show by client.
Change:
Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{ Local: &v1.LocalVolumeSource{ <ins> // Not needed because we don't need to detach local device from the host. </ins> Path: "", }, },

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (block volmode)] disruptive[Disruptive] Should test that pv used in a pod that is force deleted while the kubelet is down cleans up when the kubelet returns. Since when has it been failing: 10/8/19 Testgrid link: https://k8s- Reason for failure: Introduced by but root cause is probably Anything else we need to know:
/assign
/milestone 1.17 /priority important-soon this is consistently failing in release-master-informing job could you please take a look?
The provided milestone is not valid for this repository. Milestones in this repository: [, , , , , , , , ] Use to clear the milestone. <detailsIn response to : /milestone 1.17 /priority important-soon Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/milestone v1.17