Question: func NewResourceManager(path string) ResourceManager { scheme := runtime.NewScheme() <del> // Register conversion for apidiscovery apidiscoveryv2.SchemeBuilder.Register(apidiscoveryv2conversion.RegisterConversions) </del> utilruntime.Must(apidiscoveryv2.AddToScheme(scheme)) utilruntime.Must(apidiscoveryv2beta1.AddToScheme(scheme)) <ins> // Register conversion for apidiscovery utilruntime.Must(apidiscoveryv2conversion.RegisterConversions(scheme)) </ins> codecs := serializer.NewCodecFactory(scheme) rdm := &resourceDiscoveryManager{

Seeing data race flakes in unit tests: Appears to have just been in /sig api-machinery /priority critical-urgent /assign /cc
This code is mutating the package-level schemebuilder: I think it should be adding the conversions to the local scheme instead:
Fixed in (found several instances)
/triage accepted


Question: for _, container := range pod.Spec.Containers { expectedHash := dockertools.HashContainer(&container) <ins> dockerContainerName := dockertools.BuildDockerName(uid, podFullName, &container) </ins> if dockerContainer, found, hash := dockerContainers.FindPodContainer(podFullName, uid, container.Name); found { containerID := dockertools.DockerID(dockerContainer.ID) glog.V(3).Infof("pod %q container %q exists as %v", podFullName, container.Name, containerID)

-- is the old old format for names.
Just to be sure, is "pod [podFullName] container [container.Name]" the new preferred format? I also see some places comma separating that form.
The new form should either be a list of fields, a strict, or the result of BuildDockerName(...) On Jan 15, 2015 5:37 AM, "commonlisp" wrote:
Closed with


Question: v1 "k8s.io/api/core/v1" storagev1 "k8s.io/api/storage/v1" "k8s.io/kubernetes/test/e2e/framework" <ins> e2eframework "k8s.io/kubernetes/test/e2e/framework" </ins> e2epod "k8s.io/kubernetes/test/e2e/framework/pod" )

What happened: The CSI hostpath driver used in the e2e tests expects the root directory of nodes to be set to , , however nodes can be configured to use different paths. The tests should find out the root directory from kubelet to allow for this. Several test failures related to CSI Volumes: What you expected to happen: Test should be expected to pass. How to reproduce it (as minimally and precisely as possible): Configure kubelet on cluster nodes to use the non-default path. Run the storage-csi e2e tests. Anything else we need to know?: Environment: Kubernetes version (use ):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 testing
/sig storage /remove-sig testing This is a SIG storage specific issue.
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? I've asked about that before and the conclusion was that there is no portable way to do that (i.e. no official API). It seems to fall onto cluster admins to configure CSI driver deployments so that this particular aspect matches the cluster. For the tests that means that there has to be a parameter for the kubelet data directory that users of then have to set.
We could add and respect a flag of course then all nodes have to be the same at least. Reminder though
That's indeed another complication.
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale Tracked for csi-driver-host-path in There's a bigger issue about both mock and hostpath driver in which includes "support non-default kubelet path".
The current hostpath driver in k/k testing supports non-default paths, but the suite doesn't use that yet.

/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: assert.Equal(t, 1, len(fnh.UpdatedNodes), "Node was not updated") assert.Equal(t, "node0", fnh.UpdatedNodes[0].Name, "Node was not updated") <del> assert.Equal(t, 1, len(fnh.UpdatedNodes[0].Status.Addresses), "Node status unexpectedly updated") </del> <ins> assert.Equal(t, 3, len(fnh.UpdatedNodes[0].Status.Addresses), "Node status unexpectedly updated") </ins> cloudNodeController.Run()

<!-- 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 using the flag on the kubelet, the node's list no longer reports , , addresses. What you expected to happen: That I can explicitly set to an IP, but the other addresses will still show up. How to reproduce it (as minimally and precisely as possible): Create a new kops cluster, modify the kubelet to use the flag with the eth0 on the node. Run Anything else we need to know?: This change will probably take place in  This came up as a result of Environment: Kubernetes version (use ): 1.9.x Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): any Kernel (e.g. ): any Install tools: kops /sig network /sig node I'll make a PR for this change shortly


Question: // updateResourceQuotaUntilUsageAppears updates the resource quota object until the usage is populated // for the specific resource name. func updateResourceQuotaUntilUsageAppears(c clientset.Interface, ns, quotaName string, resourceName v1.ResourceName) error { <del> return wait.Poll(framework.Poll, 1*time.Minute, func() (bool, error) { </del> <ins> return wait.Poll(framework.Poll, resourceQuotaTimeout, func() (bool, error) { </ins> resourceQuota, err := c.CoreV1().ResourceQuotas(ns).Get(context.TODO(), quotaName, metav1.GetOptions{}) if err != nil { return false, err

Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage: Spyglass: /sig api-machinery
/sig scheduling /remove-sig api-machinery I get the log from the artifacts. ResourceQuota check for best-effort pod failed for a pod that is not scheduled due to below error that is expected as The scheduling error is expected. no error/warning messages in kube controller manager with resourcequotacontroller. The case was failed after 30 seconds. Try to fix it like for configmap check. It seems that resource quota status/used updating is not that quick.
/remove-sig scheduling /sig api-machinery
BTW, if we want to fix it in kube-controller-manager side. Increase the namespace syncs concurrent may help If there are some metrics, it can be proved to be right or wrong.
/cc /triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /cc /triage accept 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
/triage accepted
past weeks looks good to me, can we move it to observe?


Question: "Rerun it with at least two nodes to get complete coverage.") } <del> podNames := LaunchNetTestPodPerNode(f, nodes, svcname, "1.7") </del> <ins> podNames := LaunchNetTestPodPerNode(f, nodes, svcname, "1.8") </ins> // Clean up the pods defer func() {

<!-- Please only use this template for submitting enhancement requests --What would you like to be : The documentation suggests that "The default pull policy is IfNotPresent" This is not the case when imagePullPolicy is defined under the spec section in a Pod definition without a specific value. Example: This will result in a Pod having imagePullPolicy as Always. Why is this needed: This is needed for clarification of the default behaviour. It is necessary for the appropriate handling of helm charts, in cases that the imagePullPolicy is empty.
/sig docs
The imagePullPolicy default value is .
In this paragraph you can see that In your reference it points out the default action for the kubelet, not the behaviour when imagePullPolicy is declared. Please do have in mind that the imagePullPolicy option for Never is mentioned only in this paragraph in the document.
If an image tag of "latest" is used, the imagePullPolicy defaults to to "Always": If no tag and no digest are specified on the image, an image tag of "latest" is used: The behavior when no image digest or tag is specified should be documented in the API docs for the and fields:
I am interested on helping this issue, but I am new to kubernete repo, it could take me sometime
I found the following which is well documented in "Best Practices for Configuration" It would be expected to include more information on the options in the main link under
I'd like to work on this one.
Very welcome, but yesterday also mentioned that he is following up on this issue, you can communicate with him before starting

cc
This has failed The two failures are different, and both seemingly totally legitimate. The first one is simply a pod never entering running state within the 5 minute timeout. Expected error: <*errors.errorString | 0xc208475150: { s: "gave up waiting for pod 'nettest-dtwk3' to be 'running' after 5m0s", } gave up waiting for pod 'nettest-dtwk3' to be 'running' after 5m0s not to have occurred The second is not being reachable: Dec 7 01:22:47.275: Unable to connect/talk to the internet: Get dial tcp 74.125.202.147:80: i/o timeout The latter could be a result of a missing MASQ rule on the node, or GCP egress problems. I don't think that this is worth trying to debug further in the context of this test for intra-pod communication. I'll check more generally whether we have a current intermittent problems with respect to pods entering running state, or reaching the internet.
I think this test may be causing builds to time out, too. See comments from me in .
For the future, I actually don't think we need the test at all in the networking test. Maybe even move it do a different test altogether.
This is clearly a bug. I'll send a PR shortly: Regarding the ping to , why did you put in in the first place?
hmmm, not sure what you mean by "in the first place" ? I did not write the test...
sorry, I thought that you'd written that part of the test. I will find out who wrote that, figure out why they put it there in the first place, and then either remove it, or rewrite it to work correctly. Clearly that part of the test needs at least some basic retry to work consistently.
ok great, no problem just wasnt sure what you meant. SGTM. Id be okay w/ deleting the ping entirely regardless of who wrote it, its a very old snippet which doesnt really add much to the overall test suite (and in fact is questionable wether it should even be an assertion at all )
somebody put it there for some reason. Better to understand why before just deleting it.

i looked, its actually rob who i work with :) i will ask him in the morning unless you find him first :) (rrati)
Regarding my alleged "clear bug" above, I was completely wrong. There's nothing wring with that code. And unfortunately, when this test goes into a presumed endless loop (see comment above) it does not produce any output (as the output is cached by Ginkgo until the test completes). So it's very difficult to debug. But in summary I agree with this test is probably never completing, and causing tests to time out. Someone will need to isolate this test in a environment where it produces output and can be debugged. I'll keep trying, but need to head home soon, so if anyone wants to pick it up overnight, go ahead.
Smoking gun:
hmm - I'm just wondering why only this particular test is hanging forever (if we agree that's the case). I don' think that some requests are hanging forever in this test, but not in any other test...
Closing in favor of which should fix this. Or at least some way to set client timeout, which and are still figuring out.
It's happening again.
Talked to offline. I am assigning this one to you for triage. Let me know if you need any help.
AFAICT the last failure was just the pod nettest-7h5jj not coming up
Looks like this should be resolved by your pr: too. :-)
Maybe. Though the webserver only deadlocks in the failure case, so the test is probably still flaky...
Looks like this test is now explicitly flaking by failing, as I expected.
Based on the , it took 15 minutes to pull the image. closing this one as dup of
New Failure:
This looks like a race between populating the endpoints list and the /status, /read methods of the service exposed through the master proxy. It looks like the webserver pod is just trying to confirm that it can reach all peers. We can do this synchronously after having observed all expected endpoints in the test (or re-write the test to use the same pattern we do in services e2e).
The test looks really racy to me. I think the following 15 retries prevents it to fail more often, but not completely.

I will submit a pr to enfore webservers to wait till alll endpoints are up before they start to contact each other.
New failure
I am making this P0
It took more than 4 minutes for a nettest pod to come up. The nettest container is waiting for all endpoints to be ready for 2 minutes plus 15 attempts (5 sec interval) to contact its peers. This happens in less than 4 minutes. Hence the first 2 nettest pods finished contacting peers and declared failure.
The node you want is: I see: that's too much silence ...
From the It looks like kubelet is slow to start the container. Due to the lower logging level in the gke, it's hard to guess what could've slowed down the goroutine...


Question: if err != nil { glog.V(4).Infof("azureDisk - GetStorageAccount:%s err %s", storageAccountName, err.Error()) <del> return false, err </del> <ins> return false, nil // error performing the query - retryable </ins> } if provisionState == storage.Succeeded { return true, nil } <del> glog.V(4).Infof("azureDisk - GetStorageAccount:%s not ready yet", storageAccountName) // leave it for next loop/sync loop return false, fmt.Errorf("azureDisk - Account %s has not been flagged Succeeded by ARM", storageAccountName) </del> <ins> glog.V(4).Infof("azureDisk - GetStorageAccount:%s not ready yet (not flagged Succeeded by ARM)", storageAccountName) return false, nil // back off and see if the account becomes ready on next retry </ins> }) // we have failed to ensure that account is ready for us to create // the default vhd container if err != nil { <ins> if err == kwait.ErrWaitTimeout { return fmt.Errorf("azureDisk - timed out waiting for storage account %s to become ready", storageAccountName) } </ins> return err } }

I was looking for examples of our exponential backoff usage, and found some suspicious code. wait.ExponentialBackoff exits immediately if But in this loop, we always return , so we will never retry.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
That does look suspicious. What's the expected return of a retryable function (ConditionFunc)? for 'succeeded', for 'fatal error, do not retry' and for 'retryable error, let the retry policy decide whether to try again' (and it's up to the retryable function to log such errors as it encounters them rather than propagating the last error to its caller)? (Forgive me if this is a newbie question, I am... a newbie.)
Your description sounds right. The pattern seems to be to log the error in the case. Some other callers seem to stash the error for future use, but most simply return timeout on a timeout (not the "real" error, hence the need to log it). It's a pretty caller hostile API, IMO :-)


Question: dnsPolicy: Default containers: - name: fluentd-gcp <del> image: gcr.io/google-containers/fluentd-gcp:2.0.4 </del> <ins> image: gcr.io/google-containers/fluentd-gcp:2.0.5 </ins> # If fluentd consumes its own logs, the following situation may happen: # fluentd fails to send a chunk to the server => writes it to the log => # tries to send this message to the server => fails to send a chunk and so on.

Fuentd-gcp image in version , used in contained a bad version of the fluentd (0.14), which introduced regression, detected by the load tests /cc


Question: etcd.SetLogger(log.New(os.Stderr, "etcd ", log.LstdFlags)) controllerManager := registry.MakeReplicationManager(etcd.NewClient([]string{*etcd_servers}), <del> kube_client.Client{ </del> <ins> client.Client{ </ins> Host: "http://" + *master, })

It would be great to have an easy way to run a kubernetes master/minion locally. Currently, it's not that easy to set up. We should have a convenient script to make it work.
The integration test binary is pretty close. It'd be pretty simple to glue in the kubelet to that binary. Brendan On Jun 10, 2014 2:53 PM, "Daniel Smith" wrote:
I'll take a look.
+1 for this -- especially in script form rather than a go executable.
what exactly do you mean by "script form"? Were you thinking of something like a version of cloudcfg that can be run without needing to have started up a daemon first?
Basically, what I had in mind, is a shell script that looks something like
Ah, ok. That's very similar to local-; the only difference is that everything is packaged into a single go binary. We probably will switch to using individual binaries for this when we start running our components inside docker containers.
The script just makes things more obvious how to run things for those who are looking to integrate them into non-GCE environments.
That's a good point. I'll look into this some more later.
Create a pad as follows: Name: non-persistent-redis Container image: redis Named-volum with name: cache-control Mount path: /data/redis It should launch in the pre-prod namespace and the volume MUST NOT be persistent. apiVersion: v1 kind: Pod metadata: name: non-persistent-redis namespace: pre-prod spec: containers: name: non-persistent-redis image: redis volumeMounts: name: cache-control mountPath: "/data/redis" volumes: name: cache-control emptyDir: {}

I cannot find such a service when . Same thing applies for . My cluster runs fine. cc:
Ah, good catch... everything is run as a container now, will update the documentation on where to get the logs.

When I'm accessing persistentVolumes and persistentVolumeClaims, I'm getting nil instead of empty list of items, as happening in other entities when there are no items. { "kind": "PersistentVolumeList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/persistentvolumes", "resourceVersion": "" } }
Yes, this seems like a bug. I see an empty list when I access pods: And items is nil when I access persistent volumes:
Items shouldn't be tagged with omitempty:
cc
PersistentVolumeList and PersistentVolumeClaimList appear to be the only resource types with this problem.
Please see for fix.


Question: "github.com/onsi/ginkgo" ) <del> var _ = ginkgo.Describe("[sig-architecture] PodTemplates", func() { </del> <ins> var _ = ginkgo.Describe("[sig-node] PodTemplates", func() { </ins> f := framework.NewDefaultFramework("podtemplate") <del> ginkgo.It("should run the lifecycle of PodTemplates", func() { </del> <ins> /* Release : v1.19 Testname: PodTemplate lifecycle Description: Attempt to create a PodTemplate. Patch the created PodTemplate. Fetching the PodTemplate MUST reflect changes. By fetching all the PodTemplates via a Label selector it MUST find the PodTemplate by it's static label and updated value. The PodTemplate must be deleted. */ framework.ConformanceIt("should run the lifecycle of PodTemplates", func() { </ins> testNamespaceName := f.Namespace.Name podTemplateName := "nginx-pod-template-" + string(uuid.NewUUID())

This issue proposes the writing of a new test for the API endponts , , , and with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to these results from APIsnoop, we are lacking in test coverage and conformant tests for PodTemplate. We chose these three following endpoints for this mock test: - - Outline: PodTemplates, Expect no PodTemplates a PodTemplate (1), Expect no error PodTemplate (1), Ensure the same as how it was created PodTemplate (1) with label a=1, Expect no error PodTemplate (1), Expect label in returned data to be present PodTemplates by label a=1, Expect one PodTemplate PodTemplate (1) Expect no error PodTemplates, Expect no PodTemplates Fetch dependencies: This mock test is using client-go's standard functions to talk to the PodTemplate part of the API. If a test with these calls gets merged in, conformance will go up by 3 endpoints. /sig architecture /area conformance
We decided not to deprecate. We can link to that, but otherwise this is OK to write / promote.
ref: for the decision not to deprecate
/reopen
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


Question: } func NewCertificateController( <ins> name string, </ins> kubeClient clientset.Interface, csrInformer certificatesinformers.CertificateSigningRequestInformer, handler func(*certificates.CertificateSigningRequest) error,

There are multiple cert controllers that use the same base struct, so when they log, you cannot differentiate which is which.
/sig auth


Question: "time" "github.com/moby/sys/mountinfo" <ins> "golang.org/x/sys/unix" </ins> "k8s.io/klog/v2" utilexec "k8s.io/utils/exec"

<!-- 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 --We saw this several times: after restarting kubelet, kubelet didn't creating new Pods. The healthz endpoint showed that the was stuck: From the stack trace, the goroutine was stuck in the call of when doing , so no other updates can be processed: Listing the volumes of orphaned Pods on this Node, there was an unresponsive NFS volume, stat it will hang forever, so the above goroutine should be stuck in cleaning up this Pod: The NFS server IP is a service IP, whose backend Pod happened to be scheduled to this Node. However, as was stuck, it didn't handle Pod Add/Update from apiserver and didn't create the backend Pod, hence a dead lock. Searched PR and issue history, it seems there were several ones fixing NFS volume issues but looks like not covering this case: (however reverted) (still open) Is there anyone still working on it? The main syncloop of kubelet shouldn't hang due to an unresponsive NFS volume, leading to no Pods can be created. Kubernetes version (use ): v1.20.5
/sig storage /sig node similar with and And the problem code is in According to and 's comments in , it will be removed later, but I checked the new code in mount-utils. The func is not changed: Possible fix to this would be something like below:
/assign
Hey Quick question: the links that you attached that could be possible fixes, were really helpful! Since the approach to check for wouldn't help here, a timeout based approach seems best, I'm a little unsure about what this timeout period could be for this case, any suggestions on the same?
I have no idea. you may ask sig-node guys in the slack or weekly meetings. Or send a PR and discuss it in the PR. The only nfs related timeout that I can found is 1 minute in
hit again, it‘s easy to reproduce if there is nfs service in the cluster.
/assign /triage accepted
/area node-lifecycle
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /help
This request has been marked as needing help from a contributor. 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-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
/good-first-issue New contributor can follow some advice in .
Hey ! I'm wondering if this issue is still being worked on? I'd like to help if there's room to do so!
I'm not working on it. Thanks for the help.
awesome!
/assign
Hi are you still working on this?

I'm interested in this and please let me know if I can give it a try, Thanks! : )
I'm actually still on it but if you're open to it we can team up? I don't mind sharing
Thanks for reply, I am vary glad to hear that, I think you can continue your work and I would take a look at other issues, if there is anything I can help, please feel free to ping me : )
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Is someone still working on this or I am free to take a stab at this? I have ran into this a few times and trying to fix this cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .

/lifecycle rotten [1]:
/remove-lifecycle rotten /remove-label good-first-issue This isn't a great first issue to work on. It requires having a NFS server and instrumenting it to be down to test the fix.
The label(s) /remove-label good-first-issue api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor, official-cve-feedlabels -additionallabelslabels -? <detailsIn response to : /remove-lifecycle rotten /remove-label 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
/remove-good-first-issue
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the PR is closed You can: Mark this PR as fresh with Close this PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Does this problem still exist?
/triage needs-information
/remove-lifecycle stale
/triage accepted cancel
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accepted cancel 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
remove-triage accepted
/remove-triage accepted
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
statx with ATSTATXDONT_SYNC flag will not stuck in syncLoop. how about replace stat with statx?


Question: store *genericregistry.Store } <ins> var _ = rest.Patcher(&StatusREST{}) </ins> // New creates a new VolumeAttachment resource func (r *StatusREST) New() runtime.Object { return &storageapi.VolumeAttachment{}

This came up as a follow up to Also rather than opening 5 different issues - we are going to use this github issue to track all follow up items mentioned here -
/sig storage
/assign /assign
: PR
and the rest is fixed in


Question: }, } <ins> pvcConfig := e2epv.PersistentVolumeClaimConfig{ StorageClassName: &ns, } </ins> numPVs, numPVCs := 1, 1 pvols, claims, err = e2epv.CreatePVsPVCs(ctx, numPVs, numPVCs, c, f.Timeouts, ns, pvHostPathConfig, pvcConfig) framework.ExpectNoError(err, "Failed to create the requested storage resources")

master-informing: ! Last 2 runs failed consecutively, first failure: No response /sig storage
/cc
I will take a look this week.
/triage accepted
/assign


Question: } } <del> func newContainerStats(libcontainerStats *libcontainer.Stats) *info.ContainerStats { </del> <ins> func newContainerStats(libcontainerStats *libcontainer.Stats, withPerCPU bool) *info.ContainerStats { </ins> ret := &info.ContainerStats{ Timestamp: time.Now(), } if s := libcontainerStats.CgroupStats; s != nil { <del> setCpuStats(s, ret) </del> <ins> setCpuStats(s, ret, withPerCPU) </ins> setDiskIoStats(s, ret) setMemoryStats(s, ret) }

/kind feature This is the once-per-release cut of a new cAdvisor release, which corresponds to the next kubernetes release. cAdvisor v0.29 corresponds to kubernetes v1.10. /sig node /priority important-soon
self-reminder to add per-cpu stats to ignore metrics when vendoring. reminder to add a release notice that one of the container labels fields is being removed.
/kind bug turns out most of the changes are bug-fixes
please mark this issue as approved-for-milestone, since it certainly seems to be, and it's now code slush. Thanks!


Question: args: args{initialCapacity: 5, maxCapacity: 10, sizes: []int{8, 4}}, cap:  8, }, <ins> { name: "with existing capacity and length above max", args: args{initialCapacity: 12, initialLen: 5, maxCapacity: 10, sizes: []int{8, 4}}, cap:  12, len:  5, }, { name: "with existing capacity and length below max", args: args{initialCapacity: 5, initialLen: 3, maxCapacity: 10, sizes: []int{8, 4}}, cap:  8, len:  3, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { if tt.args.initialCapacity > 0 { <del> tt.args.v = reflect.ValueOf(make([]example.Pod, 0, tt.args.initialCapacity)) </del> <ins> val := make([]example.Pod, tt.args.initialLen, tt.args.initialCapacity) for i := 0; i < tt.args.initialLen; i++ { val[i].Name = fmt.Sprintf("test-%d", i) } tt.args.v = reflect.ValueOf(val) </ins> } <del> // reflection requires that the value be addressible in order to call set, </del> <ins> // reflection requires that the value be addressable in order to call set, </ins> // so we must ensure the value we created is available on the heap (not a problem // for normal usage) if !tt.args.v.CanAddr() {

has by default, and since 1.22 has the same. They seem to return wrong results in certain situations combined with / . And / also use , so they also don't work correctly. outputs partial list of pods on the node, doesn't evict some of the pods. To make it work correctly, I had to specify works correctly with any , since it's just a performance optimizing parameter. I can't provide an actual concrete example (no = default ), but instead I show how to reproduce it with a smaller I believe that the same problem occurs with create two deployments. there are 5 pods in each. with --selector=app=another-server and , it shows only 4 pods. I could confirm that the problem happens in both case of and regardless namespace, even with , or <details</details<detailsGCP / GKE Standard </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api-machinery
/sig node
I think this is indeed a bug, after some simple testing, it seems to be an bug unique to 1.24, let me fix it. /assign
/assign
I can reproduce this error in a 1.24 cluster, but not in a 1.23.6 cluster. All clusters are created via kind, and I'm guessing gke may have cherry-picked some commits or had some of their own changes to their branch. So I think this fix should at least cherry-pick to 1.23 to help other distributions fix this issue.
/remove-sig api-machinery


Question: subsets := []api.EndpointSubset{} podHostNames := map[string]endpoints.HostRecord{} <ins> var tolerateUnreadyEndpoints bool if v, ok := service.Annotations[TolerateUnreadyEndpointsAnnotation]; ok { b, err := strconv.ParseBool(v) if err == nil { tolerateUnreadyEndpoints = b } else { glog.Errorf("Failed to parse annotation %v: %v", TolerateUnreadyEndpointsAnnotation, err) } } </ins> for i := range pods.Items { pod := &pods.Items[i]

This is mostly motivated by petset. Currently we create a governing service that is responsible for the network identity of each pet. The requirements of this governing service differ from a normal service in the following ways: have internal protocols to notice peer health, and a list of different checks (eg: ). In kube, peers use DNS to communicate. So we don't want a readiness check failure to remove the pet from DNS and abruptly cut it off from the set. "governing service" is headless so kube-proxy doesn't need to NAT the service ip. will not be using this Service, so it doesn't matter that unready pets show up in DNS under the svcName sub domain. In addition to these, there's one important reason some pets need to have DNS before readiness. To provide the guarantees required to safely bootstrap a pet, we need: 0 starts before pet1.. 't start pet1 till pet0 is running/ready pet1 starts, it sees pet0 in DNS The easiest way to guarantee 3 today is to do one of: poll in the entrypoint of pet0, till it sees itself poll in the init container of pet0, till it sees itself poll in the init containers of pet {1..N-1} till it sees all previous pets Third option is not a great idea because we don't know who else is supposed to exist, and for the first 2 to work with a readiness probe, we need a DNS record before the Service is ready.
I have a wip that does this through an annotation:
+1. this is useful even in traditional n rc's and n+1 services setup for clustered systems like n nodes zookeeper/etcd. Currently, there isn't a easy way to specify a readiness check in such setups, because the check in these cases would look for whether the pod member has joined the cluster successfully as follower, which wouldn't work as they discover each other through them appearing in service endpoints. this prevents one from being able to do a rolling upgrade of cluster members safely, because there is no readiness feedback after a member pod is upgraded.
Suggestion to hold this for alpha in 1.5, and in 1.6 spend a bit of time talking about how services are best intermixed with stateful sets (there's a lot of correlation between them).

That avoids us breaking people in 1.5 and gets a bit more think time.
SGTM
See also
Can we claim that if a pod is requesting pet DNS (i.e DNS name via the hostname/subdomain annotation) it never wants kube-style readiness, because it has its own internal protocol for peer health? If that's true we can get rid of the annotation and teach kubedns to always serve records for pet DNS ignoring readiness. My intuition tells me the answer to that question is no (i.e there exist pets that use DNS for discovery, and don't have an internal protocol for readiness, so they must use kube readiness to remove themselves from the peer group), and so the ability to toggle it on/off is useful, but I also want others to consider it.
I'd love to nix an annotation but I have not the expertise to answer this one.
I don't have a strong feel either way - I'd say readiness controls on a service feel orthogonal to independent names though. Since we don't have per port readiness, we need to consider that at some point we might need more sophistication on services or pods to control membership (unless we make label flipping easier). I would like to see us tease apart the "leader / follower" service member concept a bit more because that might inform how we handle readiness (seems like a separate bit, but we may want atomic changes).
They are somewhat orthogonal, but you presumably only want to discover healthy peers, unless you have a way to probe every peer you discover for health. Applying this policy based on endpoint info also feels a little weird, because it's harder to create overlapping Servics with different behavior. I think doing the common thing always and by default is fine, as long as we can annotate our way back to what we have today, but what form would the opposite of today's Service level annotation take? i.e something that says "even though my endpoints need pet names, apply the regular rediness behavior to their DNS records"
How bad would it be to start without an annotation, assume that pet-names == tolerate-unready, and see if anyone screams? Who should we consult?
SGTM, that's also what I was prposing in the previous comment
I guess the question is why do we even want to do that? Why make a change that couples logic vs leaving as is with decoupled logic?

We have people who want unready endpoints for deployments to form gossip pools - so I guess that counts as a use case where pet names is not coupled to unready. Is leaving the annotation on for another release really a problem? , Prashanth B <:
That's exactly the kind of use case I was looking for, something that doesn't require pet names. I get the feeling there will be other apps but I couldn't produce an example.
JBoss EAP uses it to form initial quorum for jgroups, which isn't a strong consensus system. So they use deployments and a minimum set to form an initial quorum and deal with split brain like jgroups normally does (infinispan has multiple consistent modes, some of which might prefer loose pools). Arguably smaller sets and some infinispan quorums might prefer statefulsets, but those use cases are also more tolerant of partitions in general. , Prashanth B <:
we are using tolerate-unready-endpoints annotation in our zookeeper deployments (not using pet/stateful set). Without unready endpoints, it is impossible to define a meaningful pod readiness check for zk, and without a readiness check, it is hard to do rolling updates (one ensemble member at a time).
The question is whether there's a need to have StatefulSets without tolerate-unready-endpoints. It sounds like maybe yes, which makes me grumpy, but I'll acquiesce if Clayton and Prashanth say so. , ravilr <:
isn't it enough to establish a need to tolerate-unready without statefulsets?
I have two services pointing to my etcd stateful set - one that is endpoints (peers) and tolerates unready. I have one that is for naive clients that uses readiness. On Dec 1, 2016, at 2:59 AM, Prashanth B <: isn't it enough to establish a need to tolerate-unready without statefulsets? — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread
fine.
/sig network
Right. This is exactly why etcd operator uses the alpha feature. Can we make it beta in 1.8 release?
/cc
We had discussed promoting since we need it for StatefulSet and no one has come up with anything better.

We should make a decision and include it in our GA roadmap for workload controllers.
Be sure to include sig-network On Jul 6, 2017, at 2:40 PM, Anthony Yeh <: had discussed promoting tolerate-unready-endpoints since we need it for StatefulSet and no one has come up with anything better. We should make a decision and include it in our GA roadmap for workload controllers. — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread
This is also useful for ingresses that need to retain the source IP using OnlyLocal node ports, which is important for firewalling with things like Calico. The problem that we see now is when a deployment occurs, the pod is removed from the node port before the PreStop completes, which doesn't give the upstream AWS load balancer time for the pod to fail out using normal health checks.
/close
Headless Services are a thing now


Question: # Channels Setup,Windows PowerShell Channels     application,system,security Tag          winevent.raw <del> DB           winlog.sqlite   # </del> <ins> DB           winlog.sqlite   # </ins> # Json Log Example:

<!-- 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: There's a race condition between starting Windows service and when the VMs network is actually available to communicate with the VM's metadata server. If the service starts first and cannot communicate with the metadata server or start talking to the stackdriver logging service it'll crash and not resume because the service is not configured to restart on failure. Typically a is used for a service like this but Windows does not support privileged containers so a standard Windows Service is used. What you expected to happen: If the service fails to start it should be automatically be restarted. How to reproduce it (as minimally and precisely as possible): This is a flaky issue but a way to repro this is to effectively by RDP'ing into the node and running: Anything else we need to know?: Environment: Kubernetes version (use ): v1.16 and onward Cloud provider or hardware configuration: GCE OS (e.g: ): Windows Kernel (e.g. ): Windows (any version) Install tools: cluster/gce/windows/README-GCE-Windows-kube- Network plugin and version (if this is a network-related bug): Others:
/sig windows
/assign jeremyedwards
GitHub didn't allow me to assign the following users: jeremyedwards. 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 jeremyedwards 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


Question: import ( "testing" "time" <ins> "k8s.io/apimachinery/pkg/util/clock" </ins> ) func TestTimeBudget(t *testing.T) { <ins> fakeClock := clock.NewFakeClock(time.Now()) </ins> budget := &timeBudgetImpl{ <ins> clock:     fakeClock, </ins> budget:    time.Duration(0), <del> maxBudget: time.Duration(200), </del> <ins> maxBudget: 200 * time.Millisecond, refresh:   50 * time.Millisecond, last:      fakeClock.Now(), </ins> } if res := budget.takeAvailable(); res != time.Duration(0) { t.Errorf("Expected: %v, got: %v", time.Duration(0), res) } <del> budget.budget = time.Duration(100) if res := budget.takeAvailable(); res != time.Duration(100) { t.Errorf("Expected: %v, got: %v", time.Duration(100), res) </del> <ins> // wait for longer than the maxBudget nextTime := time.Now().Add(10 * time.Second) fakeClock.SetTime(nextTime) if res := budget.takeAvailable(); res != budget.maxBudget { t.Errorf("Expected: %v, got: %v", budget.maxBudget, res) } // add two refresh intervals to accumulate 2*refresh durations nextTime = nextTime.Add(2 * time.Second) fakeClock.SetTime(nextTime) if res := budget.takeAvailable(); res != 2*budget.refresh { t.Errorf("Expected: %v, got: %v", 2*budget.refresh, res) } // return one refresh duration to have only one refresh duration available // we didn't advanced on time yet budget.returnUnused(budget.refresh) if res := budget.takeAvailable(); res != budget.refresh { t.Errorf("Expected: %v, got: %v", budget.refresh, res) </ins> } <ins> // return a negative value to the budget // we didn't advanced on time yet budget.returnUnused(-time.Duration(50)) </ins> if res := budget.takeAvailable(); res != time.Duration(0) { t.Errorf("Expected: %v, got: %v", time.Duration(0), res) } <del> budget.returnUnused(time.Duration(50)) if res := budget.takeAvailable(); res != time.Duration(50) { t.Errorf("Expected: %v, got: %v", time.Duration(50), res) </del> <ins> // handle back in time problem with an empty budget nextTime = nextTime.Add(-2 * time.Minute) fakeClock.SetTime(nextTime) if res := budget.takeAvailable(); res != time.Duration(0) { t.Errorf("Expected: %v, got: %v", time.Duration(0), res) </ins> } <del> budget.budget = time.Duration(100) budget.returnUnused(-time.Duration(50)) if res := budget.takeAvailable(); res != time.Duration(100) { t.Errorf("Expected: %v, got: %v", time.Duration(100), res) </del> <ins> // wait for longer than the maxBudget // verify that adding a negative value didn't affected nextTime = nextTime.Add(10 * time.Minute) fakeClock.SetTime(nextTime) if res := budget.takeAvailable(); res != budget.maxBudget { t.Errorf("Expected: %v, got: %v", budget.maxBudget, res) </ins> } <del> // test overflow. budget.returnUnused(time.Duration(500)) if res := budget.takeAvailable(); res != time.Duration(200) { t.Errorf("Expected: %v, got: %v", time.Duration(200), res) </del> <ins> // handle back in time problem with time on the budget budget.returnUnused(10 * time.Second) nextTime = nextTime.Add(-2 * time.Minute) fakeClock.SetTime(nextTime) if res := budget.takeAvailable(); res != budget.maxBudget { t.Errorf("Expected: %v, got: %v", budget.maxBudget, res) </ins> } }

Instead of relying on the clock: we should do something similar to the golang rate-limitter is doing:
/sig api-machinery /priority important-longterm
/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 : /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
Hi, I would like to help on this.
/assign Thanks! /triage accepted
can you please provide more context or some guidance on how to proceed?
Sorry for delayed response. - what we should do is to basically: instead of having an additional go-routine that every 1s refreshes the budget change it roughly to: (a) keep the value of budget and the last time when we were refreshing it (b) on takeAvailable method: first recompute takeAvailable, which will be "min(current budget + time elapsed since last refresh * refreshValue, maxAllowedBudget) update last refresh time to now return that value [We also would need to update the existing tests to match the new logic.] - would you be willing to work on it?
-- I can take this up. One question I had was should the method rely on or the current time should be passed on by the caller like in the following: Having the caller pass the time completely removes the dependency on the clock at least for the implementation.
/assign
Let's may be start with: passing on budget creation to it relying on
-- thank you for the thoughts. I drafted a rough implementation in which still depends on . I will make the change as you suggested and rely solely on a instance passed on initialization. I have to rethink the testing strategy a bit, possibly using a .
Yes - FakeClock is the way to test this.
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-contributor-experience at . /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-contributor-experience at . /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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /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
Reopening - this didn't happen.


Question: NODE_OS_DISTRIBUTION=${KUBE_NODE_OS_DISTRIBUTION:-gci} MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-cos-stable-65-10323-64-0} MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-cos-cloud} <ins> CLEANUP_KUBEMARK_IMAGE=${CLEANUP_KUBEMARK_IMAGE:-true} </ins> # GPUs supported in GCE do not have compatible drivers in Debian 7. if [[ "${NODE_OS_DISTRIBUTION}" == "debian" ]]; then

After looking at 's , I realized that there are some problems with how we're using kubemark images for our CI-testing: run of every kubemark job creates and pushes a kubemark image to the image registry of the project in which the cluster would be created. But the kubemark cluster setup uses the image. This means that a race b/w 2 kubemark jobs while pushing the image is possible, and it may happen that one job is using the image from another one. This can be solved by using a random image tag to uniquify the runs. run of every kubemark job pushes a new image to a docker registry. So we have a huge list of leaked kubemark images in the projects where we're running kubemark jobs - e.g O(10^5) images in used for kubemark pre-submit. Each image is about 72 MB and at the cost of for our GCS buckets, it's ~/month just on stale kubemark images. Few things we should do IMO: delete the kubemark image at the end of the run delete the pre-existing stale kubemark images in general, make janitor garbage collect images also (cc ) changed the kubemark image registry to , instead of the earlier . However, the manifest for the kubemark deployment - so all jobs will continue using old kubemark image (albeit the one). This needs to be fixed asap. cc /assign
PR solves the 1st and 3rd issues above. Wrt 2, the following seem to be the current set of projects running our kubemark jobs (there may be more abandoned ones from the past): We need to clean up all those images. Any ideas on what's the easiest way of doing it? I'm thinking of directly deleting the GCS directories holding those images (if that's possible). cc And for future, I'll send out a PR soon to do automatic GC as part of the run.
I still suggest we push the image as part of the build process :-) for gc, isn't it we won't need anything except for the one? Select all and delete?
I'm not sure I understand. Push where? Do you mean pack it in the release tar (like kube-proxy, etc)?

Yeah, for now we can delete all the images (even the latest one, it'll probably just cause a few one-off failures of the current runs). In general we don't want to gc everything except the latest one as we're going to have multiple unique images in use at a given instant (see my point 1).
I thought we do image pushes already, like in our build jobs, maybe we can fit kubemark build there? cc
I'm not sure - is it? The last I remember, I think we used to pack those docker images (and their tags) into the release tar which was downloaded onto every VM and docker used to locally load those dev image builds (instead of pushing them to somewhere in a registry).
we could run a script with in a cronjob if we had a reliable way to identify which images we want to get rid of.
We still pack the docker images + tags into the release tarballs, since GCE/GKE/kops all still do sideloading, but we also push the images from the to for the kubeadm CI jobs. See for more discussion on this.
maybe combine with an appropriate ?
probably? one issue is that images can be pushed with many tags
you can use to get the list of images, and then will list all tags matching your filter query for a given image.
yeah, we'll need something like: list images we want to keep and their tags list all images and their tags delete set(all tags) - set(tags to keep)
Image retention policy is a feature we (GCR) are investigating. what other tags are you using to push? I see in combination with a , which is going to complicate matters by stripping the build timestamp from the image (thereby enabling reproducible builds). Would the unix timestamp be an acceptable alternative to a completely random tag? If you're continually uploading new images under the exact same tag(s), most of the images will be untagged, and you can list the digests of such images like so: and delete like so:
I'm not sure what uploads are done for this job yet, or what tags would be acceptable but in other places, but in other places we have code that builds images which are doubly tagged ( and ), I think this pattern is fairly common. We have some similar logic for getting rid of stale images on disk (for local caching).

I definitely think we could hack something together, I just want to make sure we'll be able to avoid deleting things we should actually keep... It sounds like for this one we can probably just delete images that aren't latest, but there are lots of other images we should probably do this for.
Ah. 's a bit... interesting, but it shouldn't be too difficult to do the set difference above:
re: bazel-built docker images, I'm hoping we can fix at some point (so we can stamp them with real timestamps).
FYI has been merged, stamping should give you useful timestamp metadata to help reap old images (when a new release is made and adopted).
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 On Tue, Jul 10, 2018, 9:08 PM fejta-bot <:
I've sent out as a simple strategy to delete image right after startup.


Question: // this func must run in admin mode, otherwise it will fail func TestGetMountRefs(t *testing.T) { <del> fm := &FakeMounter{MountPoints: []MountPoint{}} mountPath := `c:secondmountpath` expectedRefs := []string{`c:`, `c:firstmountpath`, mountPath} // remove symbolic links first for i := 1; i < len(expectedRefs); i++ { removeLink(expectedRefs[i]) } // create symbolic links for i := 1; i < len(expectedRefs); i++ { if err := makeLink(expectedRefs[i], expectedRefs[i-1]); err != nil { t.Errorf("makeLink failed: %v", err) } </del> <ins> tests := []struct { mountPath    string expectedRefs []string }{ { mountPath:    `c:windows`, expectedRefs: []string{`c:windows`}, }, { mountPath:    `c:doesnotexist`, expectedRefs: []string{}, }, </ins> } <del> if refs, err := fm.GetMountRefs(mountPath); err != nil || !setEquivalent(expectedRefs, refs) { t.Errorf("getMountRefs(%q) = %v, error: %v; expected %v", mountPath, refs, err, expectedRefs) } </del> <ins> mounter := Mounter{"fake/path"} </ins> <del> // remove symbolic links for i := 1; i < len(expectedRefs); i++ { if err := removeLink(expectedRefs[i]); err != nil { t.Errorf("removeLink failed: %v", err) </del> <ins> for _, test := range tests { if refs, err := mounter.GetMountRefs(test.mountPath); err != nil || !setEquivalent(test.expectedRefs, refs) { t.Errorf("getMountRefs(%q) = %v, error: %v; expected %v", test.mountPath, refs, err, test.expectedRefs) </ins> } } }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig windows What happened: After creating pods having PersistentVolumeClaims and deleting them, the logs are getting filled with errors regarding failing to unmount the volume [1]. Additionally, tests requiring PVCs will hang several minutes while waiting the PV to unmount [2]. [1] [2] What you expected to happen: There shouldn't be any issues while unmounting the volume, the tests shouldn't have to wait several minutes waiting for the volume to be unmounted. How to reproduce it (as minimally and precisely as possible): pod requiring PVC. the pod. logs for error messages regarding the volume not being able to be unmounted. Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.2 Cloud provider or hardware configuration: Azure, acs-engine v0.21.2 (: ) OS (e.g. from /etc/os-release): Windows Server 1803 Kernel (e.g. ): Install tools: Others:
/sig azure /assign
what's your PVC type? is it azure disk?
thanks for reporting. I have identified that this is a regression introduced by UnmountDevice common code mainly for linux: the root cause is is not well implemented Error code is like following: I have a different implementation for func on windows wich could fix this issue, will file a PR tomorrow.


Question: if (( "${found}" == "${EXPECTED_NUM_NODES}" )) && (( "${ready}" == "${EXPECTED_NUM_NODES}")); then break elif (( "${found}" > "${EXPECTED_NUM_NODES}" )); then <del> echo -e "${color_red}Found ${found} nodes, but expected ${EXPECTED_NUM_NODES}. Your cluster may not behave correctly.${color_norm}" </del> <ins> if [[ "${KUBE_USE_EXISTING_MASTER:-}" != "true" ]]; then echo -e "${color_red}Found ${found} nodes, but expected ${EXPECTED_NUM_NODES}. Your cluster may not behave correctly.${color_norm}" fi </ins> break elif (( "${ready}" > "${EXPECTED_NUM_NODES}")); then echo -e "${color_red}Found ${ready} ready nodes, but expected ${EXPECTED_NUM_NODES}. Your cluster may not behave correctly.${color_norm}"

I have an existing v1.2 cluster on AWS and wanted to utilize the multi-AZ functionality. After following , the new node seems to be correctly, but I received the error below after completed. It seems like the script is not aware of the total cluster size and throwing an error, even though the instance is registering correctly.
Happening to us also :+1: nothing seems broken however, looks like the up script is getting confused.


Question: "k8s.io/kubernetes/pkg/watch" ) <del> // Give each test that starts a background controller up to 1/2 a second. // Since we need to start up a goroutine to test watch, this routine needs // to get cpu before the test can complete. If the test is starved of cpu, // the watch test will take up to 1/2 a second before timing out. const controllerTimeout = 500 * time.Millisecond </del> var alwaysReady = func() bool { return true } func newJob(parallelism, completions int) *experimental.Job {

Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.


Question: if instances == nil || !ok { return "" } <del> ix := strings.Index(host, ".") if ix != -1 { host = host[:ix] } </del> addr, err := instances.IPAddress(host) if err != nil { glog.Errorf("Error getting instance IP: %#v", err)

In the guestbook example, the redis slaves are instructed to connect to the redis-master using the proxy provided by the minion on which they reside. The minion is designated by its hostname "kubernetes-minion-N". The container cannot resolve this name to an IP address and so slave connections fail. 1) create vagrant cluster 2) create redis-master pod 3) create redis-master service 4) create redis-slave replicationController Verify redis-slave pod locations: list pods ID Image(s) Host Labels Status redis-master-2 dockerfile/redis kubernetes-minion-1/10.245.2.2 name=redis-master Running -3839-11e4-a922- brendanburns/redis-slave kubernetes-minion-1/10.245.2.2 name=redisslave,replicationController=redisSlaveController Running -3839-11e4-a922- brendanburns/redis-slave kubernetes-minion-3/10.245.2.4 name=redisslave,replicationController=redisSlaveController Running Log onto a minion containing a slave (note: vagrant hostnames are minion-N, not kubernetes-minion-N) Find the slave container docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES brendanburns/redis-slave:latest /bin/sh -c About an hour ago Up About an hour k8s--slave.---3839-11e4-a922- docker logs | tail [7] 09 Sep 17:27:08.428  Connecting to MASTER kubernetes-minion-1: [7] 09 Sep 17:27:08.430 # Unable to connect to MASTER: No such file or directory [7] 09 Sep 17:27:09.435  Connecting to MASTER kubernetes-minion-1: sudo nsenter -m -u -n -i -p -t $(docker inspect --format '{{ .State.Pid }}' ) /bin/bash [ root ]$ ping kubernetes-minion-1 ping: unknown host kubernetes-minion-1 [ root ]$ cat /etc/hosts 244.1.4 -3839-11e4-a922- 127.0.0.

1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters [ root ]$ cat nameserver 10.0.2.3 cat /proc/1/environ HOME=/rootPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binHOSTNAME=-3839-11e4-a922-0800279696e1REDISMASTERSERVICEPORT=10000REDISMASTERPORT=tcp://kubernetes-minion-1:10000REDISMASTERPORT6379TCP=tcp://kubernetes-minion-1:10000REDISMASTERPORT6379TCPPROTO=tcpREDISMASTERPORT6379TCPPORT=10000REDISMASTERPORT6379TCPADDR=kubernetes-minion-1SERVICE_HOST=kubernetes-
Tim - are you the right guy to handle this? I think we need to resolve the name of the service host and only give IPs to the minion in env variables. We can't assume the containers have the same DNS set up as the host system.
To be clear -- this example is for the checked in Vagrant stuff? If that is the case would be the guy? I'm trying to catch up on IRC discussions from earlier today.
I can look at this, but there are two possible solutions. The first solution is in the vagrant cluster (or any other local vm setup) we could run a dns name server on the kubernetes-master that can resolve each minion by host name. We would then pass a -dns option to the docker daemon to specify that name server to use in each container. The second solution is that we pass IP address instead of host name and make no assumption or override on the containers specified name server. Is there any obvious negative to this solution? Has much thought been done on the expected Nameserver used by containers spawned by our service? - if you can weigh in, I would be happy to resolve using either approach. My preference is solution two.
So, the vagrant case is a little special as there is no sane DNS set up by default. Another suggestion (3) would be to revert the stuff and just devolve to using ip addresses directly. I would do (3) before (2) before (1).

But I'm cool with any of them. As for the nameserver of the containers that are spawned -- docker currently just takes the of the host and copies that into the container. It doesn't do that for . that is the core of the issue here. If/when we do offer some level of split horizon DNS (I'd love to) we can start exposing an extra layer of DNS on top of whatever is configured for the host. That is part of the "ip per service portal" stuff that is being talked about a lot right now.
If I do (3) there is a piece of code in pod storage that mangles my hostname where I return 10.245.x.x and it asks the cloud provider to resolve the IP address for "10". Since other providers appear to also be returning IP as host, I will look to change this so kubernetes makes no modifications to hostnames that it's given. Look for PR tomorrow.
you're right I'd missed that point. This really only applies to the Vagrant cluster and so a fix to the vagrant setup is sufficient. I also agree with your priorities. Injecting a line into /etc/hosts (if that's reasonable) is the simplest solution. Either reverting or allowing a switch to pass the minion public IP rather than hostname is next. Adding a DNS service to the vagrant master and forcing DNS resolution to the master host is most complicated and least preferable. Thanks both of you for helping me think this through better. Mark
I don't grok what the difference between 2 and 3 is? I sent a PR to docker a while back () to insert arbitrary lines to /etc/hosts. I still think it is a reasonable thing to want to do.
- difference between (2) and (3) is that in the past, the vagrant cloud provider was returning the IP address as the literal hostname for the minion. I had changed this after noticing that it had some ugly side-effects in the CLI, where a call to list pods would report pod ip addresses as IP / nil.

The issue (which I now believe is a bug that I want to change independent of what we do here) is that the code at this line mangles the hostname returned by the cloudprovider: This makes using the IP address as a hostname (10.245.2.2) to have the ugly side-effect of the code then asking the cloudprovider for the IP address of hostname "10", and then the cloudprovider having no idea how to proceed. Independent of what is done in this issue, I want to submit a PR tomorrow to stop that code from manipulating the reported hostname that was provided by the cloudprovider before asking that same cloudprovider to return the IP address using a potentially different input value. so with that backlog (3) means revert vagrant cloudprovider to use IPAddress as hostname, which means when we pass in what we believe is hostname in this environment, it will just work because it is in-fact the IPAddress. (2) means do not pass in hostname but pass in IPAddress by changing more core k8s code. all that being said, there is an option (4) that I am intrigued by, - after following your PR through its final conclusion, it looks like as of docker 1.2.0 you can change the /etc/hosts file of a running container. this introduces an option where the kubelet injects the /etc/hosts file of minion into the running container so it has the /etc/hosts values of the minion. I would need to play with that support a little more to know pros/cons more. I think longer term, we need a plan on what nameserver our containers are expecting to reference, and if they are inherently different in some way. I have run into a number of times the issue where doing things like running docker in docker causes the nested container to default to the nameserver 8.8.8.8, which happens to be blocked on the Red Hat network ;-) For now to unblock I will probably pursue (3) and fix the hostname bug referenced here at the same time. It does make the CLI uglier when working with this environment, but not a huge deal, at least it will function.
Thanks both for the complete explanation of what's happening and for the suggested fixes.

I think in the long run using hostnames in SERVICEHOST and ensuriing either through IP injection into container /etc/hosts or by providing DNS are the best options. I'm not sure if there might still be cases where resolution of SERVICEHOST would still be best done by presenting the IP address or not.


Question: verifyCascadingDeletionForService(f.FederationClientset, clusters, nil, nsName) By(fmt.Sprintf("Verified that services were not deleted from underlying clusters")) }) <ins> It("should recreate service shard in underlying clusters when service shard is deleted", func() { fedframework.SkipUnlessFederated(f.ClientSet) service = createServiceOrFail(f.FederationClientset, nsName, FederatedServiceName) defer func() { // Cleanup By(fmt.Sprintf("Deleting service %q in namespace %q", service.Name, nsName)) err := f.FederationClientset.Services(nsName).Delete(service.Name, &metav1.DeleteOptions{}) framework.ExpectNoError(err, "Error deleting service %q in namespace %q", service.Name, nsName) }() By(fmt.Sprintf("Wait for service shards to be created in all clusters for service "%s/%s"", nsName, service.Name)) waitForServiceShardsOrFail(nsName, service, clusters) framework.Logf("Successfully created and synced service "%s/%s" to all clusters", nsName, service.Name) By(fmt.Sprintf("Deleting a service shard in one underlying cluster")) primaryClusterName := clusters[0].Name err := deleteServiceShard(clusters[0], nsName, FederatedServiceName) framework.ExpectNoError(err, fmt.Sprintf("while deleting service shard %q in cluster %q", FederatedServiceName, primaryClusterName)) waitForServiceShardsOrFail(nsName, service, clusters) framework.Logf("Successfully recreated service shard "%s/%s" in %q cluster", nsName, service.Name, primaryClusterName) }) </ins> }) var _ = Describe("DNS", func() {

As mentioned in when the service is deleted from the underlying cluster, the controller should recreate it, but it does not. Below's a transcript. is talking to the federation-apiserver, and is talking to the normal cluster it's pointed at.
Thanks for catching this cc
cc
This is definitely a bug, but I think that we can kick it out into v1.4. Until fixed (i.e. while in beta), we can tell customers not to delete the underlying services in their clusters.
it should not be, I have tested this before. How long did you wait when you check the service existence in last step? Can you send me the logs? The service deletion will cause federation service update, and then the federation service watcher will catch the update even and call another round of service updates to all clusters. When you delete the service, if the service got ingress ip already? I am thinking if the deletion did not trigger federation service update? So so no update event generated..
I think that the best way forward will be to encode this in a reproducible e2e test, otherwise there are too many variables to debug effectively. It's great to know that you've tested this case, and it works in at least some scenarios.
one possible solution come into my mind, currently we set the service full sync time to 10 minutes , if we change it back to 30s, then at least during the full sync, the deleted service will be re-created. I will send a PR anyway, you can judge if it should be put to v1.3
I think we need to find and fix the underlying problem, not cover it up with a shorter sync period. If we have the correct watch on each service, we will be notified as soon as they are deleted. Why is the watch notification not firing correctly?
Keeping this open until we've verified this fix in e2e tests.
I believe this to be fixed, but we still lack an e2e test to verify conclusively. would you like to take this on along with the other e2e tests that you are busy adding?
ping
plan on doing this for 1.4? or bump to 1.5?
Yes, 1.5 is fine.
switching this to 1.6 as it's too late for 1.5. ok?

Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.


Question: b.WriteString(fmt.Sprintf("etcd output:n%sn", e2es.etcdCombinedOut.String())) } b.WriteString("******************************************************n") <del> glog.V(2).Infof(b.String()) </del> <ins> glog.V(0).Infof(b.String()) </ins> }

Looks like it maybe the ssh connect is getting killed
The relevant log snippet:
And another one, not just coreos.


Question: if !masterNodes.Has(pod.Spec.NodeName) { if pod.Spec.NodeName != "" { _, scheduledCondition := api.GetPodCondition(&pod.Status, api.PodScheduled) <del> Expect(scheduledCondition != nil).To(Equal(true)) Expect(scheduledCondition.Status).To(Equal(api.ConditionTrue)) </del> <ins> // We can't assume that the scheduledCondition is always set if Pod is assigned to Node, // as e.g. DaemonController doesn't set it when assigning Pod to a Node. Currently // Kubelet sets this condition when it gets a Pod without it, but if we were expecting // that it would always be not nil, this would cause a rare race condition. if scheduledCondition != nil { Expect(scheduledCondition.Status).To(Equal(api.ConditionTrue)) } </ins> scheduledPods = append(scheduledPods, pod) } else { _, scheduledCondition := api.GetPodCondition(&pod.Status, api.PodScheduled) <del> Expect(scheduledCondition != nil).To(Equal(true)) Expect(scheduledCondition.Status).To(Equal(api.ConditionFalse)) </del> <ins> if scheduledCondition != nil { Expect(scheduledCondition.Status).To(Equal(api.ConditionFalse)) } </ins> if scheduledCondition.Reason == "Unschedulable" { notScheduledPods = append(notScheduledPods, pod) }

https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
The last failure is legitimate. The file changed since the run, so for easier lookup - the expect that failed is caused by the Expect in Current assumption is that something overwrites PodStatus after Scheduler sets up ScheduledCondition (i.e. we have a conflict during first update, and then retry it without applying changes that were made to the PodStatus at that time). This is very rare flake, but it should be pretty simple to debug.
- cool; what about the previous two failure? Did you have time to look into them?
I didn't have time today. I'll look into them tomorrow.
This is caused by the way is assigned for Pods created by a DeamonController. In case of "normal" Pods assigning Node to a Pod is done in the same time as setting , for daemons DaemonController just assigns a Node, and it's a Kubelet that adds a to it. This leaves some time between Pod creation (with already assigned Node) done by the DaemonController and the time when is written - when we get unlucky this makes the test fail.


Question: GetDeviceNameFromMount(mountPath, pluginDir string) (string, error) } <ins> // Compile-time check to ensure all Mounter implementations satisfy // the mount interface var _ Interface = &Mounter{} </ins> // This represents a single line in /proc/mounts or /etc/fstab. type MountPoint struct { Device string

Compilation error in GetDeviceNameFromMount declared twice. and are duplicates and one of them need to be reverted. (build is disabled for linux, that's why both of them got in)
see , please
Looks like this can be closed now. right ?
Yes, closed by


Question: return append(allErrs, field.Invalid(fldPath, value, isInvalidQuotaResource)) } } <del> return field.ErrorList{} </del> <ins> return allErrs </ins> } // Validate limit range types

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In some validation functions, such as , , value returned may be wrong. When return some errors and , we may just return , that is not expected What you expected to happen: return correctly
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/assign
Can you clarify "wrong"?
For example in will add and to field of ResourceQuotaSpec. Before , these two resources are not to standard resource sets, will return error since they are not fully-qualified neither. But will not return any error since the two resources are to standard quota resource name sets. The result above is not expected . Error happened in , we need to return it instead of returning when we ran


Question: echo "Setting ${name}'s aliases to '${aliases}' (removed ${ip})" # Detach ${MASTER_NAME}-internal-ip from ${name} gcloud compute instances network-interfaces update "${name}" --project "${PROJECT}" --zone "${zone}" --aliases="${aliases}" <ins> gcloud compute instances remove-metadata "${name}" --zone "${zone}" --keys=kube-master-internal-ip </ins> run-gcloud-command "${name}" "${zone}" 'sudo ip route del to local '${ip}'/32 dev $(ip route | grep default | awk '''{print $5}''')' || true return $? }

If you create a private cluster via kube-up using provider GCE, you won't be able to restart your master nodes. If you restart you master, the nodes won't be able to connect to your master. This is due to this line - It gets executed on master on cluster-up, but it won't be re-executed on master restart. We should fix that, especially if we're to implement /sig scalability /priority important-soon
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 /good-first-issue I'll ask whether someone in SIG Scalability public meeting would like to take on this one
This request has been marked as suitable for new contributors. 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 stale /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
Hello, Can I start work on this one as my first issue? :)
I don't see anyone else claiming it, so your contributions are welcome :)
let me know if you need any explanations here
Thank you :) I've made some changes and assign you can you tell me is this will be good approach?
Thanks, I replied in the PR


Question: nodeName        types.NodeName volumeHost      volume.VolumeHost migratedPlugins map[string](func() bool) <ins> // lock protects changes to node. lock sync.Mutex </ins> } // If no updates is needed, the function must return the same Node object as the input.

What happened: I two CSI plugins to my Kubernetes cluster via a single call to . When I did this, the annotation was improperly set on 2 out of 3 nodes. Only one of the plugins appeared: What you expected to happen: Both and plugins should have appeared in the annotation. How to reproduce it (as minimally and precisely as possible): Apply two or more CSI plugins via a single call to . Anything else we need to know?: Kubelet logs indicate that it registered both plugins at the same time: The CSINode object looks complete: Only the node's annotation did not include Restarting kubelet fixed the issue. It looks like a race condition when InstallCSIDriver is called concurrently for multiple drivers. The code here: could lead to each thread observing the annotation as being empty, and then setting its own annotation that includes only itself. Environment: Kubernetes version (use ): v1.17.11 Cloud provider or hardware configuration: AWS OS (e.g: ): Ubuntu 20.04.1 LTS Kernel (e.g. ): Linux ip-172-31-17-163 5.4.0-1021-aws -Ubuntu SMP Fri Jul 24 09:42:29 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: juju
/sig storage
/assign
I can reproduce this issue with commands below ! The correct csi nodeid would be like this


