jiebi/CodeConvo huggingface dataset:
Change:
} func (b *errorOnce) Send(errIn <-chan error) ErrorOnce { <del> go b.forward(errIn) </del> <ins> if errIn == nil { // don't execute this in a goroutine; save resources AND the caller // likely wants this executed ASAP because some of some operation // ordering semantics. forward() will not block here on a nil input // so this is safe to do. b.forward(nil) } else { go b.forward(errIn) } </ins> return b } func (b *errorOnce) forward(errIn <-chan error) { if errIn == nil { <ins> // important: nil never blocks; Report(nil) is guaranteed to be a // non-blocking operation. </ins> b.Report(nil) return }

Discussion:
Can we get this fixed ASAP? Thanks!
yep, thanks for reporting , Brendan Burns wrote:
how reproduceable is this? I have some changes that I think will resolve it but I couldn't reproduce locally even when all my cpu's were pretty tied up and using a high GOMAXPROCS.
flakey label process?
the labelling is due to me failing @ github's label interface. Bulk editing labels removes them if any of the selected things have the label sigh Thanks for the quick fix.
Change:
}, "service": { "$ref": "v1beta1.ServiceReference", <del> "description": "`service` is a reference to the service for this webhook. Either `service` or `url` must be specified.nnIf the webhook is running within the cluster, then you should use `service`.nnIf there is only one port open for the service, that port will be used. If there are multiple ports open, port 443 will be used if it is open, otherwise it is an error." </del> <ins> "description": "`service` is a reference to the service for this webhook. Either `service` or `url` must be specified.nnIf the webhook is running within the cluster, then you should use `service`.nnPort 443 will be used if it is open, otherwise it is an error." </ins> }, "caBundle": { "type": "string",

Discussion:
What happened: Deployed a webhook backend and service as follows: Please note that there is only 8443 port on the service. Register the webhook as follows: Got the following error when creating pods: What you expected to happen: Based on , should be called. Not the 443 port shown in the error message. How to reproduce it (as minimally and precisely as possible): Just deploy the same setup and register webhook. Anything else we need to know?: Environment: Kubernetes version (use ): HEAD Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.0-alpha.1.97+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-01-22T20:00:24Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.470+", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-03-12T19:36:42Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): COS Kernel (e.g. ): COS
thanks for the detailed bug report!
I actually think that the API specification (or documentation) must change. Not all API servers will have access to look up the Service object and see what ports it defines. If we want to support ports other than 443, the port information must be specified in the webhook object, not discovered by direct Service object lookup
/assign
Looks like it will always use 443 no matter what ports are available, right? Should our documentation reflect this or should it behave differently? (also just sets 443 in the custom dial wrapper thing )
As a first step, I would adjust the documentation. As noted in , if we want to support ports other than 443, that information needs to be to the webhook config object
Change:
package kubectl import ( <del> scheduling "k8s.io/api/scheduling/v1alpha1" </del> <ins> scheduling "k8s.io/api/scheduling/v1beta1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "reflect"

Discussion:
/kind bug What happened: When I try to create a priorityclass object like: It fails with And when I try create it with yaml file like: It works. What you expected to happen: Create a priorityclass object with kubectl.
/sig cli
Do you have --runtime- set in kube-apiserver?
No, if set this, it works.
Agree this is a bug. v1beta1 should be preferred.
/sig scheduling
Change:
addr := net.ParseIP(node.Name) if addr != nil { address := api.NodeAddress{Type: api.NodeLegacyHostIP, Address: addr.String()} <del> node.Status.Addresses = append(node.Status.Addresses, address) </del> <ins> api.AddToNodeAddresses(&node.Status.Addresses, address) </ins> } else { addrs, err := lookupIP(node.Name) if err != nil {

Discussion:
Since we append hostips to the list on every node controller run invocation which happens at 10s intervals, this list grows pretty large pretty soon: Maybe: would still satisfy the requirements?
Fix is here I think we generally use list instead of map
This could have been P1, but I just merged a fix so I'll leave at P2. Remaining work to do: Add to validation something that limits the number of IP addresses. (and maybe checks dups?)
Yeah, I'll add validation later.
Change:
"k8s.io/kubernetes/pkg/scheduler/internal/heap" "k8s.io/kubernetes/pkg/scheduler/metrics" "k8s.io/kubernetes/pkg/scheduler/util" <ins> "k8s.io/utils/clock" </ins> ) const (

Discussion:
We should use /kind cleanup
/remove-kind feature /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 : /remove-kind feature /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
/sig scheduling /triage accepted
/assign
Change:
func (kl *Kubelet) HandlePodAdditions(pods []*v1.Pod) { start := kl.clock.Now() sort.Sort(sliceutils.PodsByCreationTime(pods)) <del> // Responsible for checking limits in resolv.conf // The limits do not have anything to do with individual pods if kl.dnsConfigurer != nil && kl.dnsConfigurer.ResolverConfig != "" { kl.dnsConfigurer.CheckLimitsForResolvConf() } </del> for _, pod := range pods { existingPods := kl.podManager.GetPods() // Always add the pod to the pod manager. Kubelet relies on the pod

Discussion:
What happened: Ref , we noticed that there are some unnecessary check around limit in kubelet, specifically at: and is moving this check to outside of the pods loop make it better, but we should be looking at whether this check can exist in an even higher layer, as it doesn't make much sense in either or . cc
/sig network
/assign Pending outcome of the discussion here, I would be happy to present a PR
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
poke :-)
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
/remove-lifecycle stale
How about lifting the check to the beginning of Kubelet#syncLoop (outside the for loop) ? All the events emitted by CheckLimitsForResolvConf are at EventTypeWarning level (not error). The CheckLimitsForResolvConf call in HandlePodUpdates would be removed as well.
Change:
case *rsa.PrivateKey: key = k default: <del> return nil, errors.Wrapf(err, "the private key file %s isn't in RSA format", privateKeyPath) </del> <ins> return nil, errors.Errorf("the private key file %s isn't in RSA format", privateKeyPath) </ins> } return key, nil

Discussion:
<!-- 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!--What happened: When trying to deploy Kubernetes using kubeadm v1.12.1, kubeadm failed to generate certificates, causing it to fail at a later step. After passing to get all the logs I could I found that it was expecting all the certificates to have been pre-made, even though I only the certificate and key for the certificate authority. So I dug into the code, and in I found this: It turns out all the PKI I've been generating for things like etcd has been ECDSA. So I found the issue I was having, but I still couldn't figure out why kubeadm wasn't failing right away. I took a look at the caller of that function: It looks like that original error is swallowed. What you expected to happen: Immediate failure when keys are in the wrong format. How to reproduce it (as minimally and precisely as possible): Use an ECDSA cert/key pair and run . Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.1 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): Ubuntu 18.04 Kernel (e.g. ): 4.15.0-34-generic -Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
Please create a issue on
/area kubeadm /sig cluster-lifecycle
Sure.
Change:
return false } <del> // GetAllocatableDevices returns information about all the devices known to the manager </del> <ins> // GetAllocatableDevices returns information about all the healthy devices known to the manager </ins> func (m *ManagerImpl) GetAllocatableDevices() ResourceDeviceInstances { m.mutex.Lock() <del> resp := m.allDevices.Clone() m.mutex.Unlock() klog.V(4).InfoS("Known devices", "numDevices", len(resp)) </del> <ins> defer m.mutex.Unlock() resp := m.allDevices.Filter(m.healthyDevices) klog.V(4).InfoS("GetAllocatableDevices", "known", len(m.allDevices), "allocatable", len(resp)) </ins> return resp }

Discussion:
When calling GetAllocatableDevices, the API returns all the registered devices, regardless of their health status. Thing is, the - and in general doesn't make much sense to report as allocatable Unhealthy devices, as is also documented in the (see last paragraph) The API should not report unhealthy device. This means the reported device set can potentially change across multiple invocations of the API, as . a kube = 1.21 environment, enable the feature gate any device plugin - including sample device plugin sure 1+ devices are reported unhealthy the podresources GetAllocatableResources API, observe the unhealthy device is reported in the return value. N/A Kubernetes version (use ): 1.21 and beyond Cloud provider or hardware configuration: not relevant OS (e.g: ): any Kernel (e.g. ): not relevant Install tools: not relevant Network plugin and version (if this is a network-related bug): not relevant Others: not relevant
/sig node
/triage accepted
Change:
// pod deletion doesn't affect. Pods are deployed on the same node or different nodes depending on requiresSameNode. // Read/write check are done across pod, by check reading both what pod{n-1} and pod{n} wrote from pod{n}. func TestConcurrentAccessToSingleVolume(f *framework.Framework, cs clientset.Interface, ns string, <del> node e2epod.NodeSelection, pvc *v1.PersistentVolumeClaim, numPods int, requiresSameNode bool) { </del> <ins> node e2epod.NodeSelection, pvc *v1.PersistentVolumeClaim, numPods int, requiresSameNode bool, readOnly bool) { </ins> var pods []*v1.Pod

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-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
/priority important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.
Change:
scalefake "k8s.io/client-go/scale/fake" core "k8s.io/client-go/testing" "k8s.io/client-go/tools/cache" <ins> "k8s.io/client-go/tools/record" </ins> "k8s.io/client-go/util/workqueue" "k8s.io/klog/v2" _ "k8s.io/kubernetes/pkg/apis/core/install"

Discussion:
When using PDBs with or (percentage), it is not supported to reference pods via a PDB selector, that do not have a supported controller owner reference: Deployment, ReplicationController, ReplicaSet, and StatefulSet controllers or a resource implementing subresource This is also documented Nevertheless, there are still people who create PDBs a pods without controllers that ignore this. For example PDBs that set , want to block eviction, and node drain (it works for them but the PDB status is invalid). Unfortunately there is no feedback for the user to receive when this happens. The KCM logs is the only place that informs the user when unmanaged pods are found. Which I think is insufficient. There should be some way to inform users about this. Since it cannot be know on admission we probably have to do it when reconciling the PDB and unmanaged pods are found. Options: an event when this is detected - probably needs to be throttled in some way a condition in a PDB status that would be set and admins could monitor these to detect misbehaving PDBs create a PDB create unmanaged pod observe incorrect status because this configuration is unsupported No response <detailsNA </details<detailsNA </details<detailsNA </details<details</details<details</details<details</details
/sig apps
/triage accepted This was discussed during today's sig-apps, we've agreed to add a warning event right next to the log statement from the original description
I'll take this on.
/assign
/reopen I did some more testing for the unsupported controllers and found out that these are covered by the event, so I posted a followup to reflect that The new event should cover only the naked pods
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
Change:
i += 2 } <del> // filenames have `/go/src/k8s.io` prefix which dont exist locally for i, v := range frames { frames[i].File = strings.Replace(v.File, "/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes", *k8sPath, 1) </del> <ins> // filenames are in one of two special GOPATHs depending on if they were // built dockerized or with the host go // we want to trim this prefix to produce portable relative paths k8sSRC := *k8sPath + "/_output/local/go/src/k8s.io/kubernetes/" for i := range frames { trimmedFile := strings.TrimPrefix(frames[i].File, k8sSRC) trimmedFile = strings.TrimPrefix(trimmedFile, "/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/") frames[i].File = trimmedFile </ins> } for _, curFrame := range frames {

Discussion:
The currently provided command for generating requires bazel, the command should be updated to one which does not require bazel Currently: Suggested: /sig testing /sig architecture /area conformance
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 . /lifecycle rotten
/assign /remove-lifecycle rotten
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
/remove-lifecycle stale
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-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten /help
This request has been marked as needing help from a contributor. 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 : /remove-lifecycle rotten /help 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
We're going to need to update this to verify under as well instead of under the bazel "unit tests", ref: I'll work on this.
done in
This is wonderful to see. Thank you
Change:
// Update the deployment template - the new replicaset should stay the same framework.Logf("Updating paused deployment %q", deploymentName) <del> newTGPS := int64(40) </del> <ins> newTGPS := int64(0) </ins> deployment, err = framework.UpdateDeploymentWithRetries(c, ns, d.Name, func(update *extensions.Deployment) { update.Spec.Template.Spec.TerminationGracePeriodSeconds = &newTGPS })

Discussion:
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
dup
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
All of these failures are related to the cleanup phase of the test - pods are terminating but never actually removed. We should probably use a zero grace period for pods.
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
Change:
if err := wrapped.SetUpAt(dir, fsGroup); err != nil { return err } <ins> if err := volumeutil.MakeNestedMountpoints(b.volName, dir, b.pod); err != nil { return err } </ins> optional := b.source.Optional != nil && *b.source.Optional secret, err := b.getSecret(b.pod.Namespace, b.source.SecretName)

Discussion:
This bug affects any pod that has a container with a nested volume (any type) beneath an API data volume, such as a secret, configMap, downwardAPI or projected volume. In the description and reproduction details below I use a secret volume, but any of the four will demonstrate this behavior. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When creating a pod with nested secrets volumes (e.g. one volume mounted at and one mounted at ), the container fails to start with an error like: What you expected to happen: The container should start with both and mounted. How to reproduce it (as minimally and precisely as possible): out master, any version since a file with 2 secrets and a pod that makes volumes for the 2 secrets, with one of them mounted within the other: the 2 secrets and the pod. Assuming you named the above file : Anything else we need to know?: This may work for other runtimes if they create mountpoints outside of the sandbox. But it's definitely broken with Docker as the runtime.
This should be fixed by /sig storage /sig node /assign
Change:
for nodeName, cpu := range nodeToAllocatableMap { requestedCPU := cpu * 7 / 10 fillerPods = append(fillerPods, createPausePod(f, pausePodConfig{ <del> Name: "filler-pod-" + nodeName, </del> <ins> Name: "filler-pod-" + string(uuid.NewUUID()), </ins> Resources: &v1.ResourceRequirements{ Limits: v1.ResourceList{ v1.ResourceCPU: *resource.NewMilliQuantity(requestedCPU, "DecimalSI"),

Discussion:
/kind bug cc What happened: Running one scheduling predicates conformance test on a 1.7.10 cluster where node names are FQDN, e.g. kube-node-, fails. What you expected to happen: The tests should pass. How to reproduce it (as minimally and precisely as possible): Follow or bootstrap a Kubernetes cluster where nodes names are FQDN, e.g. my-node- Anything else we need to know?: Also affects master but not 1.8.x. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GCP OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: none
Cherry-pick for 1.7.x Again, it doesn't seem to affect 1.8.x.
Change:
resources := []schema.GroupVersionResource{ batch.Resource("cronjobs").WithVersion("v1beta1"), networking.Resource("ingresses").WithVersion("v1beta1"), <del> // TODO #83513 csinodes override can be removed in 1.18 apisstorage.Resource("csinodes").WithVersion("v1beta1"), </del> apisstorage.Resource("csidrivers").WithVersion("v1beta1"), }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : storage/v1.CSINode is being introduced in 1.17 via The storage version should switch to v1 in 1.18. Why is this needed: We need to wait until 1.18 to handle the HA upgrade case where a controller may be 1 version higher than the API server. /assign
These files will have to be updated: