Question: return cmdutil.UsageError(cmd, execUsageStr) } } <ins> namespace, _, err := f.DefaultNamespace() if err != nil { return err } p.Namespace = namespace clientMapper := resource.ClientMapperFunc(f.ClientForMapping) mapper, typer := f.Object() decoder := f.Decoder(true) infos, err := resource.NewBuilder(mapper, typer, clientMapper, decoder). NamespaceParam(p.Namespace).DefaultNamespace(). ResourceNames("pods", p.PodName). SingleResourceType(). Do().Infos() if err != nil { return err } if len(infos) != 1 { return cmdutil.UsageError(cmd, execUsageStr) } p.PodName = infos[0].Name </ins> cmdParent := cmd.Parent() if cmdParent != nil {

I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.


Question: KUBERNETES_CONFIGURE_CBR0: $(yaml-quote ${KUBERNETES_CONFIGURE_CBR0:-true}) EOF fi <del> if [[ "${ENABLE_NODE_AUTOSCALER:-}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER}" == "true" ]]; then </ins> cat >>$file <<EOF <del> ENABLE_CLUSTER_AUTOSCALER: $(yaml-quote "true") </del> <ins> ENABLE_CLUSTER_AUTOSCALER: $(yaml-quote ${ENABLE_CLUSTER_AUTOSCALER}) </ins> AUTOSCALER_MIG_CONFIG: $(yaml-quote ${AUTOSCALER_MIG_CONFIG}) EOF fi

In kube-up we use var while in GKE, documentation, issues etc I think we call it cluster autoscaler. We should make it consistent.
I assume this is what you were already thinking, but: I think we should change it to cluster autoscaler (everywhere). You scale the cluster by adding/removing nodes. You scale a node by adding/removing resources to/from the node, so node autoscaler isn't the right term IMO.


Question: }); err != nil { t.Errorf("Waiting for Pod to get the finalizer removed: %v", err) } <del> if !tc.inCache && jobSynced { t.Error("Tried to sync deleted job") } </del> }) } }

pull-kubernetes-unit TestWatchOrphanPods/orphan May 4th Waiting for Pod to get the finalizer removed: timed out waiting for the condition No response /sig apps
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
Likely a bug in


Question: "containers":[ { "name":"redis-master", <del> "image": "gcr.io/google_containers/redis:e2e", </del> <ins> "image": "gcr.io/k8s-testimages/redis:e2e", </ins> "ports":[ { "name":"redis-server",

Kubernetes version (use ): master What happened: Pulling the redis image takes a while, like 30 seconds in GCE. This might be leading to periodic timeouts in tests like . What you expected to happen: Tests shouldn't depend on large images that take a potentially long time to pull. proposed fix to reduce flakiness we can increase the replica count on this test to 2 or make the redis image we use smaller (or not use redis at all and just use a simpler smaller image)
cc (considering this as a bug since we shouldnt need a 500MG image just to test kubectl :))
This should be as simple as changing the current to use alpine and install redis, instead of basing it off debian, installing gcc, and compiling redis from source :-) The image should be ~10MB.


Question: framework.ExpectEqual(*(rs.Spec.Replicas), int32(4), "replicaset should have 4 replicas") } <ins> // ReplicaSet Replace and Patch tests func testRSLifeCycle(f *framework.Framework) { ns := f.Namespace.Name c := f.ClientSet zero := int64(0) // Create webserver pods. rsPodLabels := map[string]string{ "name": "sample-pod", "pod":  WebserverImageName, } rsName := "test-rs" replicas := int32(1) rsPatchReplicas := int32(3) rsPatchImage := imageutils.GetE2EImage(imageutils.Pause) // Create a ReplicaSet rs := newRS(rsName, replicas, rsPodLabels, WebserverImageName, WebserverImage, nil) _, err := c.AppsV1().ReplicaSets(ns).Create(context.TODO(), rs, metav1.CreateOptions{}) framework.ExpectNoError(err) // Verify that the required pods have come up. err = e2epod.VerifyPodsRunning(c, ns, "sample-pod", false, replicas) framework.ExpectNoError(err, "Failed to create pods: %s", err) // Scale the ReplicaSet ginkgo.By(fmt.Sprintf("Scaling up %q replicaset ", rsName)) _, err = e2ereplicaset.UpdateReplicaSetWithRetries(c, ns, rsName, func(update *appsv1.ReplicaSet) { x := int32(2) update.Spec.Replicas = &x }) framework.ExpectNoError(err, "ReplicaSet fail to scale to %q replicasets") // Patch the PeplicaSet ginkgo.By("patching the ReplicaSet") rsPatch, err := json.Marshal(map[string]interface{}{ "metadata": map[string]interface{}{ "labels": map[string]string{"test-rs": "patched"}, }, "spec": map[string]interface{}{ "replicas": rsPatchReplicas, "template": map[string]interface{}{ "spec": map[string]interface{}{ "TerminationGracePeriodSeconds": &zero, "containers": [1]map[string]interface{}{{ "name":    rsName, "image":   rsPatchImage, "command": []string{"/bin/sleep", "100000"}, }}, }, }, }, }) framework.ExpectNoError(err, "failed to Marshal ReplicaSet JSON patch") _, err = f.ClientSet.AppsV1().ReplicaSets(ns).Patch(context.TODO(), rsName, types.StrategicMergePatchType, []byte(rsPatch), metav1.PatchOptions{}) framework.ExpectNoError(err, "failed to patch ReplicaSet") rs, err = c.AppsV1().ReplicaSets(ns).Get(context.TODO(), rsName, metav1.GetOptions{}) framework.ExpectNoError(err, "Failed to get replicaset resource: %v", err) framework.ExpectEqual(*(rs.Spec.Replicas), rsPatchReplicas, "replicaset should have 3 replicas") framework.ExpectEqual(rs.Spec.Template.Spec.Containers[0].Image, rsPatchImage, "replicaset not using rsPatchImage. Is using %v", rs.Spec.Template.Spec.Containers[0].Image) } </ins>

[x] two weeks soak end date : 8 March 2021 According to this APIsnoop query, there are still some remaining Replicaset endpoints that are untested. with this query, you can filter untested endpoints by their category and eligibility for conformance. e.g below shows a query to find all conformance eligible untested, stable, core endpoints replaceAppsV1NamespacedReplicaSet does not show up as untested as it touched by another not promoted to Conformance. Create a ReplicaSet with a static label Read the ReplicaSet info Scale the ReplicaSets to 2 Patch the ReplicaSet Read the ReplicaSet to ensure it is Patch Delete the Namespace and ReplicaSet Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent --------------------------------------|
createAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests patchAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests readAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests replaceAppsV1NamespacedReplicaSet | (linux/amd64) kubernetes/$Format -- [sig-apps] ReplicaSet ReplicaSet lifecycle tests (4 rows) If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance /sig apps
/triage accepted
/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: $ cluster/kubecfg.sh -u=30s rollingupdate dataController Watch the UX, it will update one pod every 30 seconds until all of the pods have the new color. <ins> [cloud-console]: https://console.developer.google.com </ins>

<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need reporting of version to be shown in the metrics. Why is this needed: The goal behind this is to add some info about the underlying infrastructure for the kubernetes cluster. Some customers were experiencing issues during the cluster upgrades, but nothing in the upgrades themselves or kubernetes code for provider seemingly could cause those. The issue is storage related, and happening on a variety of releases with a significant delay from any other underlying infrastructure change, to which the kubernetes cluster has no relation and a way to know about. So knowing used hostnames, and versions associated with it over time would be extremely beneficial for debugging in similar circumstances. Some of the use cases we face: 1) A is enabled in a customer environment, and so there occurs a periodic automated vMotion for VMs backing kuberentes . We'd like to know on which host the actual kubernetes was located at any moment, and if any vCenter version transitions happened over time, new hosts /removed/renamed.
/sig cloud-provider /wg provider-vsphere
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cloud-provider /wg provider-vsphere 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
/area provider/vmware


Question: return err } if recreated { <del> newF, err := os.Open(path) </del> <ins> newF, err := openFileShareDelete(path) </ins> if err != nil { if os.IsNotExist(err) { continue

The test is failing on Windows [0]: The idea of the test is to check that kubelet still follows and reads the Container Logs after a Log Rotation occured. However, because the followed file is open, it cannot be renamed, and thus, the container logs cannot be rotated. This issue could be prevented if the file would be opened with the [0] [1] Kubelet should not block container log rotation. Run the test ` is failing on Windows. /sig windows /kind bug /kind failing-test latest, master. This unit test has been failing for a while. N/A Windows nodes </detailsN/A N/A N/A
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
/kind failing-test /sig windows


Question: github.com/urfave/negroni v1.0.0 // indirect github.com/vishvananda/netlink v0.0.0-20171020171820-b2de5d10e38e github.com/vishvananda/netns v0.0.0-20171111001504-be1fbeda1936 // indirect <del> github.com/vmware/govmomi v0.20.1 </del> <ins> github.com/vmware/govmomi v0.20.3 </ins> go.etcd.io/etcd v0.0.0-20191023171146-3cf2f69b5738 golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586 golang.org/x/lint v0.0.0-20190409202823-959b441ac422

Expectation- We should be able to create PVCs via a storageclass with storagePolicyName defined while using a singed ca cert for secure communications with vCenter. Bug- The PVC created with a storageclass with storagePolicyName defined fails with a error when PVCs created with a storageclass without the storagPolicyName work against the same vCenter and datastore. Scenario: Utilizing the vSphere in-tree plugin on kubernetes 1.12.7. Utilizing secure communication with vSphere (signed ca cert imported into the cluster) We are able to create PVCs with the following storage class: However, if we include a storagePolicyName we receive a failure: Here is the yaml for our sc1 storage class: /sig vmware
I think we are having issue with creating PBM client using certificate set on the vCenter Client. We need to create a PBM client to get list of compatible datastore for given storage policy. I think call is failing at - Can you please provide controller-manager logs for further debugging. Make sure log level is set to 4.
Sorry for the delayed response. I'm not confident I got the log level correct, however this is what I find:
I believe I have log level 4 now set:
For comparison, here is a PVC created w/o storagePolicyName on the same datastore which succeeds:
thanks for posting logs. Now this is confirmed, issue is happening while creating PBM client when we use certificate based authentication. One more thing I want to confirm regarding the certificate, are you using solution user as mentioned here -
Can you also provide value of in the file? Is it set to true or false / 1 or 0 ? Also confirm version of vCenter you are using.
is unset, as for the solution user I'd have to leave that to to expand on.
I don't believe we used any solution user because we simply used "" as the default user during installation. please correct me if I'm wrong.
How is the certificate and private key retrieved for the user . I am successfully able to connect to the PBM using vpxd certificte and key. I ssh into the vCenter and executed following commands to retrieve certificate and private key for vpxd. with vpxd cert and private key, I do not see this issue. In addition I also set while making connection.

Can you try setting Insecure to false? That's the flag setting that triggers the cert error.
with , I see the exact same error - , while creating VC client.
Isn't that because it's self-signed? In the case of the issue in this ticket the cert is signed by a trusted CA /cc to confirm.
The cert is self-signed and its CA isn't trusted.
I used vpxd certificate and issuer is I require to set .
Is there any way to make it work if insecure=false?
- then I’d say that’s expected? If the root CA isn’t trusted, then it is insecure?
well, while that's expected, I don't know if there's a method to add the root CA to a trusted list.
Correct me if I’m wrong but isn’t the trusted list the root CA store of the K8S node’s OS in this case? I’d imagine whatever CA Root signed the cert would need to be to the OS of choice’s CA store.
you are correct, we need to download trusted root certificate and add them in the store on node vm. For now on my mac, I have downloaded trusted root certificate from the vCenter -and them in the keychain and flagged as "Always Trust". ! After this, I am able to connect to VC client with or without specifying this flag at all using VPXD certificate and private key. So certificate needs to be to the CA trust store on the master node VM. after adding trusted root certificate from vCenter to the trust store, you should be able to make a connection using .
After importing the root cert by placing it in /etc/ssl/certs on the master node, I'm able to provision a PVC while specifying a storage policy. Thanks for all the help.
Can you close this issue and work with KK to get this automated in the product?
It turns out that importing the root cert into the host was just a workaround, and the actual bug was fixed in That fix is included in govmomi v0.21.0.


Question: RequestCount int } <ins> func init() { lookupIP = func(host string) ([]net.IP, error) { return nil, fmt.Errorf("lookup %v: no such host", host) } } </ins> func (c *FakeNodeHandler) Nodes() client.NodeInterface { return c }

It seems like this depends on the network condition as I first noticed this while on a plane, and it happens to me every so often but never on travis. Offenders are TestSyncNodeStatusDeletePods and TestSyncNodeStatusTransitionTime. This may be reproducible by disconnecting network connection but also happens sometimes while connected. is a call to net.LookupIP(), I'll investigate more.
This also occurs on OSX over a VPN (at least, for my VPN it does). Each call to net.LookupIP(name) takes 30s and fails correctly. As a result, the entire unit test times out. That same function call fails fast on Linux.
cc
For other runtime, we can just mock out net, time. I'd really like to know how to do mocking in go. Using interface seems overkill.


Question: # unit and integration tests FROM golang:1.4 <del> MAINTAINER  jeff lowdermilk <jeffml@google.com> </del> <ins> MAINTAINER  Jeff Lowdermilk <jeffml@google.com> </ins> ENV KUBE_TEST_API_VERSIONS  v1,extensions/v1beta1 ENV KUBE_TEST_ETCD_PREFIXES registry ENV WORKSPACE               /workspace <ins> ENV TERM                    xterm </ins> WORKDIR /workspace <del> ADD run.sh ./ </del> RUN apt-get -o Acquire::Check-Valid-Until=false update && apt-get install -y rsync <ins> RUN apt-get install -y file </ins> RUN mkdir -p /go/src/k8s.io/kubernetes RUN ln -s /go/src/k8s.io/kubernetes /workspace/kubernetes

In the pull request Jenkins, we're running up to 8 instances of verification checks, build, unit tests, integration tests, and e2e tests. Unfortunately, it seems like several of these components were not designed to run simultaneous to other tests on the same machine. In particular, several unit tests seem to write to static file names in /tmp (or equivalent), which is a fairly easy fix. Some of the verification checks and the integration test start up etcd, however, and the etcd helper checks that only a single etcd binary is running on the host (and uses a static port for it). For example: We might be able to fix the etcd issue separately, or we can just figure out how to containerize all of these tests so they can't possibly interfere with each other. Note that we're ignoring the exit status of the verification checks and unit/integration tests right now, so these etcd failures are effectively being ignored (though it is causing us to miss test coverage).
What percentage of tests are failing due to being non-hermetic like this?
I'm not sure about unit tests (I've anecdotally seen just a few fail), but the verification checks are failing fairly regularly, and the integration test is also similarly frequently not running due to this.
To be clear, I'm looking for real numbers, to decide whether it's feasible to temporarily disable a small number of tests until we can hermetify them. Otherwise we need to turn off all unit, integration and verification tests in Jenkins to avoid irritating invalid regression signals. We need to do one or the other this week.
I'll try to dig through the logs, figure out which ones have failed recently, disable them in Jenkins, and see whether the flakes abate.
I just turned off all unit, integration and verification checks in Jenkins, as a temporary measure to unstall the merge-bot.
As a point of information, I just found approximately 20 tests in which use a static tmp path with semi-random filenames which are highly likely to collide. We could keep searching for unit tests that are non-hermetic, but it'd probably be a better investment of time to fix the test infrastructure so test authors don't need to care (and so we don't need to go look at and fix ~2000 test cases).

Another few metrics, using the string "/tmp" as a likely anti-pattern: We'd need to update each of these 23 files to get them to use or if they aren't already.
Created to track cleaning up tempdir usage in unit tests.
cc


Question: }) /* <del> Release: v1.17, v1.21 </del> <ins> Release: v1.17, v1.21, v1.27 </ins> Testname: aggregator-supports-the-sample-apiserver Description: Ensure that the sample-apiserver code from 1.17 and compiled against 1.17 will work on the current Aggregator/API-Server.

[X] Test approval issue: [X] Test PR: [x] Two weeks soak end date: [X] Test promotion PR: According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. Using a number of existing e2e test practices the has to cover the outstanding APIService endpoints. There has been some around how the current Conformance test is using RBAC, which is optional and not part of Conformance. Those calls will now only happen if is true. The e2e logs for this test are listed below.

This query shows the following APIService endpoints are hit within a short period of running this e2e test example endpoint | useragent ---------------------------------------------+
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1CollectionAPIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] (10 rows) If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted


Question: // TestPostFilterPlugin tests invocation of postfilter plugins. func TestPostFilterPlugin(t *testing.T) { <del> numNodes := 1 </del> <ins> var numNodes int32 = 1 </ins> tests := []struct { name                      string <del> numNodes                  int </del> <ins> numNodes                  int32 </ins> rejectFilter              bool failScore                 bool rejectPostFilter          bool <del> expectFilterNumCalled     int </del> <ins> expectFilterNumCalled     int32 </ins> expectScoreNumCalled      int32 expectPostFilterNumCalled int }{ { name:                      "Filter passed and Score success", <del> numNodes:                  3, </del> <ins> numNodes:                  30, </ins> rejectFilter:              false, failScore:                 false, rejectPostFilter:          false, <del> expectFilterNumCalled:     3, expectScoreNumCalled:      3, </del> <ins> expectFilterNumCalled:     30, expectScoreNumCalled:      30, </ins> expectPostFilterNumCalled: 0, }, {

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: integration-master Which test(s) are flaking: TestPostFilterPlugin Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig testing
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 scheduling /remove-sig testing
/assign


Question: variables), pulls service info from the master, and writes that to etcd for SkyDNS to find. <ins> ## Inheriting DNS from the node When running a pod, kubelet will prepend the cluster DNS server and search paths to the node's own DNS settings.  If the node is able to resolve DNS names specific to the larger environment, pods should be able to, also.  See "Known issues" below for a caveat. </ins> ## Known issues Kubernetes installs do not configure the nodes' resolv.conf files to use the cluster DNS by default, because that process is inherently distro-specific. This should probably be implemented eventually. <ins> Linux's libc is impossibly stuck ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just 3 DNS `nameserver` records and 6 DNS `search` records.  Kubernetes needs to consume 1 `nameserver` record and 3 `search` records.  This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es, some of those settings will be lost.  As a partial workaround, the node can run `dnsmasq` which will provide more `nameserver` entries, but not more `search` entries. </ins> ## Making changes Please observe the release process for making changes to the `kube2sky` image that is documented in [RELEASES.md](kube2sky/RELEASES.md). Any significant changes

Needed for new DNS schema transition. was reverted in because of Need to add 'metatdata' to e2e names-to-resolve list for GCE
OK, so we have a real problem. if libc resolver has a limit of 6 search paths, and we intend to prepend at least 3 ( ) there's a very real possibility that a random machine on which someone wants to run kube will have more than 3 search domains. Even worse, what we really want is to prepend 4 (otherwise we have to do a release with which you MUST update your DNS server), and even GCE has 3 search paths. So the question is how to handle it? 1) Use less search paths ourselves. Force users to use more specific names or even FQDNs. Mitigates but does not eliminate the problem. 2) Log an error in kubelet, but soldier on: "some of your DNS search domains may get dropped". It really is "may" since we don't know what every resolver lib does. Need a way for people to fix this, e.g. a kubelet flag --dns-search-paths="," which trumps 3) Make kubelet hard-stop. Log an event, set a Condition, refuse to run. Still need a way to fix this as in (2). for consult.
I suggest the following strategy to move forward: checks for the number of search paths in host's and mark the node unhealthy if it has more than a maximum number of search paths. We can also add a kubelet flag to let users provide custom search paths for pods. being backwards compatible while introducing the new "svc" sub-domain.
For reference RHEL recommends running dnsmasq on systems affected by this, because dnsmasq isn't affected - links to some discussion about the ABI on it.
Could we drop '' for now from the search path? I think i'm less concerned about that one if it's unlikely people change it.
I like it. If we drop for now, we can keep compat and squeek by on GCE. We still need to solve the problem overall.

How about the following: kube dns pod to be upgraded as part of the next release (v0.18.0) kube dns create dns records with and without sub-domain (This is the current plan) kubelet to replace existing search paths with and in the next release (v0.19). Existing pods will not face any resolving issues as long as they don't use FQDNs or have their namespace set to . Pipelining the changes provides some time for users to update their pods if they use FQDNs. Does this work for Openshift , Tim Hockin wrote:
We already dropped the old paths for support, so what you've proposed is fine for us. ----- Original Message -----
raised a good point - Clayton's suggestion doesn't work until search paths are transitioned. We need to be sure: a) running pods can resolve "svc" and "" to "" b) new pods can resolve "svc" and "" to "" or "". depending on search paths Then we can transition search paths to So I think Vish is right, but minor nits: kube-dns release that supports both old and new names. users to upgrade kube-dns after 0.18 before 0.19. only new search paths in 0.19; running pods are fine, new pods are fine : Make kube-dns drop support for old names This will let us squeek by on GCE. In the mean time, we can consider how to make kubelet warn when it detects a problem, and how to mitigate said problem.
/cc
re: dnsmasq, I played with it and got it doing what we need wrt nameservers but NOT wrt search paths. As far as I can tell, it expects to pass queries on unmolested, and that the client has proper search paths. Is there some config I am not seeing that makes it apply search paths to incoming queries before forwarding them? Otherwise we're still stuck at 6.
Is the instruction I got internally. ----- Original Message -----
dnsmasq manpage specifically says it ignores everything but 'nameserver' directives from any file. That means it does not do search path expansion, which is exactly what I observe. DNS forwarding works but it only forwards the queries, not expand them.


Question: })) framework.Logf("Reconciled root ca configmap in namespace %q", f.Namespace.Name) }) <ins> ginkgo.It("should update a ServiceAccount", func() { saClient := f.ClientSet.CoreV1().ServiceAccounts(f.Namespace.Name) saName := "e2e-sa-" + utilrand.String(5) initialServiceAccount := &v1.ServiceAccount{ ObjectMeta: metav1.ObjectMeta{ Name: saName, }, AutomountServiceAccountToken: utilptr.Bool(false), } ginkgo.By(fmt.Sprintf("Creating ServiceAccount %q ", saName)) createdServiceAccount, err := saClient.Create(context.TODO(), initialServiceAccount, metav1.CreateOptions{}) framework.ExpectNoError(err) framework.ExpectEqual(createdServiceAccount.AutomountServiceAccountToken, utilptr.Bool(false), "Failed to set AutomountServiceAccountToken") framework.Logf("AutomountServiceAccountToken: %v", *createdServiceAccount.AutomountServiceAccountToken) ginkgo.By(fmt.Sprintf("Updating ServiceAccount %q ", saName)) var updatedServiceAccount *v1.ServiceAccount err = retry.RetryOnConflict(retry.DefaultRetry, func() error { updateServiceAccount, err := saClient.Get(context.TODO(), saName, metav1.GetOptions{}) framework.ExpectNoError(err, "Unable to get ServiceAccount %q", saName) updateServiceAccount.AutomountServiceAccountToken = utilptr.Bool(true) updatedServiceAccount, err = saClient.Update(context.TODO(), updateServiceAccount, metav1.UpdateOptions{}) return err }) framework.ExpectNoError(err, "Failed to update ServiceAccount") framework.ExpectEqual(updatedServiceAccount.AutomountServiceAccountToken, utilptr.Bool(true), "Failed to set AutomountServiceAccountToken") framework.Logf("AutomountServiceAccountToken: %v", *updatedServiceAccount.AutomountServiceAccountToken) }) </ins> }) var reportLogsParser = regexp.MustCompile("([a-zA-Z0-9-_]*)=([a-zA-Z0-9-_]*)$")

[X] Test approval issue: [X] Test PR: 5 Oct 2022 [X] Two weeks soak end date: 19 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still three remaining LimitRange endpoints which are untested. replaceCoreV1NamespacedServiceAccount Using a number of existing e2e test practices a new has been created for one ServiceAccount endpoint. The e2e logs for this test are listed below. This query shows which ServiceAccount endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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: <ins> /* Copyright 2015 The Kubernetes Authors All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package executor import ( "sync/atomic" "testing" "time" "github.com/golang/glog" bindings "github.com/mesos/mesos-go/executor" ) type suicideTracker struct { suicideWatcher stops  uint32 resets uint32 timers uint32 jumps  *uint32 } func (t *suicideTracker) Reset(d time.Duration) bool { defer func() { t.resets++ }() return t.suicideWatcher.Reset(d) } func (t *suicideTracker) Stop() bool { defer func() { t.stops++ }() return t.suicideWatcher.Stop() } func (t *suicideTracker) Next(d time.Duration, driver bindings.ExecutorDriver, f jumper) suicideWatcher { tracker := &suicideTracker{ stops:  t.stops, resets: t.resets, jumps:  t.jumps, timers: t.timers + 1, } jumper := tracker.makeJumper(f) tracker.suicideWatcher = t.suicideWatcher.Next(d, driver, jumper) return tracker } func (t *suicideTracker) makeJumper(_ jumper) jumper { return jumper(func(driver bindings.ExecutorDriver, cancel <-chan struct{}) { glog.Warningln("jumping?!") if t.jumps != nil { atomic.AddUint32(t.jumps, 1) } }) } func TestSuicide_zeroTimeout(t *testing.T) { defer glog.Flush() k := New(Config{}) tracker := &suicideTracker{suicideWatcher: k.suicideWatch} k.suicideWatch = tracker ch := k.resetSuicideWatch(nil) select { case <-ch: case <-time.After(2 * time.Second): t.Fatalf("timeout waiting for reset of suicide watch") } if tracker.stops != 0 { t.Fatalf("expected no stops since suicideWatchTimeout was never set") } if tracker.resets != 0 { t.Fatalf("expected no resets since suicideWatchTimeout was never set") } if tracker.timers != 0 { t.Fatalf("expected no timers since suicideWatchTimeout was never set") } } func TestSuicide_WithTasks(t *testing.T) { defer glog.Flush() k := New(Config{ SuicideTimeout: 50 * time.Millisecond, }) jumps := uint32(0) tracker := &suicideTracker{suicideWatcher: k.suicideWatch, jumps: &jumps} k.suicideWatch = tracker k.tasks["foo"] = &kuberTask{} // prevent suicide attempts from succeeding // call reset with a nil timer glog.Infoln("resetting suicide watch with 1 task") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 1 { t.Fatalf("expected suicide attempt to Stop() since there are registered tasks") } if tracker.resets != 0 { t.Fatalf("expected no resets since") } if tracker.timers != 0 { t.Fatalf("expected no timers since") } case <-time.After(1 * time.Second): t.Fatalf("initial suicide watch setup failed") } delete(k.tasks, "foo") // zero remaining tasks k.suicideTimeout = 1500 * time.Millisecond suicideStart := time.Now() // reset the suicide watch, which should actually start a timer now glog.Infoln("resetting suicide watch with 0 tasks") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 1 { t.Fatalf("did not expect suicide attempt to Stop() since there are no registered tasks") } if tracker.resets != 1 { t.Fatalf("expected 1 resets instead of %d", tracker.resets) } if tracker.timers != 1 { t.Fatalf("expected 1 timers instead of %d", tracker.timers) } case <-time.After(1 * time.Second): t.Fatalf("2nd suicide watch setup failed") } k.lock.Lock() k.tasks["foo"] = &kuberTask{} // prevent suicide attempts from succeeding k.lock.Unlock() // reset the suicide watch, which should stop the existing timer glog.Infoln("resetting suicide watch with 1 task") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 2 { t.Fatalf("expected 2 stops instead of %d since there are registered tasks", tracker.stops) } if tracker.resets != 1 { t.Fatalf("expected 1 resets instead of %d", tracker.resets) } if tracker.timers != 1 { t.Fatalf("expected 1 timers instead of %d", tracker.timers) } case <-time.After(1 * time.Second): t.Fatalf("3rd suicide watch setup failed") } k.lock.Lock() delete(k.tasks, "foo") // allow suicide attempts to schedule k.lock.Unlock() // reset the suicide watch, which should reset a stopped timer glog.Infoln("resetting suicide watch with 0 tasks") select { case <-k.resetSuicideWatch(nil): tracker = k.suicideWatch.(*suicideTracker) if tracker.stops != 2 { t.Fatalf("expected 2 stops instead of %d since there are no registered tasks", tracker.stops) } if tracker.resets != 2 { t.Fatalf("expected 2 resets instead of %d", tracker.resets) } if tracker.timers != 1 { t.Fatalf("expected 1 timers instead of %d", tracker.timers) } case <-time.After(1 * time.Second): t.Fatalf("4th suicide watch setup failed") } sinceWatch := time.Since(suicideStart) time.Sleep(3*time.Second - sinceWatch) // give the first timer to misfire (it shouldn't since Stop() was called) if j := atomic.LoadUint32(&jumps); j != 1 { t.Fatalf("expected 1 jumps instead of %d since stop was called", j) } else { glog.Infoln("jumps verified") // glog so we get a timestamp } } </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: Followed the documentation on rules to limit group Id's to non-superuser (root) using the rule. The creation attempt failed with: From PSP yaml: What you expected to happen: Successfully create a new PSP for non-superuser (root) group privileges using available rule values (which actually seems to be , , according the the ) How to reproduce it (as minimally and precisely as possible): Attempt to create a PSP with a rule set to Anything else we need to know?: I don't think so Environment: Kubernetes version (use ): , looks to affect , and doc as well Cloud provider or hardware configuration: IBM Cloud OS (e.g: ):Kernel (e.g. ): Install tools: Others:
/sig docs
/assign
thanks will send out a fix next week
I wonder whether this is a bug in implementation or the document. Is this really a documentation issue?
yes, RunAsGroup does not support MustRunAsNonRoot
Got it. Thank you!
/priority important-soon


Question: ) // updateReplicaSetStatus attempts to update the Status.Replicas of the given ReplicaSet, with a single GET/PUT retry. <del> func updateReplicaSetStatus(c unversionedextensions.ReplicaSetInterface, rs *extensions.ReplicaSet, newStatus extensions.ReplicaSetStatus) (updateErr error) { </del> <ins> func updateReplicaSetStatus(c unversionedextensions.ReplicaSetInterface, rs *extensions.ReplicaSet, newStatus extensions.ReplicaSetStatus) (*extensions.ReplicaSet, error) { </ins> // This is the steady state. It happens when the ReplicaSet doesn't have any expectations, since // we do a periodic relist every 30s. If the generations differ but the replicas are // the same, a caller might've resized to the same replica count.

Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? dangling ReplicaSet Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure A1 OS (e.g. from /etc/os-release): NAME="Container Linux by CoreOS" ID=coreos VERSION=1235.9.0 VERSIONID=1235.9.0 BUILDID=2017-02-02-0235 PRETTYNAME="Container Linux by CoreOS 1235.9.0 (Ladybug)" ANSICOLOR="38;5;75" HOMEURL="" BUGREPORTURL="" Kernel (e.g. ): Linux node-3-vm 4.7.3-coreos-r2 SMP Thu Feb 2 02:26:10 UTC 2017 x8664 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools: own Others: What happened: Created new deployment by altering the image tag of the deployment descriptor and using kubectl apply -f "". Noticed that one container of the previous deployment stayed there. What you expected to happen: All containers from the previous deployment should have been terminated. How to reproduce it (as minimally and precisely as possible): I cannot reliably trigger this, I do several deployments per hour and sometimes this problem manifests itself. Anything else we need to know: Deployment descriptor:
Can you also post the output of kubectl get deployment tviftttapp -o yaml kubectl get rs (dangling rs) -o yaml When this manifests again?
Here are the current deployment, the dangling RS, and the "good" RS. Deployment: Dangling RS: Current RS:
It seems that status.availableReplicas for the new replica set is never correctly updated to 2. Short term if you stop using minReadySeconds (minReadySeconds=2 doesn't offer you much anyway), this problem should stop. Long term, we should fix the status update. cc:
can one of you guys paste logs from the controller manager when this issue occurs? Log level should be ideally set to 2.

I managed to reproduce it:
Will close this one once is cherry-picked into 1.5
4 is out and contains a fix that should force the Deployment to be resynced eventually and have availableReplicas updated. Not optimal yet but eventually consistent. I have queued up some follow-up work to refine the resync.
Does anyone know when version 1.5.4 OR 1.6 will be available using Redhat package downloads (in RPM form) ? I only see version 1.5.2 being the latest there. I have the same problem that is being discussed in this thread and want to upgrade so that my K8S cluster can support Deployments.


Question: // 	    # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt" // 	    # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key" // 	networking: <del> // 	  serviceSubnet: "10.96.0.0/12" // 	  podSubnet: "10.100.0.1/24" </del> <ins> // 	  serviceSubnet: "10.96.0.0/16" // 	  podSubnet: "10.244.0.0/24" </ins> // 	  dnsDomain: "cluster.local" // 	kubernetesVersion: "v1.12.0" // 	controlPlaneEndpoint: "10.100.0.1:6443"

<!-- 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 --I am trying to learn how to use kubeadm well and it looks like there may be a problem in the example configuration in . It says , but also uses address 10.100.0.1 for various host things like the kube-apiserver and the etcd server and the scheduler. Also, interestingly, it puts a different address --- 10.100.1.1 --- in the apiserver's cert SANs. I expected to not be confused. Kubernetes version (use ): 1.21.1 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:
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
seems more like sig/cluster-lifecycle?
/area kubeadm
Sorry, typo, corrected.
But the 'bot does not seem to have noticed the edit.
/remove-sig multicluster
/sig cluster-lifecycle
yeah, FWIW commands are never evaluated on comment edit versus a new comment so that trivial edits do not e.g. restart tests etc. also no need to apologize! just trying to make sure things get the attention of the right folks. in particular seems to stay pretty on top of SCL/kubeadm issues
For the certs sans part, it seems to be intended as the comments above. For podSubnet and node Address overlap, it may be not suggested? Let me check.

Here is an example for dual-stack:
The podSubnet part in the dual stack example is suggested by in
he is right, the docs are wrong should be 10.100.0.0/24, but I think that is more an aesthetic issue, and the code will take the right subnet, but for docs is better to be pedantic yeah, that is why I always suggest to use subnets with more clear differentiation, 10.100.0.0/24 and 10.100.1.0/24 are easy to get wrong, however , 10.96.0.0/16 and 10.244.0.0/16 are not


Question: pvcConditions := pvc.Status.Conditions Expect(len(pvcConditions)).To(Equal(0), "pvc should not have conditions") }) <ins> It("should allow expansion of block volumes", func() { pvc, storageClassVar, err = setupFunc(true /*allowExpansion*/, true /*blockVolume*/) By("Waiting for pvc to be in bound phase") pvcClaims := []*v1.PersistentVolumeClaim{pvc} pvs, err := framework.WaitForPVClaimBoundPhase(c, pvcClaims, framework.ClaimProvisionTimeout) framework.ExpectNoError(err, "Failed waiting for PVC to be bound %v", err) Expect(len(pvs)).To(Equal(1)) By("Expanding current pvc") newSize := resource.MustParse("6Gi") pvc, err = expandPVCSize(pvc, newSize, c) framework.ExpectNoError(err, "While updating pvc for more size") Expect(pvc).NotTo(BeNil()) pvcSize := pvc.Spec.Resources.Requests[v1.ResourceStorage] if pvcSize.Cmp(newSize) != 0 { framework.Failf("error updating pvc size %q", pvc.Name) } By("Waiting for cloudprovider resize to finish") err = waitForControllerVolumeResize(pvc, c, totalResizeWaitPeriod) framework.ExpectNoError(err, "While waiting for pvc resize to finish") By("Waiting for file system resize to finish") pvc, err = waitForFSResize(pvc, c) framework.ExpectNoError(err, "while waiting for fs resize to finish") pvcConditions := pvc.Status.Conditions Expect(len(pvcConditions)).To(Equal(0), "pvc should not have conditions") }) </ins> }) func createStorageClass(t testsuites.StorageClassTest, ns string, suffix string, c clientset.Interface) (*storage.StorageClass, error) {

<!-- 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: I created a block EBS volume using dynamic provisioning. Then I resized the volume from 10GB to 20 GB. Both PV and block volume reflects the change, but the PVC's capacity is still 10GB. This could be caused by in-tree resize put the PVC condition under state, but no one is acting on the condition since it is block volume: /cc /sig storage What you expected to happen: PVC's capacity should be updated to 20GB How to reproduce it (as minimally and precisely as possible): Easy to reproduce using following specs: StorageClass: Claim: Pod: Anything else we need to know?: This will affect whether CSI migration should handle migration scenario for block volume resizing. Environment: Kubernetes version (use ):1.13 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: kops Network plugin and version (if this is a network-related bug): Others:
/sig aws
/assign


Question: }) Context("", func() { It("pod infra containers oom-score-adj should be -998 and best effort container's should be 1000", func() { <del> var err error </del> <ins> // Take a snapshot of existing pause processes. These were // created before this test, and may not be infra // containers. They should be excluded from the test. existingPausePIDs, err := getPidsForProcess("pause", "") Expect(err).To(BeNil(), "failed to list all pause processes on the node") existingPausePIDSet := sets.NewInt(existingPausePIDs...) </ins> podClient := f.PodClient() podName := "besteffort" + string(uuid.NewUUID()) podClient.Create(&v1.Pod{

The test is failing in . https://k8s- https://k8s- https://k8s- The reason is that the test expects that all pause containers () should have . However, in many tests, we are starting test containers with . Those pause containers have . Ideally, containers started in previous test should be cleaned up, so in serial suite it should not affect later test. However, it is not always true when CRI is enabled. For example, in the oom message, we could see: There are 2 problems here: Why are containers not properly cleaned up when CRI enabled? I can't even find which test leaked pause container from the log, because there are many test using pause image, and some of them start a lot of containers, such as density test, restart test. The oom score adj test should not rely on process name . However, I can't find an alternative for now, because we don't report pause container status in our api, we don't even know the container id to inspect with docker or CRI. /cc
This test is still flaking in cri-serial. Some examples: https://k8s- https://k8s- Need to check the logs to see if the symptoms are the same.
It could be that with CRI, it takes kubelet longer to clean up. Or, even worse, that kubelet is not cleaning up properly. We need more information on this on failure. Dumping pods on the node Dumping containers () on the node. Accessing docker directly is not ideal, but it's okay because the test itself only applies to docker. Alternatively, we can get the current running containers from kubelet's /runningPods endpoint. The downside is that this may lag behind the actual state a little bit (seconds). We should also make the test suite run more frequently. It runs once a day, which makes the debugging round-trip overhead too high.
I can reproduce this process leak by running the "Network should recover from ip leaks" on my own node, without CRI enabled. The image used in the test was , and the docker version 1.11.2. The test creates 100 pods, then restarts the docker service by 6 times, with 20s interval in between.

After the test ends, there could be multiple processes running left on the node. Those processes were reparented to pid 1, and showed no containers running. /cc
On the side note, the test should not be blindly checking all processes. It should, instead, take a snapshot of the system before the test and only check the new processes created by the tests.
I filed a new issue for the docker bug since it's not unique to CRI and this test is catching it by accident: Leaving this issue to fix the test by not blindly checking all processes:
The docker bug is not a regression, and is tracked in . The problem of the test is not necessarily to be fixed in v1.6, at least it's not release blocker. :)


Question: } } }` <del> secret := &v1.Secret{ Data: map[string][]byte{v1.DockerConfigJsonKey: []byte(auth)}, Type: v1.SecretTypeDockerConfigJson, } // The following images are not added into NodeImageWhiteList, because this test is // testing image pulling, these images don't need to be prepulled. The ImagePullPolicy // is v1.PullAlways, so it won't be blocked by framework image white list check. for _, testCase := range []struct { description string image       string secret      bool phase       v1.PodPhase waiting     bool }{ { description: "should not be able to pull image from invalid registry", image:       "invalid.com/invalid/alpine:3.1", phase:       v1.PodPending, waiting:     true, }, { description: "should not be able to pull non-existing image from gcr.io", image:       "k8s.gcr.io/invalid-image:invalid-tag", phase:       v1.PodPending, waiting:     true, }, { // TODO(claudiub): Add a Windows equivalent test. description: "should be able to pull image from gcr.io [LinuxOnly]", image:       "gcr.io/google-containers/debian-base:0.4.1", phase:       v1.PodRunning, waiting:     false, }, { description: "should be able to pull image from docker hub [LinuxOnly]", image:       "alpine:3.7", phase:       v1.PodRunning, waiting:     false, }, { description: "should be able to pull image from docker hub [WindowsOnly]", image:       "e2eteam/busybox:1.29", phase:       v1.PodRunning, waiting:     false, }, { description: "should not be able to pull from private registry without secret", image:       "gcr.io/authenticated-image-pulling/alpine:3.7", phase:       v1.PodPending, waiting:     true, }, { description: "should be able to pull from private registry with secret [LinuxOnly]", image:       "gcr.io/authenticated-image-pulling/alpine:3.7", secret:      true, phase:       v1.PodRunning, waiting:     false, }, } { testCase := testCase It(testCase.description+" [NodeConformance]", func() { if strings.Contains(testCase.description, "[WindowsOnly]") { framework.SkipUnlessNodeOSDistroIs("windows") } name := "image-pull-test" command := []string{"/bin/sh", "-c", "while true; do sleep 1; done"} container := ConformanceContainer{ PodClient: f.PodClient(), Container: v1.Container{ Name:    name, Image:   testCase.image, Command: command, // PullAlways makes sure that the image will always be pulled even if it is present before the test. ImagePullPolicy: v1.PullAlways, }, RestartPolicy: v1.RestartPolicyNever, </del> <ins> secret := &v1.Secret{ Data: map[string][]byte{v1.DockerConfigJsonKey: []byte(auth)}, Type: v1.SecretTypeDockerConfigJson, </ins> } <del> if testCase.secret { secret.Name = "image-pull-secret-" + string(uuid.NewUUID()) By("create image pull secret") _, err := f.ClientSet.CoreV1().Secrets(f.Namespace.Name).Create(secret) Expect(err).NotTo(HaveOccurred()) defer f.ClientSet.CoreV1().Secrets(f.Namespace.Name).Delete(secret.Name, nil) container.ImagePullSecrets = []string{secret.Name} </del> <ins> secret.Name = "image-pull-secret-" + string(uuid.NewUUID()) By("create image pull secret") _, err := f.ClientSet.CoreV1().Secrets(f.Namespace.Name).Create(secret) Expect(err).NotTo(HaveOccurred()) defer f.ClientSet.CoreV1().Secrets(f.Namespace.Name).Delete(secret.Name, nil) container.ImagePullSecrets = []string{secret.Name} } // checkContainerStatus checks whether the container status matches expectation. checkContainerStatus := func() error { status, err := container.GetStatus() if err != nil { return fmt.Errorf("failed to get container status: %v", err) </ins> } <del> // checkContainerStatus checks whether the container status matches expectation. checkContainerStatus := func() error { status, err := container.GetStatus() if err != nil { return fmt.Errorf("failed to get container status: %v", err) } // We need to check container state first. The default pod status is pending, If we check // pod phase first, and the expected pod phase is Pending, the container status may not // even show up when we check it. // Check container state if !testCase.waiting { if status.State.Running == nil { return fmt.Errorf("expected container state: Running, got: %q", GetContainerState(status.State)) } </del> <ins> // We need to check container state first. The default pod status is pending, If we check pod phase first, // and the expected pod phase is Pending, the container status may not even show up when we check it. // Check container state if !expectedPullStatus { if status.State.Running == nil { return fmt.Errorf("expected container state: Running, got: %q", GetContainerState(status.State)) </ins> } <del> if testCase.waiting { if status.State.Waiting == nil { return fmt.Errorf("expected container state: Waiting, got: %q", GetContainerState(status.State)) } reason := status.State.Waiting.Reason if reason != images.ErrImagePull.Error() && reason != images.ErrImagePullBackOff.Error() { return fmt.Errorf("unexpected waiting reason: %q", reason) } } // Check pod phase phase, err := container.GetPhase() if err != nil { return fmt.Errorf("failed to get pod phase: %v", err) </del> <ins> } if expectedPullStatus { if status.State.Waiting == nil { return fmt.Errorf("expected container state: Waiting, got: %q", GetContainerState(status.State)) </ins> } <del> if phase != testCase.phase { return fmt.Errorf("expected pod phase: %q, got: %q", testCase.phase, phase) </del> <ins> reason := status.State.Waiting.Reason if reason != images.ErrImagePull.Error() && reason != images.ErrImagePullBackOff.Error() { return fmt.Errorf("unexpected waiting reason: %q", reason) </ins> } <del> return nil </del> } <del> // The image registry is not stable, which sometimes causes the test to fail. Add retry mechanism to make this // less flaky. const flakeRetry = 3 for i := 1; i <= flakeRetry; i++ { var err error By("create the container") container.Create() By("check the container status") for start := time.Now(); time.Since(start) < ContainerStatusRetryTimeout; time.Sleep(ContainerStatusPollInterval) { if err = checkContainerStatus(); err == nil { break } } By("delete the container") container.Delete() if err == nil { </del> <ins> // Check pod phase phase, err := container.GetPhase() if err != nil { return fmt.Errorf("failed to get pod phase: %v", err) } if phase != expectedPhase { return fmt.Errorf("expected pod phase: %q, got: %q", expectedPhase, phase) } return nil } // The image registry is not stable, which sometimes causes the test to fail. Add retry mechanism to make this less flaky. const flakeRetry = 3 for i := 1; i <= flakeRetry; i++ { var err error By("create the container") container.Create() By("check the container status") for start := time.Now(); time.Since(start) < ContainerStatusRetryTimeout; time.Sleep(ContainerStatusPollInterval) { if err = checkContainerStatus(); err == nil { </ins> break } <del> if i < flakeRetry { framework.Logf("No.%d attempt failed: %v, retrying...", i, err) } else { framework.Failf("All %d attempts failed: %v", flakeRetry, err) } </del> } <del> }) </del> <ins> By("delete the container") container.Delete() if err == nil { break } if i < flakeRetry { framework.Logf("No.%d attempt failed: %v, retrying...", i, err) } else { framework.Failf("All %d attempts failed: %v", flakeRetry, err) } } </ins> } <ins> It("should not be able to pull image from invalid registry [NodeConformance]", func() { image := "invalid.com/invalid/alpine:3.1" imagePullTest(image, false, v1.PodPending, true) }) It("should not be able to pull non-existing image from gcr.io [NodeConformance]", func() { image := "k8s.gcr.io/invalid-image:invalid-tag" imagePullTest(image, false, v1.PodPending, true) }) // TODO(claudiub): Add a Windows equivalent test. It("should be able to pull image from gcr.io [LinuxOnly] [NodeConformance]", func() { image := "gcr.io/google-containers/debian-base:0.4.1" imagePullTest(image, false, v1.PodRunning, false) }) It("should be able to pull image from docker hub [LinuxOnly] [NodeConformance]", func() { image := "alpine:3.7" imagePullTest(image, false, v1.PodRunning, false) }) It("should be able to pull image from docker hub [WindowsOnly] [NodeConformance]", func() { framework.SkipUnlessNodeOSDistroIs("windows") image := "e2eteam/busybox:1.29" imagePullTest(image, false, v1.PodRunning, false) }) It("should not be able to pull from private registry without secret [NodeConformance]", func() { image := "gcr.io/authenticated-image-pulling/alpine:3.7" imagePullTest(image, false, v1.PodPending, true) }) It("should be able to pull from private registry with secret [LinuxOnly] [NodeConformance]", func() { image := "gcr.io/authenticated-image-pulling/alpine:3.7" imagePullTest(image, true, v1.PodRunning, false) }) </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 What happened: Table-based e2e tests are not getting updated to leading to the following error- ( mentioned in ) framework.ConformanceIt() requires the first parameter to be and are associated with at runtime based on different cases/test-scenarios. What you expected to happen: Either disapprove the use of table-based e2e tests or suggestion on an alternative approach to add such tests to Conformance. How to reproduce it (as minimally and precisely as possible): framework.ConformanceIt() to . /area conformance cc
/sig testing
/cc
Approaches to work around this: wrap the whole table based test in a ConformanceIt block refactor to a more boilerplate approach that has a ConformanceIt block for each table entry update the conformance test walker to detect table based tests that use a well known field?
Thanks I am evaluating these approaches especially on "conformance test walker" to retrieve well-known fields like and variables used inside .
Does this close if closes or are there other tests that need to transition?
This issue would be No other e2e test needs the transition from table-based test structure. Though "only one" remaining test should be restructured as an individual test.
/close Closing as per other fruitful approach and efforts would be taken to refactor table-based tests into individual tests wherever needed.
Closing this issue. <detailsIn response to : /close Closing as per other fruitful approach and efforts would be taken to refactor table-based tests into individual tests wherever needed. 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: h := w.Header() // trigger the timeout cancel() <del> // mutate response Headers for j := 0; j < 1000; j++ { h.Set("Test", "post") </del> <ins> // keep mutating response Headers until the request times out for { select { case <-postTimeoutCh: return default: h.Set("Test", "post") } </ins> } }), func(req *http.Request) (*http.Request, bool, func(), *apierrors.StatusError) { <del> return req, false, func() {}, apierrors.NewServerTimeout(schema.GroupResource{Group: "foo", Resource: "bar"}, "get", 0) </del> <ins> return req, false, func() { close(postTimeoutCh) }, apierrors.NewServerTimeout(schema.GroupResource{Group: "foo", Resource: "bar"}, "get", 0) </ins> }, ), ),

Unit test in package flakes there is a race condition between the go routine that executes the request handler and the timeout go routine that waits for the handler to finish /sig api-machinery
/assign
I have a PR in the works
should fix it, I can easily reproduce it with the PR, the flake is not reproducible any more cc
/triage accepted


Question: }) } <ins> func describeContainers(containers []api.ContainerStatus, out io.Writer) { for _, container := range containers { fmt.Fprintf(out, "  %v:n", container.Name) fmt.Fprintf(out, "    Image:t%sn", container.Image) switch { case container.State.Running != nil: fmt.Fprintf(out, "    State:tRunningn") fmt.Fprintf(out, "      Started:t%vn", container.State.Running.StartedAt.Time.Format(time.RFC1123Z)) case container.State.Waiting != nil: fmt.Fprintf(out, "    State:tWaitingn") if container.State.Waiting.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", container.State.Waiting.Reason) } case container.State.Termination != nil: fmt.Fprintf(out, "    State:tTerminatedn") if container.State.Termination.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", container.State.Termination.Reason) } if container.State.Termination.Message != "" { fmt.Fprintf(out, "      Message:t%sn", container.State.Termination.Message) } fmt.Fprintf(out, "      Exit Code:t%dn", container.State.Termination.ExitCode) if container.State.Termination.Signal > 0 { fmt.Fprintf(out, "      Signal:t%dn", container.State.Termination.Signal) } fmt.Fprintf(out, "      Started:t%sn", container.State.Termination.StartedAt.Time.Format(time.RFC1123Z)) fmt.Fprintf(out, "      Finished:t%sn", container.State.Termination.FinishedAt.Time.Format(time.RFC1123Z)) default: fmt.Fprintf(out, "    State:tWaitingn") } fmt.Fprintf(out, "    Ready:t%vn", printBool(container.Ready)) fmt.Fprintf(out, "    Restart Count:t%dn", container.RestartCount) } } func printBool(value bool) string { if value { return "True" } return "False" } </ins> // ReplicationControllerDescriber generates information about a replication controller // and the pods it has created. type ReplicationControllerDescriber struct {