Question: clientsetPods: []runtime.Object{testPodWithOneContainers()}, actions: []testclient.Action{ testclient.NewListAction(podsResource, podsKind, "test", metav1.ListOptions{LabelSelector: "foo=bar"}), <del> getLogsAction("test", nil), </del> <ins> getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), </ins> }, expectedSources: []corev1.ObjectReference{{ Kind:       testPodWithOneContainers().Kind,

/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /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


What happened: I checked if kubelet () has permissions for with SelfsubjectAccessReviews and I saw that it has. But when I checked its permissions with SelfsubjectRulesReviews it didn't show it. What you expected to happen: I expected that the API SelfsubjectRulesReviews will show that has permssions for . How to reproduce it (as minimally and precisely as possible): You can check it on the master or the worker. Test SelfsubjectAccessReviews: You will get answer that it has permissions: Test SelfsubjectRulesReviews: It won't show the permissions. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ):Install tools: kubeadm /area/api /kind/bug /sig api-machinery
/sig api-machinery
This is a more clean display that show the bug: I think the problem is related to the fact that the file contain the kubelet certificate which is part of the group :
/sig auth
What is the SelfSubjectRulesReview response from the server ()? Note that not all authorizers support enumerating permissions, and the API object status includes an attribute which explicitly indicates the result is incomplete. See
It has Details:
I noticed that it also doesn't show that it has permissions to view and . It probably related to the Node authorizer: Because I assume that these rules doesn't appear in RBAC.
The node authorizer does not enumerate permissions, so it does not contribute to SelfSubjectRulesReview results
fixes setting correctly when the API is requested with a kubelet's credentials


Question: github.com/robfig/cron v1.1.0/go.mod h1:JGuDeoQd7Z6yL4zQhZ3OPEVHB7fL6Ka6skscFHfmt2k= github.com/rogpeppe/fastuuid v0.0.0-20150106093220-6724a57986af/go.mod h1:XWv6SoW27p1b0cqNHllgS5HIMJraePCO15w5zCzIWYg= github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4= <del> github.com/rubiojr/go-vhd v0.0.0-20160810183302-0bfd3b39853c h1:ht7N4d/B7Ezf58nvMNVF3OlvDlz9pp+WHVcRNS0nink= github.com/rubiojr/go-vhd v0.0.0-20160810183302-0bfd3b39853c/go.mod h1:DM5xW0nvfNNm2uytzsvhI3OnX8uzaRAg8UX/CnDqbto= </del> <ins> github.com/rubiojr/go-vhd v0.0.0-20200706105327-02e210299021 h1:if3/24+h9Sq6eDx8UUz1SO9cT9tizyIsATfB7b4D3tc= github.com/rubiojr/go-vhd v0.0.0-20200706105327-02e210299021/go.mod h1:DM5xW0nvfNNm2uytzsvhI3OnX8uzaRAg8UX/CnDqbto= </ins> github.com/russross/blackfriday v1.5.2 h1:HyvC0ARfnZBqnXwABFeSZHpKvJHJJfPz81GNueLj0oo= github.com/russross/blackfriday v1.5.2/go.mod h1:JO/DiYxRf+HjHt06OyowR9PTA263kcR/rfWxYHBV53g= github.com/russross/blackfriday/v2 v2.0.1 h1:lPqVAte+HuHNfhJ/0LC98ESWRz8afy9tM/0RK8m9o+Q=

I ran an OSS license scan of a codebase that has this project as a dependency and came across an interesting hit. This go-vhd dependency specified here: has a snippet of code from StackOverflow which is license under creative commons sharealike. Here's the code in question: I'm not a license expert, so I don't know if there are any real issues/conflicts here or not, but wanted to share to see what you all think. Here's SO's license info for reference: My understanding is that the potential issue would be with this clause: which could potentially require go-vhd and projects that depend on it to use the Creative Commons license as well.
Thanks for the report! can you please take a look if this is concerning? If so, we'll check if we can avoid this dependency (looks unlikely unless we duplicate what it's ) or we'll follow up upstream to update the code. /cc OWNERS for this repo
CC-BY-SA can be problematic in Apache-2.0 projects like k8s because of the ShareAlike aspect as noted. I'd recommend working with upstream to rewrite just that one function particularly since it looks like it's fairly limited.
let's please move this issue to kubernetes/kubernetes?
/provider azure
/sig release /area code-organization
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig release /area code-organization Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc /assign
/area code-organization
/assign
/milestone v1.19 /priority important-soon
Not a huge difference, but this is likely actually licensed under , not 4.0. See
the k/k code actually does not reference , since that function is in , do you mean we should remove from k/k totally?
Yes, we would either need to remove from k/k or ask the maintainers of to update . This means that (and k/k if we end up using it) would need to be licensed until CC-BY-SA.
Would this ultimately be backported to older versions of k8s or would you just do it in 1.19?

