jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> type buffer struct { b  bytes.Buffer rw sync.RWMutex } func (b *buffer) String() string { b.rw.RLock() defer b.rw.RUnlock() return b.b.String() } func (b *buffer) Write(p []byte) (n int, err error) { b.rw.Lock() defer b.rw.Unlock() return b.b.Write(p) } </ins> func Test_managerImpl_processShutdownEvent(t *testing.T) { var ( probeManager   = probetest.FakeManager{}

Discussion:
There seems to be a race condition in the following unit test The race happens between read at and write at No race condition CI logs where race was detected: <details</details<details</details<details</details<details</details<details</details<details</details
/sig node /cc
/remove-kind bug /kind flake (potential flake, did not use the flake template because CI is green for this test)
A related pr merged
/assign
Thanks for checking again. fyi
Maybe we need something like this:
are u working on resolve this issue? i wonder why doesn't face a race condition
I think he's still working on it. The race condition doesn't happen there because doesn't start another go routine. In the kubelet's case however, the write part of the race condition happens in another go routine that is spawned: write:
/triage accepted /priority important-soon
seen in this spiked in the last couple days - is this related to the klog bump ()? cc /priority critical-urgent /milestone v1.24
increasing priority since it is impacting test runs, and marking as blocker until root caused and we understand whether it is prod-impacting
/assign ^ I'll take this one up on monday - still feel free to open a PR if you have WIP investigation/research
please see if you have comments/inputs on the already open one.
I don't see how the klog bump could have made it worse. Perhaps the change around the flush daemon changed some timing conditions, but that's a rather wild guess. These tests have been faulty all along and need to be fixed. What klog can do is support unit tests like this better. I've opened two issues: short term: long term as it depends on contextual logging:
I think it's safe to remove the release-blocker here. The root cause is largely as explained here: (appears to be test-only)
Change:
// Install adds the DefaultMetrics handler func (m DefaultMetrics) Install(c *mux.PathRecorderMux) { <ins> register() </ins> c.Handle("/metrics", prometheus.Handler()) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: endpoint of different k8s components expose Prometheus metrics that are not for them. For example, exposes metrics: or : What you expected to happen: Prometheus metrics only for to appear on kubelet's endpoint. How to reproduce it (as minimally and precisely as possible): Access the endpoint of all Kubernetes components Anything else we need to know?: This problem comes from usage of functions in different packages that automatically register Prometheus metrics. Just importing that package or some package that depends on it can cause those metrics to appear in unexpected places. In the list bellow you can find the different packages that have init functions and affected binaries: [ ] () cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] () cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubectl kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubelet [ ] hyperkube kube-apiserver kube-controller-manager [ ] hyperkube kube-apiserver [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubelet Environment: Kubernetes version (use ):Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A /sig instrumentation
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
Change:
function kubectl-with-retry() { ERROR_FILE="${KUBE_TEMP}/kubectl-error" <ins> preserve_err_file=${PRESERVE_ERR_FILE-false} </ins> for count in $(seq 0 3); do kubectl "$@" 2> ${ERROR_FILE} || true if grep -q "the object has been modified" "${ERROR_FILE}"; then

Discussion:
cc
Assigning to per test-
Flaked again
The flake actually happened when pausing the deployment. Changing issue title.
When , sometimes one of the deployments isn't paused. cc
I can't access the internal Google logs to examine the cause, nor can I reproduce this issue locally. Is there any additional information that you can provide to help troubleshoot the flake?
I've gone ahead and attempted a fix for this in
We should fix this in eventually
the external links are here ():
Change:
t.Fatalf("Unexpected error: %v", err) } <del> watching, err := h.Watch(context.TODO(), key, "0", storage.Everything) </del> <ins> watching, err = h.Watch(context.TODO(), key, "0", storage.Everything) </ins> if err != nil { t.Fatalf("Unexpected error: %v", err) } defer watching.Stop() <del> // marked as modified b/c of concatenation event := <-watching.ResultChan() if event.Type != watch.Modified { </del> <ins> // because we watch from 0, first event that we receive will always be ADDED event = <-watching.ResultChan() if event.Type != watch.Added { </ins> t.Errorf("Unexpected event %#v", event) }

Discussion:
Currently, Watch request with resourceVersion=0 results in: returning a single "watch event" for every object existing "now" starts watching from that point This is pretty misleading (e.g. it's different that what we have in etcd, where there is no first step from above). In the v2 api, we should probably eliminate the first stop (or even disallow watch requests with resourceVersion = 0).
/cc
Issues go stale after 30d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
/remove-lifecycle rotten /lifecycle frozen
What do you mean by v2 API? Are we ever going to have a v2 of the machiery and semantics?
In 2015 I thought it's not ridiculous. I'm not sure I believe in it now. Moreover, with we will actually be taking benefits of semantic like this, so we should close this.
Change:
[developer's documentation]: https://git.k8s.io/community/contributors/devel#readme [Docker environment]: https://docs.docker.com/engine [Go environment]: https://go.dev/doc/install <del> [interactive tutorial]: https://kubernetes.io/docs/tutorials/kubernetes-basics </del> [kubernetes.io]: https://kubernetes.io [Scalable Microservices with Kubernetes]: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615 [troubleshooting guide]: https://kubernetes.io/docs/tasks/debug/

Discussion:
Hello, Upon visiting the . There is a link for interactive tutorial which is being inactive. Error from (k8 page)[] is ! We have to remove the page link.
label:sig/docs
/sig docs /kind documentation
Per let's delete this reference for now and we can add something later potentially following
/triage accepted /assign
Change:
"sort" "strings" "sync" <ins> "time" </ins> "github.com/containernetworking/cni/libcni" cnitypes "github.com/containernetworking/cni/pkg/types" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/klog" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2"

Discussion:
What happened: When Node's iops is full, the Node status becomes to be NotReady. The NotReady message is "Container runtime is not ready". After our troubleshoot, we found func in cni package costs more then 30s, then the runtime status health check is failed : What you expected to happen: Node should still be in Ready status when iops is full. Because the CNI config files does not change. How to reproduce it (as minimally and precisely as possible): Run an application to fill disk IO bandwidth, then the Node becomes to be NotReady. Anything else we need to know?: Nothing yet. Environment: Runtime is dockershim. Other environment is no need to pay attention.
/assign /sig-node
/sig node /sig network
Change:
"fmt" "strings" <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/util/validation/field" podutil "k8s.io/kubernetes/pkg/api/pod" api "k8s.io/kubernetes/pkg/apis/core"

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: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:
Change:
DNS_SERVER_IP=${KUBE_DNS_SERVER_IP:-10.0.0.10} DNS_DOMAIN=${KUBE_DNS_NAME:-"cluster.local"} KUBECTL=${KUBECTL:-cluster/kubectl.sh} <del> WAIT_FOR_URL_API_SERVER=${WAIT_FOR_URL_API_SERVER:-10} </del> <ins> WAIT_FOR_URL_API_SERVER=${WAIT_FOR_URL_API_SERVER:-20} </ins> ENABLE_DAEMON=${ENABLE_DAEMON:-false} HOSTNAME_OVERRIDE=${HOSTNAME_OVERRIDE:-"127.0.0.1"} CLOUD_PROVIDER=${CLOUD_PROVIDER:-""}

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): local-up- Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: KVM OS (e.g. from /etc/os-release): fedora 25 Kernel (e.g. ): uname -a Linux k8sbuild-master 4.11.3-200.fc25.x8664 SMP Thu May 25 19:03:07 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others: What happened: local-up- fails to create kube-dns and StorageClass. What you expected to happen: local-up- is successfully executed. How to reproduce it (as minimally and precisely as possible): 1) Clone kubernetes from master branch 2) run local-up- $ export ENABLEHOSTPATHPROVISIONER="true"; ./hack/local-up- If you already have kubernetes , try this 1) make cleanmeta 2) run local-up- $ export ENABLEHOSTPATHPROVISIONER="true"; ./hack/local-up- Anything else we need to know: I think this problem is timing issue because sleeping 3 seconds before startkubedns can avoid this problem.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team.