Kubectl describe pods id only has top level pod information, without any information related to containers. Taking kube-dns pod as an example, which has 3 containers specified: If a pod with RestartAlways policy, but all contianers are in crashloop, the user cannot interpret the true state based on above information. Proposed to include ContainerStatus here.
Why isn't this redundant with ?
is for kubectl get pods id.


Question: Kubernetes currently supports two objects that use label selectors to keep track of their members, `service`s and `replicationController`s: - `service`: A service is a configuration unit for the proxies that run on every worker node.  It is named and points to one or more pods. <del> - `replicationController`: A replication controller takes a template and ensures that there is a specified number of "replicas" of that template running at any one time.  If there are too many, it'll kill some.  If there are too few, it'll start more. </del> <ins> - `replicationController`: A [replication controller](replication-controller.md) ensures that a specified number of pod "replicas" are running at any one time.  If there are too many, it'll kill some.  If there are too few, it'll start more. </ins> The set of pods that a `service` targets is defined with a label selector. Similarly, the population of pods that a `replicationController` is monitoring is also defined with a label selector.

Currently replication controllers define an exact value. Are there disadvantages to allowing the replication controller to define more of a policy - at least X, at most X, exactly X? Since replication controllers aren't really aware of overlapping sets, I guess you can't really use that to guide allocation between two pools because they would just end up fighting unproductively
What is the use case? This seems sort of like auto-scaling policy. I'd prefer to put those objects in the auto-scaler.
It sounds like you want a canary-controller that scales the old version down while scaling the new one up. Combine with a service that spreads traffic across both versions and this should Just Work (tm).
I'm thinking about this from the mechanics of doing a deployment by composing replication controllers. With controllers as they are today: existing replication controller with old template, name=foo,deployment=1 x5 create new replication controller with new template, name=foo,deployment=2 x0 alter controller 2 to be x1 (or up by the batch size) alter controller 1 to be x4 (or down by the batch size) ... repeat until done delete controller 1 The thought around atLeast was about explicitly representing the invariant you want during an available deployment: existing replication controller with old template, name=foo,deployment=1 x5 create new replication controller with new template, name=foo, atLeast=5 set controller to be atMost=5 delete a pod from the name=foo,deployment=1 query ... continue until 0 pods in that query delete controller 1 update controller 2 to change the label query to name=foo,deployment=2 I'm not sure that's better.... just the for loop for deletes seems more reasonable. Not a huge deal, just trying to work through how we'd model common deploy cases for end users.
Overlapping replicationController sets: I think we should validate that this isn't possible upon creation of a replicationController. We can do this by determining whether the label selector may overlap with any others, though to do this analytically without looking at the combinations of labels attached to pods it requires that all replicationController label selectors have at least one key in common, with a different value than all other replicationControllers. Policy: As mentioned, we intended the policy to go in a separate auto-scaling policy entity, in a higher-level layer / separate component.

Deployment: As pointed out, it is possible to create a new replicationController and gradually scale it up while scaling the original down. Or, one could do the Asgard trick of creating a new replicationController and then shift traffic to it. It's possible to add/remove instances from a service by tweaking their labels. For instance one could toggle the value of an in_service=true/false label. The update demo changes the template of a single replication controller and then kills instances one by one until they all get replaced. I don't like that due to the risk of unpredictable replacements and complexity involved with rollbacks. Splitting out the template ( ) would address the rollback issue, but not the unpredictability. It seems to me that the atMost approach suffers from the same risk. That said, I see what you mean that atLeast/atMost are not auto-scaling policies, but are invariants to maintain. I could imagine that flexibility could be useful. For example, a worker pool manager could use that to opportunistically request resources, where some pod requests may fail. Or, perhaps in the case that we need to temporarily create a new pod for some reason (CRIU-based migration?) but we don't want an old one to be killed. So, I like the idea, just not the use case. :-) FWIW, exactly X could be implemented by combining atLeast and atMost.
Agree that without a kill policy on the replication controller the uses cases described don't work. Is a kill policy something you've discussed for the replication controller (oldest, ones that don't match my template first, ones on most overloaded systems)?
I agree that kill policy would be useful and all of the policies you mention are reasonable in particular scenarios. However, I see this as a rich, unbounded policy space, much like scheduling. IIRC, Joe and/or Brendan proposed kill policies early on and I asked for them to be removed. Instead, I propose that we leave the default policy entirely up to the system, much like scheduling, so we can take as many factors into account as we like, and otherwise I'd like to enable the user to implement an arbitrary policy using event hooks . For instance, I could imagine POSTing to a URL whenever a pod needed to be killed.

The user's hook would have N seconds to respond (perhaps configurable), after which the replication controller would kill its default choice.
Thanks for the clarification - I think I'll close this for now until the API stabilizes, and then add some of this context to the doc.
I suggest re-opening this issue, but change the title to "add XXX context to doc YYY", so that we can reference in the PR for posterity.


Question: }) } } <ins> func TestValidatePodController(t *testing.T) { testName, testNamespace := "testname", "default" objMetadata := metav1.ObjectMeta{Name: testName, Namespace: testNamespace, Labels: map[string]string{"foo": "bar"}} // One of the pod-template objects goodDeploy := appsv1.Deployment{ ObjectMeta: objMetadata, Spec: appsv1.DeploymentSpec{ Selector: &metav1.LabelSelector{MatchLabels: map[string]string{"foo": "bar"}}, Template: corev1.PodTemplateSpec{ ObjectMeta: objMetadata, Spec: corev1.PodSpec{ RuntimeClassName: pointer.String("containerd"), }, }, }, } badDeploy := appsv1.Deployment{ ObjectMeta: objMetadata, Spec: appsv1.DeploymentSpec{ Selector: &metav1.LabelSelector{MatchLabels: map[string]string{"foo": "bar"}}, Template: corev1.PodTemplateSpec{ ObjectMeta: objMetadata, Spec: corev1.PodSpec{ SecurityContext: &corev1.PodSecurityContext{ // out of allowed sysctls to return auditAnnotation or warning Sysctls: []corev1.Sysctl{{Name: "unknown", Value: "unknown"}}, }, RuntimeClassName: pointer.String("containerd"), }, }, }, } // Ensure that under the baseline policy, // the pod-template object of all tests returns correct information or is exempted nsLabels := map[string]string{ api.EnforceLevelLabel: string(api.LevelBaseline), api.WarnLevelLabel:    string(api.LevelBaseline), api.AuditLevelLabel:   string(api.LevelBaseline), } testCases := []struct { desc                 string exemptNamespaces     []string exemptRuntimeClasses []string exemptUsers          []string // request subresource subresource string // for create newObject runtime.Object // for update oldObject runtime.Object gvr       schema.GroupVersionResource expectWarnings         []string expectAuditAnnotations map[string]string }{ { desc:        "subresource(status) updates don't produce warnings", subresource: "status", newObject:   &badDeploy, oldObject:   &goodDeploy, gvr:         schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}, }, { desc:             "namespace in exemptNamespaces will be exempted", newObject:        &badDeploy, gvr:              schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}, exemptNamespaces: []string{testNamespace}, }, { desc:                 "runtimeClass in exemptRuntimeClasses will be exempted", newObject:            &badDeploy, gvr:                  schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}, exemptRuntimeClasses: []string{"containerd"}, }, { desc:        "user in exemptUsers will be exempted", newObject:   &badDeploy, gvr:         schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}, exemptUsers: []string{"testuser"}, }, { desc:      "podMetadata == nil && podSpec == nil will skip verification", newObject: &corev1.ReplicationController{ObjectMeta: metav1.ObjectMeta{Name: "foo-rc"}}, gvr:       schema.GroupVersionResource{Group: "", Version: "v1", Resource: "replicationcontrollers"}, }, { desc:                   "good deploy creates and produce nothing", newObject:              &goodDeploy, gvr:                    schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}, expectAuditAnnotations: map[string]string{}, }, { desc:                   "bad deploy creates produce correct user-visible warnings and correct auditAnnotations", newObject:              &badDeploy, gvr:                    schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}, expectAuditAnnotations: map[string]string{"audit": "forbidden sysctls (unknown)"}, expectWarnings:         []string{"would violate "latest" version of "baseline" PodSecurity profile: forbidden sysctls (unknown)"}, }, { desc:                   "bad spec updates don't block on enforce failures and returns correct information", newObject:              &badDeploy, oldObject:              &goodDeploy, gvr:                    schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}, expectAuditAnnotations: map[string]string{"audit": "forbidden sysctls (unknown)"}, expectWarnings:         []string{"would violate "latest" version of "baseline" PodSecurity profile: forbidden sysctls (unknown)"}, }, } for _, tc := range testCases { t.Run(tc.desc, func(t *testing.T) { var operation = admissionv1.Create if tc.oldObject != nil { operation = admissionv1.Update } attrs := &AttributesRecord{ testName, testNamespace, tc.gvr, tc.subresource, operation, tc.newObject, tc.oldObject, "testuser", } defaultPolicy := api.Policy{ Enforce: api.LevelVersion{Level: api.LevelPrivileged, Version: api.LatestVersion()}, Audit:   api.LevelVersion{Level: api.LevelPrivileged, Version: api.LatestVersion()}, Warn:    api.LevelVersion{Level: api.LevelPrivileged, Version: api.LatestVersion()}, } podLister := &testPodLister{} evaluator, err := policy.NewEvaluator(policy.DefaultChecks()) assert.NoError(t, err) nsGetter := &testNamespaceGetter{ ns: &corev1.Namespace{ ObjectMeta: metav1.ObjectMeta{ Name:      testName, Namespace: testNamespace, Labels:    nsLabels}}, } PodSpecExtractor := &DefaultPodSpecExtractor{} a := &Admission{ PodLister:        podLister, Evaluator:        evaluator, PodSpecExtractor: PodSpecExtractor, Configuration: &admissionapi.PodSecurityConfiguration{ Exemptions: admissionapi.PodSecurityExemptions{ Namespaces:     tc.exemptNamespaces, RuntimeClasses: tc.exemptRuntimeClasses, Usernames:      tc.exemptUsers, }, }, defaultPolicy:   defaultPolicy, NamespaceGetter: nsGetter, } result := a.ValidatePodController(context.TODO(), attrs) // podContorller will not return an error due to correct evaluation resultError := "" if result.Result != nil { resultError = result.Result.Message } assert.Equal(t, true, result.Allowed) assert.Empty(t, resultError) assert.Equal(t, tc.expectAuditAnnotations, result.AuditAnnotations, "unexpected AuditAnnotations") assert.Equal(t, tc.expectWarnings, result.Warnings, "unexpected Warnings") }) } } </ins>

Tasks: [ ] status updates don't produce warnings [ ] spec updates don't block on enforce failures [ ] spec updates produce correct user-visible warnings
I want to do this and consult at slack.
/assign


Question: attribute.Stringer("accept", &lazyAccept{req: req}), attribute.Stringer("audit-id", &lazyAuditID{req: req}), attribute.Stringer("client", &lazyClientIP{req: req}), <ins> attribute.Stringer("api-group", &lazyAPIGroup{req: req}), attribute.Stringer("api-version", &lazyAPIVersion{req: req}), attribute.Stringer("name", &lazyName{req: req}), attribute.Stringer("subresource", &lazySubresource{req: req}), attribute.Stringer("namespace", &lazyNamespace{req: req}), </ins> attribute.String("protocol", req.Proto), attribute.Stringer("resource", &lazyResource{req: req}), attribute.Stringer("scope", &lazyScope{req: req}),

Feedback originally provided on slack: It would be helpful to have additional fields on APIServer spans. This is the current set of attributes we provide: It would be helpful to add: group, version, namespace, name, and subresource, if possible. Part of
/sig instrumentation /sig apimachinery /priority important-longterm cc /triage accepted
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrumentation /sig apimachinery /priority important-longterm cc /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api-machinery
/assign


Question: fmt.Fprintf(out, "%sn", r.Name) return nil }) <ins> checkErr(err) </ins> if found == 0 { <del> glog.V(2).Infof("No resource(s) found") </del> <ins> fmt.Fprintf(cmd.Out(), "No resources foundn") </ins> } }, }