thanks, Let me remove the code in v1.19, actually that part of functionality is deprecated in Azure cloud provider already. My initial thought is only do this in v1.19
/kind bug /priority important-soon /sig cloud-provider /area provider/azure
Since it isn't trivial to remove as a dependency entirely (), I've created upstream to track updating the code there.


Question: t.Errorf("Expected mount options to be %v got %v", expectedMountOptions, mountOptions) } } <ins> func TestGetCandidateZone(t *testing.T) { const testZone = "my-zone-1a" // TODO: add test case for immediate bind volume when we have a good way to mock Cloud outside cloudprovider tests := []struct { cloud         *aws.Cloud node          *v1.Node expectedZones sets.String }{ { cloud: nil, node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Labels: map[string]string{ v1.LabelZoneFailureDomain: testZone, }, }, }, expectedZones: sets.NewString(), }, { cloud:         nil, node:          &v1.Node{}, expectedZones: sets.NewString(), }, } for _, test := range tests { zones, err := getCandidateZones(test.cloud, test.node) assert.Nil(t, err) assert.Equal(t, test.expectedZones, zones) } } </ins>

<!-- 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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign


Question: exec := exec.New() outputBytes, err := exec.Command(nsenterPath, args...).CombinedOutput() if len(outputBytes) != 0 { <del> glog.V(5).Infof("Output from mount command: %v", string(outputBytes)) </del> <ins> glog.V(5).Infof("Output of unmounting %s: %v", target, string(outputBytes)) </ins> } return err

Currently, there many error messages in that do not contain any context. This means that these messages are basically meaningless in real systems where many pods may be on a node. Examples: Every error message in this file should identify the path that the message is in relation to.
Can you handle this, since you most recently touched in ?