You can find the team list and label list
/sig testing /sig storage /sig network
/sig apps
I met the same issue we should add a function to check if all api-versions are up
Change:
} return GetUUIDFromProviderID(node.Spec.ProviderID), nil } <ins> func GetVMUUID() (string, error) { uuidFromFile, err := getRawUUID() if err != nil { return "", fmt.Errorf("error retrieving vm uuid: %s", err) } //strip leading and trailing white space and new line char uuid := strings.TrimSpace(uuidFromFile) // check the uuid starts with "VMware-" if !strings.HasPrefix(uuid, UUIDPrefix) { return "", fmt.Errorf("Failed to match Prefix, UUID read from the file is %v", uuidFromFile) } // Strip the prefix and white spaces and - uuid = strings.Replace(uuid[len(UUIDPrefix):(len(uuid))], " ", "", -1) uuid = strings.Replace(uuid, "-", "", -1) if len(uuid) != 32 { return "", fmt.Errorf("Length check failed, UUID read from the file is %v", uuidFromFile) } // need to add dashes, e.g. "564d395e-d807-e18a-cb25-b79f65eb2b9f" uuid = fmt.Sprintf("%s-%s-%s-%s-%s", uuid[0:8], uuid[8:12], uuid[12:16], uuid[16:20], uuid[20:32]) return uuid, nil } </ins>

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: Running the vSphere cloud provider on a windows node throws the following error: This is because the vm identifier is retrieved with the command - , which assumes that the uuid and serial are the same. On some vmware vm versions, the uuid and serial are not the same. vmware (comment), vmware (comment) What you expected to happen: Kubelet is able to find vm in vCenter from the identifier looked up on the node. or should be used instead to find the vm identifier. How to reproduce it (as minimally and precisely as possible): Issue only occurs on some vm versions, such as 13. Anything else we need to know?: On the linux side, this issue was resolved by switching from looking up the id from to . See Some discussion about this issue here - Environment: Kubernetes version (use ): 14.0-beta.1 Cloud provider or hardware configuration: Vsphere OS (e.g: ): Windows 2019 Kernel (e.g. ): Install tools: Others:
/sig windows /sig vmware
/milestone v1.14
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.14 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
Change:
expectDelete: false, }, { <del> description:  "naked pod with --force", node:         node, expected:     cordonedNode, pods:         []corev1.Pod{nakedPod}, rcs:          []corev1.ReplicationController{}, args:         []string{"node", "--force"}, expectFatal:  false, expectDelete: true, </del> <ins> description:           "naked pod with --force", node:                  node, expected:              cordonedNode, pods:                  []corev1.Pod{nakedPod}, rcs:                   []corev1.ReplicationController{}, args:                  []string{"node", "--force"}, expectFatal:           false, expectDelete:          true, expectOutputToContain: "node/node drained", </ins> }, { description:  "pod with EmptyDir",

Discussion:
When draining a node, using kubectl drain [NODE], the output resembles this: Expected output should indicate that the node was drained, for example: kubectl drain [NODE] No response <details</details<detailsCan reproduce locally using and printing the output </details<details</details<details</details<details</details<details</details
/sig cli
/triage accepted
Change:
accBody:    "User-Agent: kube-probe/", }, { <ins> handler: headerEchoHandler, reqHeaders: http.Header{ "User-Agent": {"foo/1.0"}, "Accept":     {"text/html"}, }, health:  probe.Success, accBody: "Accept: text/html", }, { handler: headerEchoHandler, reqHeaders: http.Header{ "User-Agent": {"foo/1.0"}, "Accept":     {"foo/*"}, }, health:  probe.Success, accBody: "User-Agent: foo/1.0", }, { handler: headerEchoHandler, reqHeaders: http.Header{ "X-Muffins-Or-Cupcakes": {"muffins"}, "Accept":                {"foo/*"}, }, health:  probe.Success, accBody: "X-Muffins-Or-Cupcakes: muffins", }, { handler: headerEchoHandler, reqHeaders: http.Header{ "Accept": {"foo/*"}, }, health:  probe.Success, accBody: "Accept: foo/*", }, { handler: headerEchoHandler, reqHeaders: http.Header{ "Accept": {""}, }, health:  probe.Success, notBody: "Accept:", }, { handler: headerEchoHandler, reqHeaders: http.Header{ "User-Agent": {"foo/1.0"}, "Accept":     {""}, }, health:  probe.Success, notBody: "Accept:", }, { handler:    headerEchoHandler, reqHeaders: http.Header{}, health:     probe.Success, accBody:    "Accept: */*", }, { </ins> // Echo handler that returns the contents of Host in the body handler: func(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : I would like that besides User-agent we the Accept header as well with the "acept all" default. Just like curl does. Why is this needed: Because it was my expectation that the probe would work similarly to a curl but is not the case. I think more folks can hit this situation and waste some time to finally sort it out If this is not something you would like to add I would then like the docs to mention this specifically. _ PS: I would love to propose the improvement my self
/sig node network
/assign
Is the goal simply to avoid tripping over servers that look for that header? I don't think this presents any hazards - is that right? If so, it seems like a simple PR if you want to tackle it. /triage accepted /kind feature
cool! will look into it! thanks :)
Hello sorry but be bugging you, but I have opened the PR but I had 0 response since then. I think I have met all the requirements, so I was wondering (as this is my first PR in k8s) if you could help me a bit. Thanks anyway.
Change:
"k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apiserver/pkg/endpoints/metrics" <del> "k8s.io/apiserver/pkg/endpoints/responsewriter" </del> <ins> "k8s.io/apiserver/pkg/server/httplog" </ins> "k8s.io/klog/v2" )