We should support multiple objects on the command line, but, failing that, some kind of error message would be useful. /cc
Fixing, just fixed the equiv in create


Question: adc.addNodeToDswp(node, types.NodeName(node.Name)) } } <del> return nil </del> <ins> err = adc.processVolumeAttachments() if err != nil { klog.Errorf("Failed to process volume attachments: %v", err) } return err </ins> } func (adc *attachDetachController) getNodeVolumeDevicePath(

<!-- 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: Background: The attach/detach controller create objects for CSI Volumes to indicate that a volume needs to be attached to a node. It deletes the object to indicate that the volume should be detached. Problem: If the Attach/Detach controller crashes, and in the meantime the pod using that volume is deleted, when the AD controller restarts, it won't know that the volume was previously attached and should be cleaned up. What you expected to happen: Proposal: We should have the AD controller periodically list all objects and for any that are not accounted for, update its internal actual/desired state caches so that the volume is gracefully detached. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig storage 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:
could I take it?
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available .

If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/lifecycle frozen /reopen
Reopened this issue. <detailsIn response to : /lifecycle frozen /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
/assign
should address this


Question: err: testCase.updateErr, }, containerMap:      containermap.NewContainerMap(), <del> activePods:        func() []*v1.Pod { return nil }, </del> podStatusProvider: mockPodStatusProvider{}, <ins> sourcesReady:      &sourcesReadyStub{}, </ins> } pod := makePod("fakePod", "fakeContainer", "2", "2") container := &pod.Spec.Containers[0] <ins> mgr.activePods = func() []*v1.Pod { return []*v1.Pod{pod} } </ins> err := mgr.Allocate(pod, container) if !reflect.DeepEqual(err, testCase.expAllocateErr) { t.Errorf("CPU Manager Allocate() error (%v). expected error: %v but got: %v",

What happened: A container which had exclusive CPUs assigned to it (and an entry in /var/lib/kubelet/cpumanagerstate specifying those CPUs) was killed. When it came back, it was using the default cpuset, and its entry in /var/lib/kubelet/cpumanagerstate was gone. What you expected to happen: It should have been given exclusive CPUs. How to reproduce it (as minimally and precisely as possible): Create a pod/container with "guaranteed" QoS. Determine the exclusive CPUs allocated to the container. From the host, kill pid1 within the container. ("kill -9" works.) The container will restart within the existing pod, but it will be allocated cpus from the default cpuset (which will now include the CPUs that had been exclusively allocated to the container earlier). Anything else we need to know?: I some instrumentation to kubelet. What seems to be happening is this: 1) The container is killed (or dies). Kubelet then immediately creates a new container and calls PolicyStatic.Allocate() to allocate exclusive CPUs for it. This updates the entry in /var/lib/kubelet/cpumanagerstate (and the in-memory cache) which is mapped by podUID and container name, such that it contains the cpuset for the new container. 2) The InternalContainerLifecycle.PostStopContainer() code runs, which calls i.cpuManager.RemoveContainer(containerID). This uses the containerID of the exited container to look up the podUID/container-name tuple, then deletes the cpuset entry from /var/lib/kubelet/cpumanagerstate (and the in-memory cache). But the entry that was deleted was actually the one for the new container. 3) Kubelet calls the CPU manager's AddContainer() function, which calls m.state.GetCPUSetOrDefault(string(p.UID), c.Name) to get the cpuset based on the podUID and container name of the new container. The cpuset entry was erroneously deleted, so this returns the default cpuset, and the container which should have gotten exclusive CPUs ends up running on the default cpuset. An solution suggested by is to delay calling cpuManager.RemoveContainer() until the whole pod is deleted. This would preserve the CPU allocations.

