jiebi/CodeConvo huggingface dataset:
Change:
func IndexHandler(container *restful.Container, muxHelper *MuxHelper) func(http.ResponseWriter, *http.Request) { return func(w http.ResponseWriter, r *http.Request) { <ins> status := http.StatusOK if r.URL.Path != "/" && r.URL.Path != "/index.html" { // Since "/" matches all paths, handleIndex is called for all paths for which there is no handler registered. // We want to to return a 404 status with a list of all valid paths, incase of an invalid URL request. status = http.StatusNotFound } </ins> var handledPaths []string // Extract the paths handled using restful.WebService for _, ws := range container.RegisteredWebServices() {

Discussion:
Authenticated requests to master with an invalid URL path should return a non-status 200 response code. Preferably a 404 (not found). Sample output: { "paths": [ "/api", "/api/v1beta1", "/api/v1beta2", "/api/v1beta3", "/healthz", "/healthz/ping", "/logs/", "/metrics", "/static/", "/swagger-ui/", "/swaggerapi/", "/validate", "/version" ] }
Change:
annotations = map[string]string{} } annotations[corev1.LastAppliedConfigAnnotation] = value <del> if isAnnotationsValid(annotations) != nil { </del> <ins> if err := apimachineryvalidation.ValidateAnnotationsSize(annotations); err != nil { </ins> delete(annotations, corev1.LastAppliedConfigAnnotation) } accessor.SetAnnotations(annotations)

Discussion:
Expose totalAnnotationSizeLimitB in the validation package: This value is useful for validating annotations outside of the validation package, such as in SSA: Otherwise, size validation on annotations outside of the package would diverge and cause issues later. /kind cleanup /wg api-expression 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
/assign
Change:
// Assumes that lock is already acquired. func (cache *schedulerCache) updatePod(oldPod, newPod *v1.Pod) error { <ins> if _, ok := cache.nodes[newPod.Spec.NodeName]; !ok { // The node might have been deleted already. // This is not a problem in the case where a pod update arrives before the // node creation, because we will always have a create pod event before // that, which will create the placeholder node item. return nil } </ins> if err := cache.removePod(oldPod); err != nil { return err }

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! If the matter is security related, please disclose it privately via --What happened: If we delete node first, then remove pods on this node, the scheduler will crash in function What you expected to happen: Not crashed How to reproduce it (as minimally and precisely as possible): some pods on node A delete node A delete pods on node A Anything else we need to know?: Environment: Kubernetes version (use ): 1.16-1.18, even master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig scheduling
can you show the core dump please of this crash?
/assign
I patched the unit test shown in into the , and branches. None crashed. I'll await for the crash dump.
Here is the fresh dump.
and which version was this?
This is master branch. And I've tested it from 1.16-1.18, it can be reproduced easily.
Thanks a lot. I was able to finally reproduce in unit tests. The scenario is: a node with at least 2 pods. node. pod1. In unit test, this is first an update to set the termination timestamp. No issues up to this point. pod2. Again, first an update to set the termination timestamp. Here it crashes. I'm working on a fix.
It looks like this is not an issue in 1.17 and below, because we preserved a placeholder node where the operations occur. do you have stacktraces for 1.17 and 1.16?
Yes, it seems only be found at 1.18. :smile:
Change:
"time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/wait" clientset "k8s.io/client-go/kubernetes"

Discussion:
created a spread sheet of the slowest running tests for the pull-kubernetes-gce job. cc discussion on slack: spreadsheet: pie chart of test durations from SIGs: ! it seems appropriate to evaluate the state of the tests and reduce these runtimes. possibly move tests to periodic by marking them as [Slow]. /assign /kind design /area test (?)
/remove-kind bug
Are pull jobs the right place to be calculating the time? Or should be be counting in CI instead?
pull is the one timing out, so probably?
Looking at some of the top slowness:: subPath should fail for new directories when readOnly specified in the volumeSource: This test case is no longer defined in master HostPathType: This test case has not been checked in yet and is trying to be in a PR PersistentVolumes-local StatefulSet with pod affinity should use volumes spread across nodes when pod has anti-affinity: This test is already marked as slow in master
Created This should address most of the top slow storage tests
Change:
obj := event.Object.(*unstructured.Unstructured) return w.checkCondition(obj) } <ins> func extendErrWaitTimeout(err error, info *resource.Info) error { return fmt.Errorf("%s on %s/%s", err.Error(), info.Mapping.Resource.Resource, info.Name) } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : let's say I run If the deployment is comes up in time it tells me which deployment is up, but if it times out it doesn't tell me on which deployment/resource. Could it be Why is this needed: That would make it easier to use, and the information provided is the same irregardless on whether the condition is met or not
/sig cli
Sounds reasonable for me, i can take care of this one if someone from owners will approve it as a feature.
/assign Zyqsempai
GitHub didn't allow me to assign the following users: Zyqsempai. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Zyqsempai 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:
# Detect instance group name generated by gke. # <del> # Note that this will only select instance groups in the same zone as the # cluster, meaning that it won't include all groups in a multi-zone cluster. </del> <ins> # Note that the NODE_INSTANCE_GROUPS var will only have instance groups in the # same zone as the cluster, meaning that it won't include all groups in a # multi-zone cluster. The ALL_INSTANCE_GROUP_URLS will contain all the # instance group URLs, which include multi-zone groups. </ins> # # Assumed vars: #   GCLOUD

Discussion:
The test job was passing consistently until midday on 6/18, e.g. Then it started failing consistently, e.g: ... with this error: 12:31:41 ... in gke:detect-node-instance-groups() 12:31:42 ERROR: (gcloud.compute.instance-) Some requests did not succeed: 12:31:42 - The resource 'projects/k8s-jkns-e2e-gke-multizone/zones/us-central1-f/instanceGroupManagers/gke-jenkins-e2e-default-pool--grp' was not found 12:31:42 Assigning to and to triage and assign someone to fix.
cc:
Almost certainly caused by . I'm not going to bother rushing in a rollback today since it's not a critical build, but could you fix this up tomorrow
Yeah, that's me. The change to support multiple MIGs in a single zone doesn't quite work. Didn't know of this test variation. Just to confirm, to run this test variation, the additional env vars I should set are (aside from the standard ones): export KUBERNETESPROVIDER=gke export ADDITIONALZONES=us-central1-a,us-central1-b Any other?
-- yet another instance of a PR passing all presubmit tests and breaking other jenkins jobs after being merged.
Can you tell me a bit more how this test is setup? I tried to do a "kube-" with the additional zones and it worked for me. My settings: export KUBERNETESPROVIDER=gke export ZONE=us-central1-f export CLOUDSDKBUCKET=gs://cloud-sdk-testing/ci/staging export CLOUDSDKAPIENDPOINTOVERRIDESCONTAINER=https://test- export ADDITIONAL_ZONES=us-central1-a,us-central1-b
Have you read ?
Oh, sorry, wrong link.
Take a look at and let me know if you need any more info.
The above PR was the one for GCE. The following is the one did for GKE. There are some relatively minor differences:
Hum, I'll have to dig a bit deeper. I tried the exact combination of env vars and my "kube-up" was successful (with the correct number of nodes across the zones).

Curious...
Any ETA, I'm getting tired of all the test failure emails :p
I think I found the problem. I have a workaround that'll make it work for now. I'm hoping sometime this afternoon.
The PR merged and gke-multizone Jenkins has gone green. Sorry for the trouble. There's still a larger issue of multi-zone handling in the test runner itself, but I think that's for another day.
Change:
wantPodStatus: v1.PodStatus{ Phase:   v1.PodFailed, Reason:  "Evicted", <del> Message: "The node was low on resource: ephemeral-storage. ", </del> <ins> Message: "The node was low on resource: ephemeral-storage. Threshold quantity: 2Gi, available: 1536Mi. ", </ins> }, }, }

