jiebi/CodeConvo huggingface dataset:
Change:
nodeRef:      nodeRef, } <del> err := im.start() if err != nil { return nil, fmt.Errorf("failed to start image manager: %v", err) } </del> return im, nil } <del> func (im *realImageManager) start() error { </del> <ins> func (im *realImageManager) Start() error { </ins> // Initial detection make detected time "unknown" in the past. var zero time.Time err := im.detectImages(zero)

Discussion:
I'm trying to start 100-node cluster. I got the following error in kubelet: E0505 08:31:55. 5066 ] Failed to create kubelet: failed to initialize image manager: failed to start image manager: dial unix connection refused After ssh-ing I checked that docker is working by running . I guess it must be some kind of a race where kubelet starts before docker is ready. When I start 3-node cluster it works just fine. This happened to me 3 times in a row. Please add this to 1.0 milestone if necessary.
I've just exactly the same problem (when creating a 100-node cluster)
This is a bug in our initialization logical. We initialize image manager which needs to talk to docker at very early stage before docker is up yet. Later kubelet does a wait to make sure docker is up. We should either delay the initialization of image manager or handle docker unavailable better. Kubelet will be restarted by monit eventually, but this definitely slow down node initialization. I mark this for 1.0. Should be a simple fix if we just simply delay the initialization of image manager.
I'll go ahead and fix it (since I am mainly to blame :) )
Changed to P0 because asked us to only add P0 issues to v1.0 milestone.
Change:
func findDiskByLun(lun int, io ioHandler, exec mount.Exec) (string, error) { return "", nil } <del> func formatIfNotFormatted(disk string, fstype string, exec mount.Exec) { } </del>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When use an existing azure disk(also called ) in pod, if that disk has partitions, the disk will be formatted in the pod mounting. What you expected to happen: How to reproduce it (as minimally and precisely as possible): create a disk with source from an os disk, e.g. that disk is already formatted before pod could access it Anything else we need to know?: Root cause: current diskLooksUnformatted func is using command to check whether disk is formatted or not while common k8s code() is using to detect disk format, could detect multiple partitions so if we use common k8s code(), following error will be returned for mulitple partition disks, which is expected: Environment: Kubernetes version (use ): v1.7 - v1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
cc
iirc we don't support partitions on Azure volumes. There was a specific hang long ago. in all cases i think should be safe to based check now via the underlaying api
thanks for the info, I am writing this PR, and also testing carefully. And this issue depends on , could you review it first? Thanks.
Change:
<br> If the webhook is running within the cluster, then you should use <code>service</code>.<br> <br> <del> If 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.</p></td> </del> <ins> Port 443 will be used if it is open, otherwise it is an error.</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">true</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#_v1beta1_servicereference">v1beta1.ServiceReference</a></p></td> <td class="tableblock halign-left valign-top"></td>

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:
} createNode2NormalPodEviction := func(client clientset.Interface) func() error { return func() error { <ins> zero := int64(0) </ins> return client.Policy().Evictions("ns").Evict(&policy.Eviction{ TypeMeta: metav1.TypeMeta{ APIVersion: "policy/v1beta1",

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 using the function from Python's Kuberneets API, we noticed that Pods are terminated bythe cluster without respecting their preStop hooks or terminationGracePeriodSeconds seconds. What you expected to happen: When using the eviction API, just as when using delete, Pods should be allowed to run their preStop hooks, as well as be given terminationGracePeriodSeconds before being terminated with SIGKILL. How to reproduce it (as minimally and precisely as possible): the following pod: the pod logs in another window to evict the pod. Here is a sample curl equivalent of what (1.13) is doing - happy path: Here is a sample curl equivalent of what Python's is doing (when not passed ) - broken path: The log output generated by the guinea pod on the happy path looks like this: The "Got signal 15" message shows up only after the preStop hook is finished, so ~10 seconds after the evict call is made What happens on the broken path is: We seem to be getting 2x SIGTERM, there are no messages indicating continued processing after the signal, and the signal itself is registered immediately after the eviction call is made, suggesting that preStop didn't run. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CentOS Linux release 7.5.1804 Kernel (e.g. ): 3.10.0-862.14.4.el7.x8664 SMP Wed Sep 26 15:12:11 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: in-house Others:
/sig api-machinery
this is because of this code: invoked from here: it is passing in the eviction delete options field as-is, meaning nil gets propagated and defaulted to mean delete immediately. when calling delete APIs normally, delete options defaults to a non-nil empty set of options:
Fixed in
patch looks legit. Thanks for the quick reaction and for the pointers!
I've a elasticsearch stateful set which have a preHook which never completes and the pod is never killed despite terminationGracePeriodSeconds being set.

Is it related ? If so can this be considered to be cherry-picked on v1.13.x release branch ?
Change:
// Until is a wrapper around workqueue.ParallelizeUntil to use in scheduling algorithms. // A given operation will be a label that is recorded in the goroutine metric. func (p Parallelizer) Until(ctx context.Context, pieces int, doWorkPiece workqueue.DoWorkPieceFunc, operation string) { <ins> goroutinesMetric := metrics.Goroutines.WithLabelValues(operation) </ins> withMetrics := func(piece int) { <del> metrics.Goroutines.WithLabelValues(operation).Inc() defer metrics.Goroutines.WithLabelValues(operation).Dec() </del> <ins> goroutinesMetric.Inc() </ins> doWorkPiece(piece) <ins> goroutinesMetric.Dec() </ins> } workqueue.ParallelizeUntil(ctx, p.parallelism, pieces, withMetrics, workqueue.WithChunkSize(chunkSizeFor(pieces, p.parallelism)))

Discussion:
We observed degradation in scheduling throughput, putting it under 100 pods/s pprof points to ! /sig scheduling /kind regression 100 pods/s N/A No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/assign cc
/triage accepted
Oh.. sorry for the degradation and thanks for working on this. This time, as goroutine metric is called every time goroutine is created, we observed the clear performance degradation. But, there are actually many other metrics which is stored directly by calling everytime. So, for the future direction, is it better (slightly?) for the performance to move all other metrics to store via ? (like metric)
No need to be sorry. Just tagging you as FYI so that we are aware of this kind of performance penalties in future reviews :)
No, this code is too complex to be worth it. The rest of the metrics usage doesn't show up in pprofs, so no need to optimize further for now. We just need to be diligent not to call within critical routines when they all share the same values.
Change:
. "github.com/onsi/ginkgo" . "github.com/onsi/gomega" apps "k8s.io/api/apps/v1beta1" <ins> appsv1beta2 "k8s.io/api/apps/v1beta2" </ins> "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" klabels "k8s.io/apimachinery/pkg/labels"

Discussion:
What happened: There are no e2e and integration tests for statefulset scale subresource. What you expected to happen: (1) e2e test should exist BEFORE code freeze (2) integration test should exist AFTER 1.8 release branches cut Anything else we need to know?: Refer PR for more info. We should NOT remove existing e2e test.
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. 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
/close
Change:
} } // Delete dummy interface created by ipvs Proxier. <del> nl := NewNetLinkHandle() </del> <ins> nl := NewNetLinkHandle(false) </ins> err := nl.DeleteDummyDevice(DefaultDummyDevice) if err != nil { klog.Errorf("Error deleting dummy device %s created by IPVS proxier: %v", DefaultDummyDevice, err)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area ipv6 /area ipvs /sig network What happened: In an ipv6-only cluster with proxy-mode=ipvs the entries for NodePort in ipvs are created for ipv4 addresses. The target's (if there are any) consists of ipv6 addresses (wrongly) interpreted as ipv4; Attempts to use the NodePort with ipv6 addresses are black-holed. What you expected to happen: Ipv6 addresses to the nodes should be used for NotePort and the LB-targets shall be the ipv6 address of the pods. Traffic to NodePorts shall be distributed among the (ipv6) endpoints. How to reproduce it (as minimally and precisely as possible): Setup an ipv6-only cluster Create a service with type with endpoints Try to connect to the NodePort Do Anything else we need to know?: The nodes have both ipv4 and ipv6 addresses and it is possible that if the nodes only had ipv6 addresses it would work (I havn't tested). But even in an ipv6-only k8s cluster the nodes almost always need ipv4 addresses for other purposes. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm VMs on Ubuntu 18.04.01 LTS OS (e.g. from /etc/os-release): Own BusyBox based system Kernel (e.g. ):Install tools: None Others:
The NodeIPs() function seem to return only ipv4 addresses.
I can't see why (yet) since is used in the GetLocalAddresses function
/cc Please give a hint before I dive into the netlink code.
This issue is used as an example here;
The functions filters on Src != nil . But ipv6 addresses seems to have Src == nil always. As it is this function will never return any ipv6 addresses.
Change:
}) AfterEach(func() { <ins> By("Stop and wait for recycle goroutine to finish") close(stopCh) wg.Wait() By("Clean all PVs") </ins> for nodeName, localVolumes := range allLocalVolumes { By(fmt.Sprintf("Cleaning up %d local volumes on node %q", len(localVolumes), nodeName)) cleanupLocalVolumes(config, localVolumes) } cleanupStorageClass(config) <del> By("Wait for recycle goroutine to finish") close(stopCh) wg.Wait() </del> }) It("should be able to process many pods and reuse local volumes", func() {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-serial Which test(s) are failing: [sig-storage] PersistentVolumes-local Stress with local volumes [Serial] should be able to process many pods and reuse local volumes Since when has it been failing: since introduction Testgrid link: https://k8s- Reason for failure: Anything else we need to know:
/assign
/reopen 1 failure out of recent 4 builds since is merged, will make it stable
Reopened this issue. <detailsIn response to : /reopen 1 failure out of 4 builds since is merged, will make it stable 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
This failure is because kubelet is restarted serval times during testing. fail time of test: Note that after , the rest 3 pods cannot finish. This is because kubelet is restarted serval times in this period of time. Output of : The rest 3 jobs was assigned to this node, it cannot finished because kubelet is restarted repeatedly. Because all tests in this job is run serially. I'm not sure what caused kubelet to restart during this test is running. kubelet.service is configured with following configurations: With , kubelet may be restarted by clean/unclean signal, exit code or watchdog, timeout. And may kill it when it failed to , here is kubelet-
I guess these kubelet restarts are not expected, but fixing it is beyond my ability. One workaround is to increase timeout to tolerate them, what do you think? Because we check pod conditions periodically, it will not slow down test.
Maybe we need to get some help from node team to figure out why kubelet is restarting. cc
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
This test has not flaked in almost 2 weeks. /close
Closing this issue. <detailsIn response to : This test has not flaked in almost 2 weeks. /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:
fi } <del> # Verify and find the various tar files that we are going to use on the server. # # Vars set: #   SERVER_BINARY_TAR #   SALT_TAR function find-release-tars { SERVER_BINARY_TAR="${KUBE_ROOT}/server/kubernetes-server-linux-amd64.tar.gz" if [[ ! -f "$SERVER_BINARY_TAR" ]]; then SERVER_BINARY_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-server-linux-amd64.tar.gz" fi if [[ ! -f "$SERVER_BINARY_TAR" ]]; then echo "!!! Cannot find kubernetes-server-linux-amd64.tar.gz" >&2 exit 1 fi SALT_TAR="${KUBE_ROOT}/server/kubernetes-salt.tar.gz" if [[ ! -f "$SALT_TAR" ]]; then SALT_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-salt.tar.gz" fi if [[ ! -f "$SALT_TAR" ]]; then echo "!!! Cannot find kubernetes-salt.tar.gz" >&2 exit 1 fi } </del> # Use the gcloud defaults to find the project.  If it is already set in the # environment then go with that. #

Discussion:
I suspect we're going through an if/else clause where KUBETARURL isn't defined, and not defaulting it, though the function header seems to indicate it should be set in the callee.
Will take a look.
Is this in Jenkins, or on a local run? The Jenkins push job is borked as well, but it looks like it's for a different reason: Which I'm taking care of in .
Jobs are generating incredibly large log files (300 Megs?) with lots of repeated lines like this: Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 I think this needs to be resolved, since it already caused an out-of-disk in Jenkins.
Okiedokie. Yes, this was my fault. silently expects and to be set in . I the extra expectation that be set, but didn't think about how would then also have to set that. Working on a fix.
(For anyone who cares, culprit is .)
Change:
klog.V(4).Infof("Updating %s", castObj.Name) c.enqueue(castObj) } <ins> func (c *ConditionController) deleteCustomResourceDefinition(obj interface{}) { castObj, ok := obj.(*apiextensions.CustomResourceDefinition) if !ok { tombstone, ok := obj.(cache.DeletedFinalStateUnknown) if !ok { klog.Errorf("Couldn't get object from tombstone %#v", obj) return } castObj, ok = tombstone.Obj.(*apiextensions.CustomResourceDefinition) if !ok { klog.Errorf("Tombstone contained object that is not expected %#v", obj) return } } c.lastSeenGenerationLock.Lock() defer c.lastSeenGenerationLock.Unlock() delete(c.lastSeenGeneration, castObj.Name) } </ins>

Discussion:
/sig api-machinery /kind bug /assign sttts because the controller that maintains the condition runs multiple instances in HA apiserver clusters, the controller must not duel in cases where the validation messages change slightly between releases
Change:
docs/user-guide/kubectl/kubectl_set_image.md docs/user-guide/kubectl/kubectl_set_resources.md docs/user-guide/kubectl/kubectl_set_selector.md <ins> docs/user-guide/kubectl/kubectl_set_serviceaccount.md </ins> docs/user-guide/kubectl/kubectl_set_subject.md docs/user-guide/kubectl/kubectl_taint.md docs/user-guide/kubectl/kubectl_top.md

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): HEAD Now that RBAC is going to GA, using ServiceAccounts is getting more and more important. Still a lot of users run their apps/addons/whatever in the SA. In order for the admin to be able to change ServiceAccount easily after an application has been installed (which supposedly is crashlooping due to insufficient privs), a command could exist. I know I can do this: but for new users to Kubernetes, it's non-obvious. Proposed command: Tracking issue: WDYT? This would be a good way for a new contributor to get aquainted with the code by contributing this feature.
Is anyone working on this? If not I would like to take this up.
Nobody is working on this. I would be super happy if you could contribute this feature. Be aware of that there isn't consensus around this proposal yet (I proposed it yesterday, saturday, so people haven't had time to catch up on it) However, I do think that this is in line with , so feel free to start working on this if you want to ;) Also, don't hesitate to ask for help if you don't know how to get started and we'll help out! Thanks!
I'm in favor of this command. ?
Thanks, I will start working on this.
Is the SA on a Pod mutable or immutable? What about DaemonSet and StatefulSet? Do those have SA as well? Is there a way to do this so that it dynamically supports anything with a PodTemplate? Maybe this should be done as a subresource that can be dynamically discovered by kubectl using the discovery service.
Maybe helpful:
Pod is immutable. All the other objects (with the exception of stateful set) are mutable.
That pattern is the same for all the things that set aspects of a pod spec (except image, which is also mutable in pods)
Statefulsets are going to loosen their validation soon I expect.
This sounds good to me. just go ahead, I will help review this. Thanks ~
The outout of this command kubectl get rc/nginx-controller -o=yaml , has service acccount at the following path '' , and the corresponding pod has service account at 'spec.serviceAccountName'.

Both refer to the 'serviceAccountName' field of PodSpec struct but can be made to be different by patching the ReplicationController resource. How does ReplicationController and Pod use serviceAccountName differently? Shouldn't the ReplicationControllerSpec have a serviceAccountName field?
ptal, I think you are more familiar with ReplicationController implementation than me.
ReplicationController contains a pod spec object, which contains a serviceAccountName.
Hi , how to go about writing e2e test cases for this. My development is mostly complete.
I wouldn't mind if you posted the PR now and then we'd see what e2e test makes sense to have. In order to move forward...
what are the next steps?
Change:
accessModes: - ReadWriteOnce hostPath: <del> path: /tmp/pv-2 </del> <ins> path: /tmp/data/pv-2 </ins>

Discussion:
Version: Running this example on RHEL 7.2 (assume same for centos), and using hostPath, I get a permissions error when the mysql container does a . If I set selinux to permissive on the host it works. If I manually run the container with it works. I was not able to get it to work when adding to the deployment. My fix was to locate the PVs in by changing the local- file, and doing . I this comment to local- If this issue is valid I will create a quick PR to doc this selinux solution.
See pr