An alternate solution also suggested by is to avoid calling cpuManager.RemoveContainer() from the container lifecycle code, but instead call removeStaleState() in the CpuManager.Allocate() function. Environment: Kubernetes version (use ): 1.18.1 Cloud provider or hardware configuration: x86, SMP OS (e.g: ): CentOS 7 Kernel (e.g. ): 3.10.0-1062.1.2.rt56.1025.el7
/sig sig-node
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-node Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
Considering the following change based on discussion over Slack with
Sorry that bother you via this close issue, but I was tracing back to this issue via the PR. As per your statement above, if I understand correctly, this problem only happened when the container inside Pod got killed. but an simple Pod restarted (e.g. delete/re-create via kubectl delete pod command) should not trigger the problem, right? Or any container(inside Pod) or Pod restart with guaranteed Qos will trigger this issue?


Question: name: "v1.List in order", obj: &corev1.List{ Items: []runtime.RawExtension{ <del> {Raw: encodeOrDie(a)}, {Raw: encodeOrDie(b)}, {Raw: encodeOrDie(c)}, </del> <ins> {Object: a, Raw: encodeOrDie(a)}, {Object: b, Raw: encodeOrDie(b)}, {Object: c, Raw: encodeOrDie(c)}, </ins> }, }, sort: &corev1.List{ Items: []runtime.RawExtension{ <del> {Raw: encodeOrDie(a)}, {Raw: encodeOrDie(b)}, {Raw: encodeOrDie(c)}, </del> <ins> {Object: a, Raw: encodeOrDie(a)}, {Object: b, Raw: encodeOrDie(b)}, {Object: c, Raw: encodeOrDie(c)}, </ins> }, }, field: "{.metadata.name}",

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: seems to have regressed in v1.13.0 and no longer sorts by creation timestamp. What you expected to happen: should sort by creation timestamp. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: N/A Environment: Kubernetes version (use ): <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
/assign
bisected to () /assign
opened to fix
/assign