Discussion:
panics with error when health probes time out. The following stack trace shows this error (from an apiserver that uses : The is thrown by net/http because attempts to call after the request had timed out (handler had completed) here is the code site that triggers the panic (on master): Is there any historical context why we use the original by calling . If we use the decorated object then the panic will be prevented: uses the underlying object only when the request handler has not completed yet. No panic hard to reproduce, maybe we should add a unit test to reproduce the issue.
/sig api-machinery cc
/assign
GitHub didn't allow me to assign the following users: benluddy. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
/triage accepted
Change:
"description": "Human readable message indicating details about last transition." } } <ins> }, "v1beta1.Scale": { "id": "v1beta1.Scale", "description": "represents a scaling request for a resource.", "properties": { "kind": { "type": "string", "description": "Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#types-kinds" }, "apiVersion": { "type": "string", "description": "APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#resources" }, "metadata": { "$ref": "v1.ObjectMeta", "description": "Standard object metadata; More info: http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#metadata." }, "spec": { "$ref": "v1beta1.ScaleSpec", "description": "defines the behavior of the scale. More info: http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-status." }, "status": { "$ref": "v1beta1.ScaleStatus", "description": "current status of the scale. More info: http://releases.k8s.io/HEAD/docs/devel/api-conventions.md#spec-and-status. Read-only." } } }, "v1beta1.ScaleSpec": { "id": "v1beta1.ScaleSpec", "description": "describes the attributes of a scale subresource", "properties": { "replicas": { "type": "integer", "format": "int32", "description": "desired number of instances for the scaled object." } } }, "v1beta1.ScaleStatus": { "id": "v1beta1.ScaleStatus", "description": "represents the current status of a scale subresource.", "required": [ "replicas" ], "properties": { "replicas": { "type": "integer", "format": "int32", "description": "actual number of observed instances of the scaled object." }, "selector": { "type": "any", "description": "label query over pods that should match the replicas count. More info: http://releases.k8s.io/HEAD/docs/user-guide/labels.md#label-selectors" } } </ins> } } }  No newline at end of file

Discussion:
e.g. scale up if CPU usage exceeds 70% of CPU request. Subtasks: [x] Add API changes [x] Add implementation [x] Add support in kubectl to print status with cpu request utilization [x] Add e2e tests
I've sent main PR for review (). During your day/my night please look into kubectl changes and e2e tests.