Discussion:
when the pod is evicted due to low imagefs.available, the prompt is difficult to understand. it showed: But the container was evicted not by exceeding its request of 0 ephemeral-storage, but due to reaching the evictionHard of the node. The correct prompt message points out the reason for the pod eviction. don't print "which exceeds its request of 0.", because the container was evicted not by exceeding its request of 0. % oc label mcp worker custom-kubelet-eviction=small-pods evictionHard by creating a kubeletconfig % oc create -f custom-kubelet- custom-kubelet- several minutes, the mcp worker finish rolling out to the latest mc a pod % oc create -f hello-pod- hello-pod- a large file in container, make imagefs.available < 90Gi (the current available disk size is 111G ) command terminated with exit code 137 the node status the pod status % oc get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-pod-2 0/1 ContainerStatusUnknown 1 7m58s 10.131.0.7 ip-10-0-213- <none<none% oc get pod hello-pod-2 -o yaml No response <details</details<detailsaws </details<details</details<details</details<details</details<details</details
/sig node
/assign
/assign
/triage accepted
Change:
By("deleting host1ROPod") framework.ExpectNoError(podClient.Delete(host1ROPod.Name, &api.DeleteOptions{}), "Failed to delete host1ROPod") <ins> By("Test completed successfully, waiting for PD to safely detach") waitForPDDetach(diskName, host0Name) waitForPDDetach(diskName, host1Name) </ins> }) It("should schedule a pod w/ a RW PD shared between multiple containers, write to PD, delete pod, verify contents, and repeat in rapid succession [Slow]", func() {

Discussion:
PD E2E tests have very aggressive clean up routine that does not wait for volumes to safely detached. After the test completes, the test cleanup routine unilaterally detaches the PD (instead of waiting for k8s to do it cleanly). Although this does not cause the test to fail, it results in errors in the kernel logs: We should modify these tests to wait for k8s to safely detach the disk.
Change:
// wait a tick and then mark that we're finished (otherwise, we have no // way to indicate that we're finished, because the function decides not to do anything) time.Sleep(1 * time.Second) <ins> tc.Lock() </ins> tc.statusUpdated = true <ins> tc.Unlock() </ins> tc.processed <- "test-hpa" }()

Discussion:
What happened: The unit test for Horizontal Pod Autoscaler frequently deadlocked on the OpenShift CI system. What you expected to happen: The unit test should be robust and succeed without having to win a race condition to avoid deadlock. How to reproduce it (as minimally and precisely as possible): I'm not sure. Anything else we need to know?: Here are some logs of the problem happening: https://openshift-gce- The deadlocks seem to happen when the chan fills up while waiting for events. If that happens, there's a race where immediately after an event is read but before it can acquire the lock to verify the test, 2 event reactors are able to acquire the lock and write to the chan. The second will block forever since the chan is full and there's nobody to read from it. I've opened a PR with the fix. See
/sig autoscaling
/assign
Change:
// See https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ or https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration // for kube proxy official documentation. // <del> //    apiVersion: kubelet.config.k8s.io/v1beta2 </del> <ins> //    apiVersion: kubelet.config.k8s.io/v1beta1 </ins> //    kind: KubeletConfiguration //       ... // // The KubeletConfiguration type should be used to change the configurations that will be passed to all kubelet instances // deployed in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults. // <del> // See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or https://godoc.org/k8s.io/kubelet/config/v1beta2#KubeletConfiguration </del> <ins> // See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration </ins> // for kubelet official documentation. // // Here is a fully populated example of a single YAML file containing multiple

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! If the matter is security related, please disclose it privately via --What happened: references and a broken link to this (because it doesn't exist!) I'm guessing this was a bad find and replace when copying kubeadm's own v1beta1 to v1beta2 What you expected to happen: accurate documentation How to reproduce it (as minimally and precisely as possible): read the docs Anything else we need to know?: this template has a lot of fields :^) Environment: anything Kubernetes version (use ): n/a Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: kubeadm Network plugin and version (if this is a network-related bug): n/a Others: n/a /assign /sig cluster-lifecycle
Change:
old    networking.NetworkPolicy update networking.NetworkPolicy } <del> successCases := []npUpdateTest{ { </del> <ins> successCases := map[string]npUpdateTest{ "no change": { </ins> old: networking.NetworkPolicy{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: "bar"}, Spec: networking.NetworkPolicySpec{

Discussion:
I tried to update the NetworkPolicy Spec field with more ingress rules but got It seems NetworkPolicy does not allow update on Spec This means if I want to have more ingress rules, I will have to add those in a new networkpolicy in the same namespace. Any reason why I should not add those in the existing one(update the existing networkpolicy)? Thanks!
This is as designed for now. The expectation is that updates to the spec will be allowed when the NetworkPolicy API moves from v1beta1 to GA.
(And that is planned for Kubernetes 1.6 release.)
good to know, thanks!
Note that the PR to move NetworkPolicy to v1 did not make it into v1.6, but is now planned for 1.7:
Oh, I didn't know about this bug and that didn't get changed in but we can do it as another PR after. (I'm trying to not make any more changes there so we can get it merged.)
Change:
type TypeMeta struct { Kind              string    `json:"kind,omitempty" description:"kind of object, in CamelCase"` ID                string    `json:"id,omitempty" description:"name of the object; must be a DNS_SUBDOMAIN and unique among all objects of the same kind within the same namespace; used in resource URLs"` <del> UID               types.UID `json:"uid,omitempty" description:"UUID assigned by the system upon creation, unique across space and time"` CreationTimestamp util.Time `json:"creationTimestamp,omitempty" description:"RFC 3339 date and time at which the object was created; recorded by the system; null for lists"` SelfLink          string    `json:"selfLink,omitempty" description:"URL for the object"` ResourceVersion   uint64    `json:"resourceVersion,omitempty" description:"string that identifies the internal version of this object that can be used by clients to determine when objects have changed; value must be treated as opaque by clients and passed unmodified back to the server"` </del> <ins> UID               types.UID `json:"uid,omitempty" description:"unique UUID across space and time; populated by the system, read-only"` CreationTimestamp util.Time `json:"creationTimestamp,omitempty" description:"RFC 3339 date and time at which the object was created; populated by the system, read-only; null for lists"` SelfLink          string    `json:"selfLink,omitempty" description:"URL for the object; populated by the system, read-only"` ResourceVersion   uint64    `json:"resourceVersion,omitempty" description:"string that identifies the internal version of this object that can be used by clients to determine when objects have changed; populated by the system, read-only; value must be treated as opaque by clients and passed unmodified back to the server"` </ins> APIVersion        string    `json:"apiVersion,omitempty" description:"version of the schema the object should have"` Namespace         string    `json:"namespace,omitempty" description:"namespace to which the object belongs; must be a DNS_SUBDOMAIN; 'default' by default"`

Discussion:
Right now we have haphazard comments regarding which fields are read-only/output-only, and many, such as aren't documented at all. Swagger 2.0 actually supports a property tag, but we're using Swagger 1.2, which does not, officially. The official meaning doesn't match what we want, though. fields must not be included in a PUT, which would be painful for clients. We could simply document our convention, however. We should tag fields as readonly. Maybe we could have go-restful automatically add a comment to the description in that case.
/cc
Are there any known obstacles with upgrading to 2.0?
go-restful (the framework that we are using to generate swagger-spec) does not support 2.0 yet:
Disclaimer: for the doc-fix it day, I will be adding the read-only information into the description. This partially resolves this issue, but not entirely. I will unassign myself after description is done.
Note: users can set the node status when creating a node. This is a bug and should be fixed. After fixing that bug, the corresponding description should be updated.
Change:
}{ { parent:   ss1, <del> revision: ss1Rev1, </del> <ins> revision: ss1Rev2, </ins> }, }, rename: true,

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: What happened: When a statefulset object is created, a lot of controllerrevisions are created at the same time. the controllerrevisions have differenct hash value but the same Data.Raw. How to fix it: two controllerrevisions are seen as the same , when [ControllerRevisionHashLabel] , Controllerrevision.Data.Raw , Controllerrevision.Data.Object are strictly the same // this line shoud be to fix the bug like below: Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.8 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I would help fix it
/kind bug /sig apps
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 /remove-lifecycle stale
StatefulSet uses the following code to construct its history object (controllerrevision): However, collisionCount shouldn't be blindly increased when there's name collision. Because controller uses a cache store, the name collision could be due to a controllerrevision created but not yet observed by the controller. The right way to handle it is to first check if the controllerrevision with the same name has the same content as the one we're going to create, like how DaemonSet controller handles it:
Change:
if hc != nil { hcNames = append(hcNames, hc.Name) } <del> if err := gceCloud.DeleteExternalTargetPoolAndChecks(loadBalancerName, gceCloud.Region(), hcNames...); err != nil && </del> <ins> if err := gceCloud.DeleteExternalTargetPoolAndChecks(loadBalancerName, region, hcNames...); err != nil && </ins> !IsGoogleAPIHTTPErrorCode(err, http.StatusNotFound) { retErr = fmt.Errorf("%vn%v", retErr, err) }

Discussion:
In federation tests, if we observe the build logs. we see cleaning up LoadBalancer from cloud provider seems not working. It has 2 effects: delays the tests by waiting to delete but always returns error. so we waste like 5 minutes. maybe we are leaking the LoadBalancer in the project.
we can see these errors in every build. but just for reference here are some build logs https://k8s-
cc
All the errors in logs are . It doesn't necessarily indicate we are leaking resource, just now we must have clusterID initialized before calling EnsureLoadBalancerDeleted(). Would be better to not call this function directly in e2e test :)
Federation cleanup should use the same implementation as non-federated e2e test:
function looks like only specific to GCE. in future we would run the e2e tests in AWS too. it would be better to use generic functions if any.
using is working for us. here is the test logs https://k8s-
EnsureLoadBalancerResourcesDeleted() actually cleans up nothing, it only lists forwarding rules and probably logging :)
Change:
function run-gcloud-compute-with-retries { RETRIES="${RETRIES:-3}" for attempt in $(seq 1 ${RETRIES}); do <del> local -r gcloud_result=$(gcloud compute "$@" 2>&1) local -r ret_val="$?" </del> <ins> # We don't use 'local' to declare gcloud_result as then ret_val always gets value 0. gcloud_result=$(gcloud compute "$@" 2>&1) || local ret_val="$?" </ins> echo "${gcloud_result}" <del> if [[ "${ret_val}" -ne "0" ]]; then </del> <ins> if [[ "${ret_val:-0}" -ne "0" ]]; then </ins> if [[ $(echo "${gcloud_result}" | grep -c "already exists") -gt 0 ]]; then if [[ "${attempt}" == 1 ]]; then echo -e "${color_red}Failed to $1 $2 $3 as the resource hasn't been deleted from a previous run.${color_norm}" >& 2

Discussion:
I'm seeing the following in my logs: There was an errors, and we silently skipped it.
Good catch! Thanks for pointing.
Change:
// Empty if the Pod has no claims. claims []*resourcev1alpha2.ResourceClaim <del> // The AvailableOnNodes node filters of the claims converted from the // v1 API to nodeaffinity.NodeSelector by PreFilter for repeated // evaluation in Filter. Nil for claims which don't have it. availableOnNodes []*nodeaffinity.NodeSelector </del> // The indices of all claims that: // - are allocated // - use delayed allocation

Discussion:
The node selectors gets parsed by in for each node. That work can be done once in . Better performance.
/sig node /sig scheduling /triage accepted /priority backlog
I can try this one. /assign