Question: ```bash SOURCE_DATE_EPOCH=$(git show -s --format=format:%ct HEAD) <del> ``` </del>  No newline at end of file <ins> ``` </ins>

I spent quite a while figuring out how to build the docker images for k8s, when I finally succeeded, the build process told me the images are deleted. I was quite puzzled: After I built the images again. only to receive the same message, I started digging, and I found out that the images are exported with . I think a notification where the images are found would be useful. If you do it a couple of times you remember this, but for newcomers or the occasional contributor this can be very frustrating. A log message I'm happy to submit a PR, if you think this is useful.
FWIW all output goes under , I think we should ensure this is sufficiently documented at least.
It took me a while to find this. Also, I tried using the scripts directly without much success. The makefile is much more helpful. It might be worth mentioning that in the linked document.
i had the same problem
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 /help /triage accepted /kind documentation /retitle document _output directory though also a log message might be good? thing is where to stick it, we have a lot of variations on building that won't pass through the same codepaths ... IMO this absolutely ought to be documented at the very least
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle stale /help /triage accepted /kind documentation /retitle document _output directory though also a log message might be good? thing is where to stick it, we have a lot of variations on building that won't pass through the same codepaths ... IMO this absolutely ought to be documented at the very least 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
to begin with, I only a note about the location of the build artifacts.

The is referenced already in many places in the developer guide. Maybe it is better to completely remove the mentioning of manual invocation of the individual scripts and instead recommend the specific make target? IMHO, this is more consistent with the rest of the documentation. However, it is definitely out of scope here. If you or other dev's think it is a good idea, I can submit another PR for that.
completely remove the mentioning of manual invocation of the individual scripts and instead recommend the specific make target? Generally I think this is true, but there are some specific scripts in the repo where it can make sense to just invoke them directly and a few that are not in the makefile at all (like ) so it doesn't necessarily apply to everything, but I'd agree it generally applies to building at least. And I think that it would be good to make this more consistent
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]:
Ping. Can this be merged?
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]:
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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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: return nil, err } <ins> systemUUID, err := getSystemUUID() if err != nil { return nil, err } </ins> return &cadvisorapi.MachineInfo{ NumCores:       runtime.NumCPU(), MemoryCapacity: p.nodeInfo.memoryPhysicalCapacityBytes, MachineID:      hostname, <ins> SystemUUID:     systemUUID, </ins> }, nil }

<!-- 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: The windows kubelet does not set .status.nodeInfo.systemUUID on the node object. What you expected to happen: The windows kubelet sets the systemUUID from How to reproduce it (as minimally and precisely as possible): Start the windows kubelet and check for UUID: Anything else we need to know?: This will affect users running the out-of-tree vsphere CCM since that depends on the systemUUID, unlike the in-tree version. Also, looks like cAdvisor is the component responsible for providing the systemUUID so let me know if this issue needs to be moved to that repo. Environment: Kubernetes version (use ): Verified on 1.13.1 and 1.14 Cloud provider or hardware configuration: None OS (e.g: ): Windows Server 2019
/sig windows /sig vmware
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


Question: # To bump the Zeppelin version, bump the version in # zeppelin/Dockerfile and bump this tag and reset to v1. <del> ZEPPELIN_TAG = v0.5.5_v1 </del> <ins> ZEPPELIN_TAG = v0.5.5_v2 </ins> spark: docker build -t gcr.io/google_containers/spark-base base

The image by is over a gig. Investigate how to trim this down. (Cut out interpretters? Make them more modular somehow, possibly composing them once we have some solution like ?) It's not even clear there's upstream support for making this more modular, though.
cc
remove mvn tooling and all the extra steps, once upstream releases 's like the rest of apache.
I can look at that, but I think I can actually just strip the image of the dev tooling right now. Right now I think the Zeppelin deps themselves are a ridiculous portion of this, though. (I'll poke at it.)
(3) is an install of [bzr git mercurial openssh-client subversion] in the base java image, which seems wasteful to me. you'll have to switch base images to get rid of this. (2) is your install of [curl net-tools build-essential git wget unzip python python-setuptools python-dev python-numpy libfontconfig]. i expect curl is at least redundant, as is git if your using the java image. you should merge this layer w/ (1) and do an uninstall of [python-setuptools python-dev etc] & deps at the end. of course, those are less significant than (1), which is the mvn build. the long term solution here is to use the upstream binaries, when they exist. in the meantime, you should clone zeppelin into tmp, copy out the resulting build artifact and delete the clone. that should at least cut the size of this layer in half, as all the intermediate build artifacts are likely still present and in the final tarball/jar.
I can trim it down some by cutting out the build machinery (and I'll put up a PR shortly), but here's what the looks like: And expanded: (Instead of just deleting, it's actually easy to build, copy out, compose, too.)
Is it me or are all the containers rather large. For example, does spark itself need to be a gig? 1.5.1v3 6 weeks ago 989.7 MB There's some spark binary package that's 73M uncompressed:
Java runtime + baseimage + transitive closer is what is causing most of the bloat. But as we have discussed on other tickets, these images need to move out of the main repository.

I'm afraid I don't understand "transitive closer". For example I see my JDK is around 280M, and the Spark binary is 73M. Then that leaves another 636M for base + whatever. I guess I'll have to look at the imagelayers if I'm really curious.
he means all the dependencies and their dependencies. if you'd like to tackle shrinking the spark image, please open an issue for it. we've done some work on this and you can use the example investigation above to help improve image sizes.