Question: API_PORT=8080 KUBELET_PORT=10250 <ins> GO_OUT=$(dirname $0)/../output/go </ins> <del> $(dirname $0)/../output/go/apiserver  </del> <ins> APISERVER_LOG=/tmp/apiserver.log ${GO_OUT}/apiserver  </ins> --address="127.0.0.1"  --port="${API_PORT}"  --etcd_servers="http://127.0.0.1:4001"  <del> --machines="127.0.0.1" &> /tmp/apiserver.log & </del> <ins> --machines="127.0.0.1" &> ${APISERVER_LOG} & </ins> APISERVER_PID=$! <del> $(dirname $0)/../output/go/controller-manager  </del> <ins> CTLRMGR_LOG=/tmp/controller-manager.log ${GO_OUT}/controller-manager  </ins> --etcd_servers="http://127.0.0.1:4001"  <del> --master="127.0.0.1:${API_PORT}" &> /tmp/controller-manager.log & </del> <ins> --master="127.0.0.1:${API_PORT}" &> ${CTLRMGR_LOG} & </ins> CTLRMGR_PID=$! <del> $(dirname $0)/../output/go/kubelet  </del> <ins> KUBELET_LOG=/tmp/kubelet.log ${GO_OUT}/kubelet  </ins> --etcd_servers="http://127.0.0.1:4001"  --hostname_override="127.0.0.1"  --address="127.0.0.1"  <del> --port="$KUBELET_PORT" &> /tmp/kubelet.log & </del> <ins> --port="$KUBELET_PORT" &> ${KUBELET_LOG} & </ins> KUBELET_PID=$! <del> echo "Local Kubernetes cluster is running. Press enter to shut it down." read unused kill ${APISERVER_PID} kill ${CTLRMGR_PID} kill ${KUBELET_PID} kill ${ETCD_PID} </del> <ins> echo "Local Kubernetes cluster is running. Press Ctrl-C to shut it down." echo "Logs: " echo "  ${APISERVER_LOG}" echo "  ${CTLRMGR_LOG}" echo "  ${KUBELET_LOG}" cleanup() { echo "Cleaning up..." kill ${APISERVER_PID} kill ${CTLRMGR_PID} kill ${KUBELET_PID} kill ${ETCD_PID} rm -rf ${ETCD_DIR} exit 0 } trap cleanup EXIT while true; do read x; done </ins>

For structured logging migration we have developed a tool to klog invocations For a given directory logcheck validates two things: directory is fully migrated - check if there are non-structured logging calls like usage of and is correct - check if key values passed are paired. We run logcheck as part of Kubernetes verify scripts on directories listed in Directories listed in are marked as migrated to avoid regressions from organized migration, however there are also other code locations that already use new functions that are not yet ready to be marked as migrated (components that are not part of organized migrations are done as best effort). We should split checking if directory was migrated from correctness of new functions and scan whole codebase for correctness. Plan: Add a flag to logcheck for requiring that directory was migrated. Add to verify-strucured- running logcheck of whole k/k codebase to check correctness This will ensure higher quality of migration PRs by validating correctness of directories that were not yet in .structuredlogging /wg structured-logging /cc
I'd like to pick this up. Do I need to wait till it is triage/accepted?
/triage accepted
Feel free to pick it up :P Usually I don't want to self triage, but this issue is purely Structured Logging WG related.
/assign
[Case 2: Correct usage] If the directory is not marked as migrated, we check that it's usage of is correct and don't care about usage of . By default, CI will test for correctness of whole k/k codebase instead of testing for complete migration (which is the current behavior). And to test for migration, a new flag must be passed explicitly. is this the expectation?
To clarify, let me rephrase. Current state is What we want: [Case 2: Correct usage] tested on whole repository
If this is the case, I can start implementing it.
SG, thanks for the help.
/milestone v1.22 Part of work go graduate Structured Logging KEP to beta.
I don't think work here has finished. We still need to implement those changes in k/k repo: Cut new klog Bump klog in k/k Update the script ./hack/verify-structured- /reopen
Reopened this issue. <detailsIn response to : I don't think work here has finished.

We still need to implement those changes in k/k repo: Update the script /reopen </details
Why do we need to cut a new klog and bump in k/k? Can't we make latest logcheck available to k/k without it? I don't know the process.
Hmm, We could try without updating to update. Please send PR that will update ./hack/verify-structured- If updating klog is nesesery feel free to contact for help
If we do both, we'd have to run logcheck twice (with and without flag) which means test time will increase.
This depends on implementation, increasing running time is ok as long it's reasonable, for example x1.5, but not x10.
Due to v1.22 code freeze, I'm moving this issue to the next release. /milestone v1.23
We would like to have static analysis setup before we start migrating logs in 1.23. will you be able to work on it this week? Do you need any help?
Yes, I can. PR kubernetes/kubernetes/pull/ is up for enabling static analysis. It has some unresolved conversations. It'd be helpful if I could get another round of review on that PR. Before we merge that we'd need to fix existing logging issues which are listed here: If I could get help fixing those it'd be great. Else I can fix it too.
I see two issues that need to be addressed: Fix handling of in klog code, this should be done by creating an issue to klog () Fix remaining errors Upgrade klog version to pick up fix for Exit


Question: - --source=kubernetes.summary_api:'' - --sink=influxdb:http://monitoring-influxdb:8086 - --sink=gcm:?metrics=autoscaling <del> - image: gcr.io/google_containers/heapster-amd64:v1.5.0-beta.0 </del> <ins> - image: gcr.io/google_containers/heapster-amd64:v1.5.0-beta.1 </ins> name: eventer command: - /eventer

I also hit when running cri-containerd as the container runtime. The reason is that we don't populate stats like in cri-containerd integration now. is adding the containerd support in cadvisor, after that we should have full summary metrics. However, heapster should not panic in this case anyway. Can we cut a heapster patch release and update heapster in the main repo?
+1. Many new CRI integration would run into this issue.
In fact, as far as I am aware, not a single CRI implementation currently implements any of the stats calls.
I beg to differ: That's the reason why filed the issue.
Yeah does implement the CRI stats. Currently it only support core metrics, which is only part of summary api. We are working on integration with cadvisor, before that some fields in summary api such as will be nil. Current heapster version will crash when is nil, which shouldn't happen. :)
/cc
My bad, thanks for the pointer :slightlysmilingface:. I'll correct my statement: I believe no CRI implementation except for cri-containerd implements the stats calls. The ones I explicitly checked are: dockershim, cri-o, rktlet.
Something I'm wondering about though: The intention of the stats calls is in order to be able to get rid of cAdvisor. Making the stats calls depend on cAdvisor seems to cover up the issues it has. Re:
Here is the reason that we still have to integrate with cadvisor for now.
/cc
If I understand correctly this is meant as a migration mean, so that both are possible for some time, and then we drop cAdvisor once a reasonable migration period has been granted.
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
I will take a look at Heapster and try to fix this. Can you advise how to reproduce the issue?

This will help a lot with debugging and verifying a fix once it's ready.
this is already fixed at head and 1.4.3 version of heapster The problem that is using kubernetes version from head and we have there 1.5.0-beta.0: I see two possible solutions: version of heapster to 1.4.3 at head of kubernetes. Piotr mentioned that 1.5.0 has still a lot of problems, so it maybe makes sense. a new release of heapster (1.5.0-beta.1) and after that bump version at head.
And thanks for taking this issue.
Not directly related to this issue: a more general discussion is at We'd like to understand which fields are required and optional in heapster, so that we won't crash heapster with partial result.
We've merged a work around for now Hopefully it works. But anyway, we should fix this in 1.9.
what needs to be done for 1.9 here?
we'll need an assignee as well
We just need to update heapster version.


Question: // Kill any running node processes cleanupNodeProcesses(host) <del> testArgs, err := updateOSSpecificKubeletFlags(testArgs, host, workspace) </del> <ins> testArgs, err := osSpecificActions(testArgs, host, workspace) </ins> if err != nil { return "", err }

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: pull-kubernetes-node-crio-e2e Which test(s) are failing: N/A Since when has it been failing: N/A Testgrid link: Reason for failure: Anything else we need to know:
/sig node
/assign


Question: Expect(err).NotTo(HaveOccurred()) if defaultStr == "" { <del> delete(sc.Annotations, storageutil.IsDefaultStorageClassAnnotation) </del> <ins> delete(sc.Annotations, storageutil.BetaIsDefaultStorageClassAnnotation) </ins> } else { if sc.Annotations == nil { sc.Annotations = make(map[string]string) } <del> sc.Annotations[storageutil.IsDefaultStorageClassAnnotation] = defaultStr </del> <ins> sc.Annotations[storageutil.BetaIsDefaultStorageClassAnnotation] = defaultStr </ins> } sc, err = c.StorageV1().StorageClasses().Update(sc)

https://k8s- Failed: [] Dynamic provisioning [] DynamicProvisioner Default should be disabled by removing the default annotation[Slow] [Serial] [Disruptive] [Volume] {Kubernetes e2e suite} Failed: [] Dynamic provisioning [] DynamicProvisioner Default should be disabled by changing the default annotation[Slow] [Serial] [Disruptive] [Volume] {Kubernetes e2e suite}
These test have failed in the last few serial jobs () and may represent a regression. The tests were in by Assigning her to take a look. /assign cc:
CC
The e2e test is using IsDefaultStorageClassAnnotation, which used to equal the beta annotation, but then got changed to use the non-beta annotation. However, the default storage classes that are installed are using the beta annotation. So when the test tries to disable the default storage class by modifying or deleting the annotation, it is trying to use the non-beta annotation which does not exist, so it has no affect, since the the beta annotation is unchanged. So for now, the simple fix should be to make the test modify the beta annotation. I am working on it now and should have a PR out soon. Longer term, the test should be able to detect which annotation is being used and modify the appropriate one.
Looks like this is failing again with a different error: https://k8s-
This should be fixed by
Good to know, I'll leave open until we confirm in e2e
this test went green in the last two e2e's


Question: <ins> // +build linux </ins> /* Copyright 2016 The Kubernetes Authors.

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): master Environment: OS: MacOS Kernel (e.g. ): Darwin Klauss-MacBook- 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASEX8664 x86_64 What happened: Build failed: What you expected to happen: Successfully built How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: N/A
cc , any suggestion?
attempted to fix this error in a recent PR.
I'll take a look. node_e2e should not be built on mac. It's weird.
I checked our cross build, everything is good: Are you sure you are using head? Have your code included
similar issue after , refer to the following output. Is the used to remove node_e2e on Mac? I'll check it and try to fix this issue :).
by running , it will just build everything on the current platform. That's why e2e_node and even other kubelet servers are built on Mac with . The problem is that whether guarantee building on Mac? From , it seems that K8s could build on Mac before. However, broke that.
, are you still working on this ? If not, I'd like to contribute to this one :). Here's what I found recently: The latest build command is: But when I checked , the is not included in it: I'm going to find what happened when build ; it seems is not included on Mac, which triggers this build error. If any comments/suggestion, please let me know.
/ , there's the root cause: the is only built on linux because of build flag (), that makes can not find related functions on Mac.
Yeah, for now we can add in to solve the problem. :) Feel free to fix it if you're interested. :)
, thanks very much; is better than a new file. The PR was updated accordingly ().


Question: // change the reclamation policy of the PV for the next test pv.Spec.PersistentVolumeReclaimPolicy = api.PersistentVolumeReclaimDelete <del> w, _ = testClient.PersistentVolumes().Watch(api.ListOptions{}) </del> <ins> w, err = testClient.PersistentVolumes().Watch(api.ListOptions{}) if err != nil { t.Errorf("Failed to watch PersistentVolumes: %v", err) } </ins> defer w.Stop() <del> _, _ = testClient.PersistentVolumes().Create(pv) _, _ = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) </del> <ins> _, err = testClient.PersistentVolumes().Create(pv) if err != nil { t.Errorf("Failed to create PersistentVolume: %v", err) } _, err = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) if err != nil { t.Errorf("Failed to create PersistentVolumeClaim: %v", err) } </ins> waitForPersistentVolumePhase(w, api.VolumeBound)

PersistentVolume integration tests fail sometimes: There are some interesting reports in the log like: Thans for report.
It turns out that volume integration tests have no logs at all, was not checked and I don't really know what's going on there. adds error checks to help me find out what's wrong there. Still, I suspect there are some troubles with etcd, not related to the test itself.
This flake affects also TestPersistentVolumeMultiPVs:
Extended logging got merged just now, please post links to logs when it breaks again!
Marking as P1 as per
I have no real usable logs, but I think it could be fixed by , it hasn't flaked since it was merged. And I have (in merge queue) to further stabilize the tests.
Not blocking this on 1.3.
It hasn't flaked for almost a month, can we close this?
Closing this issue since previous fixes made the flake go away.


Question: func (az *Cloud) getAzureClientConfig(servicePrincipalToken *adal.ServicePrincipalToken) *azclients.ClientConfig { azClientConfig := &azclients.ClientConfig{ <ins> CloudName:               az.Config.Cloud, </ins> Location:                az.Config.Location, SubscriptionID:          az.Config.SubscriptionID, ResourceManagerEndpoint: az.Environment.ResourceManagerEndpoint,

<!-- Please only use this template for submitting enhancement requests --What would you like to be : PR() already proves that old api-version on Azure stack works on global Azure too, we could support azure stack in azure cloud provider lib, and then make sure following components works in Azure stack: CSI drivers: azure disk, azure file CCM Since it's mainly api-version change, we could also add e2e tests against global Azure too. Why is this needed: /assign /priority important-soon /sig cloud-provider /area provider/azure
there is blocking issue here(also need azure stack supports latest data model struct): just making the change in interfaces and not go-sdk but facing this error, since we don't have a switch inside go-sdk, we only do switch in azure cloud provider lib,
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


Question: <ins> /* Copyright 2019 The Kubernetes Authors. 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 openstack import ( "k8s.io/kubernetes/test/e2e/framework" ) func init() { framework.RegisterProvider("openstack", newProvider) } func newProvider() (framework.ProviderInterface, error) { return &Provider{}, nil } // Provider is a structure to handle OpenStack clouds for e2e testing type Provider struct { framework.NullProvider } </ins>

What happened: When specifying "openstack" as cloud-provider of e2e test, the test is failed like What you expected to happen: We can run e2e test with openstack cloud provider. How to reproduce it (as minimally and precisely as possible): Just kick the following command: ` Anything else we need to know?: This issue doesn't happen on v1.13, so this issue seems to happen during this dev cycle for v1.14. Environment: Kubernetes version (use ): master for v1.14 Cloud provider or hardware configuration: OpenStack OS (e.g: ): Ubuntu 16.04.5 LTS Kernel (e.g. ): 4.4.0-142-generic Install tools: kubeadm Others:
/sig openstack /sig testing
The exception raises at
The reason of this issue comes from
Ideally it is nice to put a new directory for registering the cloud provider.
/assign
I was wondering we could remove "openstack" provider specific tests and conditions from e2e tests, but there are storage tests which are related to OpenStack in e2e tests. So it is nice to add registration for OpenStack at this time.


Question: import ( "net" <ins> "strings" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" )

Since this PR got merged, the ELB e2e test, which was consistently succeeding, is now consistently failing: Revert now that is in, and fix the tests that were relying on it. (details) Commit by arob Revert now that is in, and fix the tests that were relying on it. The file was modified The file was modified The file was modified I'm going to roll it back to confirm.


Question: <ins> /* Copyright 2015 Google Inc. 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 e2e import ( "fmt" "sync" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/fields" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" . "github.com/onsi/ginkgo" . "github.com/onsi/gomega" ) // This test suite can take a long time to run, so by default it is added to // the ginkgo.skip list (see driver.go). // To run this suite you must explicitly ask for it by setting the // -t/--test flag or ginkgo.focus flag. var _ = Describe("Scale", func() { var c *client.Client var minionCount int var RCName string var ns string BeforeEach(func() { var err error c, err = loadClient() expectNoError(err) minions, err := c.Nodes().List(labels.Everything(), fields.Everything()) expectNoError(err) minionCount = len(minions.Items) Expect(minionCount).NotTo(BeZero()) nsForTesting, err := createTestingNS("scale", c) ns = nsForTesting.Name expectNoError(err) }) AfterEach(func() { // Remove any remaining pods from this test if the // replication controller still exists and the replica count // isn't 0.  This means the controller wasn't cleaned up // during the test so clean it up here rc, err := c.ReplicationControllers(ns).Get(RCName) if err == nil && rc.Spec.Replicas != 0 { By("Cleaning up the replication controller") err := DeleteRC(c, ns, RCName) expectNoError(err) } By(fmt.Sprintf("Destroying namespace for this suite %v", ns)) if err := c.Namespaces().Delete(ns); err != nil { Failf("Couldn't delete ns %s", err) } }) type Scalability struct { skip          bool totalPods     int podsPerMinion int rcsPerThread  int } scalabilityTests := []Scalability{ {totalPods: 500, podsPerMinion: 10, rcsPerThread: 5, skip: true}, {totalPods: 500, podsPerMinion: 10, rcsPerThread: 25, skip: true}, } for _, testArg := range scalabilityTests { // # of threads calibrate to totalPods threads := (testArg.totalPods / (testArg.podsPerMinion * testArg.rcsPerThread)) name := fmt.Sprintf( "should be able to launch %v pods, %v per minion, in %v rcs/thread.", testArg.totalPods, testArg.podsPerMinion, testArg.rcsPerThread) if testArg.skip { name = "[Skipped] " + name } itArg := testArg It(name, func() { podsLaunched := 0 var wg sync.WaitGroup wg.Add(threads) // Create queue of pending requests on the api server. for i := 0; i < threads; i++ { go func() { defer GinkgoRecover() defer wg.Done() for i := 0; i < itArg.rcsPerThread; i++ { name := "my-short-lived-pod" + string(util.NewUUID()) n := itArg.podsPerMinion * minionCount expectNoError(RunRC(c, name, ns, "gcr.io/google_containers/pause:go", n)) podsLaunched += n Logf("Launched %v pods so far...", podsLaunched) err := DeleteRC(c, ns, name) expectNoError(err) } }() } // Wait for all the pods from all the RC's to return. wg.Wait() Logf("%v pods out of %v launched", podsLaunched, itArg.totalPods) }) } }) </ins>

The issue is to follow up discussions in : running conformance test with the commonly used tool, sonobuoy, failed because the tool's test runner is lack of permission towards . The original issue was resolved by changing the e2e (conformance) test of to an integration test. Several problems remained: privilege requirement in is outdated. discovery is one of the least-privileged permissions, and is expected to be granted to every authenticated user but is not actually. the result returned by should be part of conformance? 1st and 2nd are straightforward to fix, not sure about 3rd, should we add a separate test or add a verification step in existing one like With the fix of 2nd, e2e for should no longer fail with any test runner. cc - should be reflect the accurate permission requirement discovery permission should be granted to all authenticated users. test should check the result returned by . Inapplicable No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery /sig testing
I agree with this. We have conformance tests around things like webhooks and custom resource definitions. I'd recommend rephrasing that as "limits itself to capabilities exposed via APIs (e.g., does not require root on nodes, access to raw network interfaces) and does not require write access to system namespaces (like kube-system)" I'm not sure I agree with this. No binaries Kubernetes provides (that I'm aware of) and nothing in client-go needs to make use of root discovery information. I'd be very slow to expand endpoints included in . Unless we have compelling reasons for people to use and rely on this data, I would lean towards no.
can we fix 1 , that seems that everybody agree and looks like the most clear one? the other sound more contentious
thanks for your comments. Created for 1 and closed the other one.
Thanks all. Agree on this outcome.
/triage accepted


Question: return } <ins> // Watch returns a watch.Interface that watches the requested pods. func (c *pods) Watch(label, field labels.Selector, resourceVersion string) (watch.Interface, error) { return c.r.Get(). Prefix("watch"). Namespace(c.ns). Resource("pods"). Param("resourceVersion", resourceVersion). SelectorParam("labels", label). SelectorParam("fields", field). Watch() } </ins> // Bind applies the provided binding to the named pod in the current namespace (binding.Namespace is ignored). func (c *pods) Bind(binding *api.Binding) error { return c.r.Post().Namespace(c.ns).Resource("pods").Name(binding.Name).SubResource("binding").Body(binding).Do().Error()

PodInterface should have Watch method behaving in the same way as ServiceInterface.Watch does. Use case: a monitoring system (namely Prometheus) expects to get the list of monitored servers performing a DNS-SD query. Special service (similar to kube2sky shipped with Kubernetes) mirrors status of running Pods into etcd, which is in turn monitored by SkyDNS server and exported as DNS-SD. Schematically the data flow looks like this: Kubernetes -kube2sky -etcd -SkyDNS -Prometheus. The biggest challenge is to deliver list of all running pods from Kubernetes to kube2sky. Currently kube2sky can only poll Kubernetes with PodInterface.List() each N seconds, which is not efficient. Having a Watch method would be much better.
cc Do you know why we do not support watch?
Every object should support Watch.
Watching status doesn't currently work -- that's .
I agree with OP. This is just an accident of history; some boilerplate in the client isn't completely filled out. As Brian mentions, not every field is currently watchable but that's being addressed elsewhere.
This is relevant to your interests potentially w/ your work on
This is a pretty simple change if someone wants to get their feet wet. :)
I'll work on it.


Question: volumeID:     pvSource.VolumeHandle, specVolumeID: spec.Name(), csiClient:    client, <ins> readOnly:     readOnly, </ins> } return mounter, nil }

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The field passed to is never set. In where is a object that is initialized in the method in Notice the field is never set. What you expected to happen: The field should be set to How to reproduce it (as minimally and precisely as possible): Create a CSI volume and set to true. Check the value of in the CSI call. It should be true, but is false. CC Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I think is only used for mounting pod volume path to container, here(for ), we can set to , just like other volume plugins. I can help to fix this.
What about the case when a user wants to mount a volume for one of containers in a POD as read only, but the actual volume has ReadOnly False? I would like to suggest an alternative solution which passes the value of ReadOnly attribute, taken from POD's spec.
Thank you and for jumping on this! I feel like the other volume plugins have the wrong behavior here. The purpose of the call is to mount the volume. Therefore, the should receive the pod volume mount readonly field. That said, as mentioned , I think the fact that " is used for mounting pod volume path to container" might be hiding a bug: that is never set correctly. I haven't had a chance to validate this but my reading of the code suggests that the is never set. But because the container mount uses , even though the plugin did not get the correct readonly value, the mount ends up getting mounted with the correctly readonly value. Thoughts?
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release.

</details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
We discussed the proposed fixes in the Kubernetes CSI implementation meeting today (see ). We decided it would be better for CSI to be consistent with the other plugins (and still broken), and have CSI fixed, along with all the other plugins, whenever we fix the issue (likely post-1.10). Therefore, I will accept fix and we will close Then we can remove the 1.10 tag from this issue and track it independent of the 1.10 release.
Spoke with offline. Details here: Based on that conversation, I don't think there is anything else we need to do here.


Question: }, }, }, <del> NodeName: nodeName, </del> <ins> NodeName: p.NodeName, </ins> }, }) } <ins> func startNewLoggingPod(f *framework.Framework, podName string, nodeName string, totalLines int, loggingDuration time.Duration) *loggingPod { pod := newLoggingPod(podName, nodeName, totalLines, loggingDuration) pod.Start(f) return pod } </ins> func waitForSomeLogs(f *framework.Framework, config *loggingTestConfig) error { podHasIngestedLogs := make([]bool, len(config.Pods)) podWithIngestedLogsCount := 0

Pods should be run in parallel with checking the logs from the backend to fit into the timeout.


Question: flags_completion=() flags+=("--all") <ins> flags+=("--dry-run") </ins> flags+=("--filename=") flags_with_completion+=("--filename") flags_completion+=("__handle_filename_extension_flag json|yaml|yml")

kubectl should support a --dry-run option for every mutation to show what it would do, without actually doing it We might need API changes in order to make this high-fidelity. For instance, if we wanted to know what a pod config would look like after admission control populated defaults, we'd need to execute most of the creation path.
For generator types commands, I think there is a usability argument that the default when a user specifies should be to dry-run (and a user should be allowed to override that with ). I think I'd rather encourage composition of commands (pipe) than every generator command in the system creating objects. We may also want to clarify dry-run against the server vs dry run against the client - there are lots of places where we want to generate locally to a file or an editor or a pipe command before we want to create it. At this point, OpenShift has a few commands that treat -o  as "dry-run" - new-app (complex generator) and export (never expect to send it to the server). We also have a few that are designed to be compositional in a pipe always - process (take a template and turn it into a list of api objects), which never creates the objects for you (you have to pipe to ). I'm somewhat partial to having and support the presence of changing the default of to true, because that's more common and easier than having to set and . The counter argument is that is the preferred action, and is format only - except that by definition --dry-run using the default output format isn't very useful (you created a service named foo and an rc named bar). My gut is that most users once they understand what a particular generator does their default path is always going to be to review the change, and then if they want to create it they can pipe to or just by appending to their existing command. I'm not sure that's a strong enough argument to couple --dry-run and -o, but based on our experience so far it's going to be the "normal" path.
:+1: for this feature. In particular, I would like an ability to validate an object definition separate from actually creating the object. e.g. running at the validation step of my deployment pipeline.
I agree that the validation use case is important. I would distinguish --dry-run from --local.

The former would still entail contacting the server and returning the result of the mutation. The latter would imply that only local information were used.
- I'm planning to add a parameter like 'pretty' or 'labelselector' to API requests. Once the server get this parameter, it will do validation to the resource and check if request can pass admission controls, but return success before write to etcd. I've read the documented about API changing, it lists some principles when changing the api object, but parameters are not mentioned. Is there anything need to be taken special care of when adding a parameter?
We need to be careful about dry-run with admission control... some admission controllers (like quota, specifically), record things to etcd in the process of admitting an object. Also, dry-run wouldn't work with a list of objects intended to be created in order, where later objects reference earlier objects (and those references are validated at create time)
We could potentially carry "dry run" down into the admission controller request path. However, a query parameter may not be appropriate, instead there's probably a HTTP header that already covers this. We try not to mix query parameters and post bodies in many cases. , Jordan Liggitt wrote:
- Thanks for advices! I'm trying to make myself thoroughly familar with request handling process. And during this period, I may need more of your help. I think I've replied this message before but unfortunately it's not showed up here:-( - Can you provide a link to the code about the HTTP header? Thanks!
This feels like a variant of an header with a sub parameter - possibly or possibly content-type . , Victor HU wrote:
+1 for this. My use case is to understand the difference between a stack file and an existing cluster, but this command would be a substitute.
It looks like support for has been . I think this issue can be closed.
We still need to make touch the server, or at least decide that we don't want to.
you mean move server side?
has just released kubeval: From to sig-apps mailing list: I am not sure if it validates the values and other constraints checked on the server-side. Just leaving it here as it might be relevant to the feature discussion. (h/t briangrant for pointing this out).
Issues go stale after 90d of inactivity.

Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
/remove-lifecycle rotten
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
a HTTP header that already covers this. We try not to mix query parameters and post bodies in many cases. Do you remember why you said that? I'm trying to understand ...
should fix this issue, we can close it when the server-side dry-run feature reaches beta. The feature above () will fix this use-case, and even validate against the admission chain. is being built on top of server-side dry-run, and will be a good way to visualize the output of dry-run apply:
This is now beta.


Question: <ins> /* Copyright 2019 The Kubernetes Authors. 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 windows import ( "crypto/tls" "encoding/json" "fmt" "io/ioutil" "net/http" "regexp" "strconv" "time" v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/client-go/kubernetes/scheme" kubeletconfigv1beta1 "k8s.io/kubelet/config/v1beta1" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" "k8s.io/kubernetes/test/e2e/framework" imageutils "k8s.io/kubernetes/test/utils/image" "github.com/onsi/ginkgo" "github.com/onsi/gomega" ) var _ = SIGDescribe("[Feature:Windows] Memory Limits [Serial] [Slow]", func() { f := framework.NewDefaultFramework("memory-limit-test-windows") ginkgo.BeforeEach(func() { // NOTE(vyta): these tests are Windows specific framework.SkipUnlessNodeOSDistroIs("windows") }) ginkgo.Context("Allocatable node memory", func() { ginkgo.It("should be equal to a calculated allocatable memory value", func() { checkNodeAllocatableTest(f) }) }) ginkgo.Context("attempt to deploy past allocatable memory limits", func() { ginkgo.It("should fail deployments of pods once there isn't enough memory", func() { overrideAllocatableMemoryTest(f, 4) }) }) }) type nodeMemory struct { // capacity capacity resource.Quantity // allocatable memory allocatable resource.Quantity // memory reserved for OS level processes systemReserve resource.Quantity // memory reserved for kubelet (not implemented) kubeReserve resource.Quantity // grace period memory limit (not implemented) softEviction resource.Quantity // no grace period memory limit hardEviction resource.Quantity } // runDensityBatchTest runs the density batch pod creation test // checks that a calculated value for NodeAllocatable is equal to the reported value func checkNodeAllocatableTest(f *framework.Framework) { nodeMem := getNodeMemory(f) framework.Logf("nodeMem says: %+v", nodeMem) // calculate the allocatable mem based on capacity - reserved amounts calculatedNodeAlloc := nodeMem.capacity.Copy() calculatedNodeAlloc.Sub(nodeMem.systemReserve) calculatedNodeAlloc.Sub(nodeMem.kubeReserve) calculatedNodeAlloc.Sub(nodeMem.softEviction) calculatedNodeAlloc.Sub(nodeMem.hardEviction) ginkgo.By(fmt.Sprintf("Checking stated allocatable memory %v against calculated allocatable memory %v", &nodeMem.allocatable, calculatedNodeAlloc)) // sanity check against stated allocatable gomega.Expect(calculatedNodeAlloc.Cmp(nodeMem.allocatable)).To(gomega.Equal(0)) } // Deploys `allocatablePods + 1` pods, each with a memory limit of `1/allocatablePods` of the total allocatable // memory, then confirms that the last pod failed because of failedScheduling func overrideAllocatableMemoryTest(f *framework.Framework, allocatablePods int) { const ( podType = "memory_limit_test_pod" ) totalAllocatable := getTotalAllocatableMemory(f) memValue := totalAllocatable.Value() memPerPod := memValue / int64(allocatablePods) ginkgo.By(fmt.Sprintf("Deploying %d pods with mem limit %v, then one additional pod", allocatablePods, memPerPod)) // these should all work pods := newMemLimitTestPods(allocatablePods, imageutils.GetPauseImageName(), podType, strconv.FormatInt(memPerPod, 10)) f.PodClient().CreateBatch(pods) failurePods := newMemLimitTestPods(1, imageutils.GetPauseImageName(), podType, strconv.FormatInt(memPerPod, 10)) f.PodClient().Create(failurePods[0]) gomega.Eventually(func() bool { eventList, err := f.ClientSet.CoreV1().Events(f.Namespace.Name).List(metav1.ListOptions{}) framework.ExpectNoError(err) for _, e := range eventList.Items { // Look for an event that shows FailedScheduling if e.Type == "Warning" && e.Reason == "FailedScheduling" && e.InvolvedObject.Name == failurePods[0].ObjectMeta.Name { framework.Logf("Found %+v event with message %+v", e.Reason, e.Message) return true } } return false }, 3*time.Minute, 10*time.Second).Should(gomega.Equal(true)) } // newMemLimitTestPods creates a list of pods (specification) for test. func newMemLimitTestPods(numPods int, imageName, podType string, memoryLimit string) []*v1.Pod { var pods []*v1.Pod memLimitQuantity, err := resource.ParseQuantity(memoryLimit) framework.ExpectNoError(err) for i := 0; i < numPods; i++ { podName := "test-" + string(uuid.NewUUID()) pod := v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: podName, Labels: map[string]string{ "type": podType, "name": podName, }, }, Spec: v1.PodSpec{ // Restart policy is always (default). Containers: []v1.Container{ { Image: imageName, Name:  podName, Resources: v1.ResourceRequirements{ Limits: v1.ResourceList{ v1.ResourceMemory: memLimitQuantity, }, }, }, }, NodeSelector: map[string]string{ "beta.kubernetes.io/os": "windows", }, }, } pods = append(pods, &pod) } return pods } // getNodeMemory populates a nodeMemory struct with information from the first func getNodeMemory(f *framework.Framework) nodeMemory { selector := labels.Set{"beta.kubernetes.io/os": "windows"}.AsSelector() nodeList, err := f.ClientSet.CoreV1().Nodes().List(metav1.ListOptions{ LabelSelector: selector.String(), }) framework.ExpectNoError(err) // Assuming that agent nodes have the same config // Make sure there is >0 agent nodes, then use the first one for info gomega.Expect(nodeList.Size()).NotTo(gomega.Equal(0)) ginkgo.By("Getting memory details from node status and kubelet config") status := nodeList.Items[0].Status nodeName := nodeList.Items[0].ObjectMeta.Name kubeletConfig, err := getCurrentKubeletConfig(nodeName) framework.ExpectNoError(err) systemReserve, err := resource.ParseQuantity(kubeletConfig.SystemReserved["memory"]) if err != nil { systemReserve = *resource.NewQuantity(0, resource.BinarySI) } kubeReserve, err := resource.ParseQuantity(kubeletConfig.KubeReserved["memory"]) if err != nil { kubeReserve = *resource.NewQuantity(0, resource.BinarySI) } hardEviction, err := resource.ParseQuantity(kubeletConfig.EvictionHard["memory.available"]) if err != nil { hardEviction = *resource.NewQuantity(0, resource.BinarySI) } softEviction, err := resource.ParseQuantity(kubeletConfig.EvictionSoft["memory.available"]) if err != nil { softEviction = *resource.NewQuantity(0, resource.BinarySI) } nodeMem := nodeMemory{ capacity:      status.Capacity[v1.ResourceMemory], allocatable:   status.Allocatable[v1.ResourceMemory], systemReserve: systemReserve, hardEviction:  hardEviction, // these are not implemented and are here for future use - will always be 0 at the moment kubeReserve:  kubeReserve, softEviction: softEviction, } return nodeMem } // getTotalAllocatableMemory gets the sum of all agent node's allocatable memory func getTotalAllocatableMemory(f *framework.Framework) *resource.Quantity { selector := labels.Set{"beta.kubernetes.io/os": "windows"}.AsSelector() nodeList, err := f.ClientSet.CoreV1().Nodes().List(metav1.ListOptions{ LabelSelector: selector.String(), }) framework.ExpectNoError(err) ginkgo.By("Summing allocatable memory across all agent nodes") totalAllocatable := resource.NewQuantity(0, resource.BinarySI) for _, node := range nodeList.Items { status := node.Status totalAllocatable.Add(status.Allocatable[v1.ResourceMemory]) } return totalAllocatable } // getCurrentKubeletConfig modified from test/e2e_node/util.go func getCurrentKubeletConfig(nodeName string) (*kubeletconfig.KubeletConfiguration, error) { resp := pollConfigz(5*time.Minute, 5*time.Second, nodeName) kubeCfg, err := decodeConfigz(resp) if err != nil { return nil, err } return kubeCfg, nil } // Causes the test to fail, or returns a status 200 response from the /configz endpoint func pollConfigz(timeout time.Duration, pollInterval time.Duration, nodeName string) *http.Response { // start local proxy, so we can send graceful deletion over query string, rather than body parameter ginkgo.By("Opening proxy to cluster") cmd := framework.KubectlCmd("proxy", "-p", "0") stdout, stderr, err := framework.StartCmdAndStreamOutput(cmd) framework.ExpectNoError(err) defer stdout.Close() defer stderr.Close() defer framework.TryKill(cmd) buf := make([]byte, 128) var n int n, err = stdout.Read(buf) framework.ExpectNoError(err) output := string(buf[:n]) proxyRegexp := regexp.MustCompile("Starting to serve on 127.0.0.1:([0-9]+)") match := proxyRegexp.FindStringSubmatch(output) gomega.Expect(len(match)).To(gomega.Equal(2)) port, err := strconv.Atoi(match[1]) framework.ExpectNoError(err) ginkgo.By("http requesting node kubelet /configz") endpoint := fmt.Sprintf("http://127.0.0.1:%d/api/v1/nodes/%s/proxy/configz", port, nodeName) tr := &http.Transport{ TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, } client := &http.Client{Transport: tr} req, err := http.NewRequest("GET", endpoint, nil) framework.ExpectNoError(err) req.Header.Add("Accept", "application/json") var resp *http.Response gomega.Eventually(func() bool { resp, err = client.Do(req) if err != nil { framework.Logf("Failed to get /configz, retrying. Error: %v", err) return false } if resp.StatusCode != 200 { framework.Logf("/configz response status not 200, retrying. Response was: %+v", resp) return false } return true }, timeout, pollInterval).Should(gomega.Equal(true)) return resp } // Decodes the http response from /configz and returns a kubeletconfig.KubeletConfiguration (internal type). func decodeConfigz(resp *http.Response) (*kubeletconfig.KubeletConfiguration, error) { // This hack because /configz reports the following structure: // {"kubeletconfig": {the JSON representation of kubeletconfigv1beta1.KubeletConfiguration}} type configzWrapper struct { ComponentConfig kubeletconfigv1beta1.KubeletConfiguration `json:"kubeletconfig"` } configz := configzWrapper{} kubeCfg := kubeletconfig.KubeletConfiguration{} contentsBytes, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, err } err = json.Unmarshal(contentsBytes, &configz) if err != nil { return nil, err } err = scheme.Scheme.Convert(&configz.ComponentConfig, &kubeCfg, nil) if err != nil { return nil, err } return &kubeCfg, nil } </ins>

Kubelet and System-reserve are implemented on Windows along with pod/container reserves which can help prevent overprovisioning, but we still need to test OOM behavior. We need a test case that will: kubelet & system reserve pods until node is full something that will take up system ram so that OOM is triggered /sig windows /milestone v1.14
I have started to look into this test case and have a few questions: What is the expected behavior we are testing for? What does "run something that will take up system ram" mean? Does that mean run a pod that uses up memory or run a system service that uses memory? After setting the reserves and as mentioned in we should be able to schedule pods until full and then once we trigger OOM (either by pod or system service) kubelet should continue running becuase of the reserves? Do the two settings need to be tested independently or they should be tested together? I found that seems to be doing something similar but it is in node-e2e. Is sig-windows running node-e2e tests currently?
/assign
GitHub didn't allow me to assign the following users: jsturtevant. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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
After researching this further and talking with I found that the does test the allocatable memory but uses CGroups to set reserves to test the reported vs actual. As windows does not have CGroups this test will not port as is. There is and the is not implemented so will not work either. The proposed testing solution would be two parts: kubelet & system reserve and verify allocatable is reporting properly. Schedule pods with known memory consumption values and verify the allocatable is correclty updated.Schedule until full and verify scheduling is not allowed. kubelet & system reserve and verify allocatable is reporting properly. Schedule Schedule until full and verify scheduling is not into machine and run process that consumes memory and verify kubelet and pods remain running. There is an open question on the second test as to whether kubelet and will be have properly.

If it does not we will submit test 1 and open an issue to resolve 2.
I would suggest adding a third case that would test the behavior when excessive memory pressure is exerted on the node from the pods. This is perhaps a more common use case than 2 since the pod workloads are more likely to exhibit greater resource variability than node system processes. It would also carry over as a test for when/if node allocatable enforcement get implemented for windows nodes. Additionally, to complement this work would it be suitable to test windows pod memory limit enforcement? Or is this tested elsewhere?
Agreed this is a more common case. I am not sure that it is. Is this tested on linux somewhere?
I am seeing strange numbers reported when performing a test case. I scheduled a few pods to test memory limits and then schedule a pod with no memory limit and a process that will consume all of the available memory 500mb at a time: After the pod consumes all available memory, When I compare Node Allocatable/Node usage/Pod Usage I am not seeing the numbers add up properly: My node is staying online and kubelet is reporting no memory pressure. The total node memory consumption is over the Allocatable memory. What is the expected behavior and what should the test look like?
I believe node allocatable will always just be capacity minus reserves (system and kubelet) - So in this scenario it looks like you have and/or set? The memory % on the node is relative to the allocatable amount, and still seems to be under the total memory capacity - are you sure that all available memory has been consumed by your oom pod? The node should be tainted with memory-pressure when a hard or soft eviction threshold is met (). What do you have set for and ?
Thanks for the clarification. I currently have these settings: And on the machine I am seeing most memory being used: If I understand correctly, I start to see memory-pressure once I get into the setting above. In that case I should start to see pods get evicted, so for a valid test I could adjust the values to be easier to hit then test to see that pods get evicted properly which would be similar the .

I am going to adjust a few of the settings and manually test that this is working then see what it will take to port the PriorityMemoryEviction, which currently uses cgroups which won't work on windows. This combined with testing that Memory Allocatable is being properly set should give us a good test coverage for windows on this scenario.
I performed manual testing and found that even when memory was used up on the machine the "Memory Pressure" notification was not fired. After looking deeper I found is not implemented for windows. The , which uses cgroups, provides the . This means even though is being it isn't used. On Windows, Node allocatable when used with limits and requests does prevent the node from over scheduling. I believe the the test and  (this only shows cpu and I could not find a test that demonstrated memory) demonstrate this works. But this doesn't stop a pod from consuming all the memory on the node and since eviction (hard/soft/node allocatable) is not implemented on windows this means a node can end up resource starved. I think the only valid test to be written for this scenario, as it stands now, is validating that Node Allocatable is being reported properly. Beyond that there is no functionality that can be validated around OOM behavior for the windows node.
Yeah, that sounds to be in agreement with what I've observed on the windows nodes that I run. To prevent resource starvation (as a workaround), would setting mem/cpu requests equal to mem/cpu limits for all windows pods work? I think the request / limit values get passed down into the docker daemon when it starts a container, so is it possible that docker could enforce the memory limit?
Yes, setting limits==requests would help the scheduler not over provision the nodes. I think the best way to approach this particular issue for 1.14 is to make sure docs call out what works/doesn't work and give guidance to on how to prevent resource starvation on nodes. Is there a place in the docs that would make sense for this information?

The call outs would be: , , and flags do update Node Allocatable is not implemented and are not implemented Condition is not implemented in Windows There are no OOM actions taken by kubelet As a work around to previous, and should always be equal to prevent memory resource starvation as this allows the scheduler to to use limits and Kubelet running on the windows node does not have memory restrictions. and system-reserve does not set limits on kubelet or processes running the host. This means kubelet or a process on the host could cause memory resource starvation outside the and scheduler
thank you for the thorough investigation


Question: <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="-30" y="416.75" width="364" height="146"/> </g> <g> <del> <rect style="fill: #ffffff" x="418.774" y="551" width="176.225" height="121"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="418.774" y="551" width="176.225" height="121"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="506.886" y="583.4"> <tspan x="506.886" y="583.4">Distributed</tspan> <tspan x="506.886" y="599.4">Watchable</tspan> <tspan x="506.886" y="615.4">Storage</tspan> <tspan x="506.886" y="631.4"></tspan> <tspan x="506.886" y="647.4">(implemented via etcd)</tspan> </text> </g> <g> </del> <rect style="fill: #ffffff" x="201.314" y="594.318" width="154.6" height="38"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="201.314" y="594.318" width="154.6" height="38"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="278.614" y="617.218">

CA Advisor runs inside docker containers, but I don't believe it's correct to show the Kubelet and Proxy processes as inside the docker box on the minion. Also, shouldn't the internet-firewall-really load balance across minion proxies instead of be connected to just one SPOF minion, treating that connection more like a logical connection across all minion proxies?
This is the desired state, which is admittedly not the current state. Yeah, this is a good point. k8s currently relies on its environment for load balancing. Maybe or can speak to the desired state here.
We should just review the diagram and make it correctly reflect the state of 1.0.


Question: // NewCgroupNotifier returns a linuxCgroupNotifier, which performs cgroup control operations required // to receive notifications from the cgroup when the threshold is crossed in either direction. func NewCgroupNotifier(path, attribute string, threshold int64) (CgroupNotifier, error) { <ins> // cgroupv2 does not support monitoring cgroup memory thresholds using cgroup.event_control. // Instead long term, on cgroupv2 kubelet should rely on combining usage of memory.low on root pods cgroup with inotify notifications on memory.events and or PSI pressure. // For now, let's return a fake "disabled" cgroup notifier on cgroupv2. // https://github.com/kubernetes/kubernetes/issues/106331 if libcontainercgroups.IsCgroup2UnifiedMode() { return &disabledThresholdNotifier{}, nil } </ins> var watchfd, eventfd, epfd, controlfd int var err error watchfd, err = unix.Open(fmt.Sprintf("%s/%s", path, attribute), unix.O_RDONLY|unix.O_CLOEXEC, 0)

Start kubelet on a cgroupv2 image with kubelet config option or the flag enabled. Kubelet will periodically log something like: This is because the kernel memcg notifications relies on kubelet's which uses evenfd on file which is cgroupv1 specific and not supported on cgroupv2. Kubelet will disable kernel memcg notifications on cgroupv2 if they are unsupported and consider long term support for more cgroupv2 "compatible" ways to monitor for memory pressure. The closest analogous cgroupv2 concept is using inotify notifications on file and or combination with PSI pressure. This requires to be set on pod cgroup which requires the MemoryQOS feature to be enabled Start kubelet on a cgroupv2 image with enabled.
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 node /cc


Question: filenameWidgetServerside = "../../../../test/fixtures/pkg/kubectl/cmd/apply/widget-serverside.yaml" ) <del> func readConfigMapList(t *testing.T, filename string) []byte { </del> <ins> func readConfigMapList(t *testing.T, filename string) [][]byte { </ins> data := readBytesFromFile(t, filename) cmList := corev1.ConfigMapList{} if err := runtime.DecodeInto(codec, data, &cmList); err != nil { t.Fatal(err) } <del> cmListBytes, err := runtime.Encode(codec, &cmList) if err != nil { t.Fatal(err) </del> <ins> var listCmBytes [][]byte for _, cm := range cmList.Items { cmBytes, err := runtime.Encode(codec, &cm) if err != nil { t.Fatal(err) } listCmBytes = append(listCmBytes, cmBytes) </ins> } <del> return cmListBytes </del> <ins> return listCmBytes </ins> } func readBytesFromFile(t *testing.T, filename string) []byte {

<!-- 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: The dry run output listed all the resources that would be configured: deployments, HPAs, services, and an ingress: This was expected. However, it then listed all resources again (except for the HPAs) as being pruned: The config was then applied with: As expected, no resources were actually pruned. What you expected to happen: should actually display which resources are going to be pruned. How to reproduce it (as minimally and precisely as possible): a YAML file to with it: run + prune: should be listed as both configured and pruned it again with pruning: that the deployment is configured but not pruned, even though the dry run said it would be. Anything else we need to know?: Was trying to write a devops script that gave a warning before any resources would be pruned. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): (Lubuntu 18.04) Kernel (e.g. ):Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
I can reproduce it, and i will try to fix it.


During kube-proxy bootstrap, kube-proxy retrieves node IP by accessing node object. Because kube-proxy is a static pod, kubelet may start kube-proxy before completing self registration. Hence kube-proxy may start up without knowing the correct node IP.
to confirm.
I'm hitting this as well, for the same reason - kube-proxy comes up before node registration is complete. I'm wondering what are the consequences of this?
I completely missed the issue :- kube-proxy uses the host network, so it's not blocked by kubelet registering and getting the pod CIDR. Can't kube-proxy wait and/or retry? is the bug still valid or has it been fixed?
This is not fixed. We are moving kube-proxy to daemonset. I am wondering if there is some easy config to make sure kube-proxy starts up after node status becomes ready or some sort.
yay! Is making kube-proxy blocked until node is ready not an option?
/assign
GitHub didn't allow me to assign the following users: MikeSpreitzer. Note that only can be assigned. <detailsIn response to : /assign </details
/assign
Update?
I got derailed by ; clues there would be nice. I will get back to this today, one way or another.
I have been reading about tests, wondering where to add a test case that covers this problem. It is not clear to me that Kubernetes has a test suite that can test race conditions in cluster creation.
There are some reboot/restart test.
FYI:
A test case that probes this issue would be even more intimate with the way the cluster is deployed, needing to inject a controlled delay in the node startup sequence.
Will this make 1.7?
move to the next milestone
BTW, always makes the kube-proxy before the kubelet, so it is easy to probe this issue in manual testing.
Next milestone reason: it seems that there are still some conversations about this the PR fix around whether or not we want to make require the presence of . It seems warranted then to accept this fix in the next release.
We need to address this in a patch release, but it should not block 1.7.
This is impacting one of our worker nodes as well, which was working fine and then after a restart, the API server communication was impacted (for POST requests, e.g. , ).

We noticed the the error in the kube-proxy logs. The workaround is to detect the failure via the logs, and restart the kube-proxy pod.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
As far as I can tell, the nodeIP is used in one particular case and nowhere else. Specifically a service of type=LoadBalancer, which also uses LoadBalancerSourceRanges field AND specifies the node itself as a valid source range for the LB. That's a pretty corner case. I bet we could find a better way to express that, and eliminate that parameter and error message entirely. I doubt it is actually causing anyone problems unless I totally misunderstand what that field is doing
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
Since the PR is merged to master, is also used in . Now if this race condition happens, kube-proxy is not able to determine the correct nodeIP. This affects all the nodeport services with kube-proxy mode ipvs. Please reopening the issue.
You can't reopen an issue/PR unless you authored it or you are a collaborator. <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
looks like this shouldn't have gotten closed anyway /reopen /remove-lifecycle rotten /lifecycle frozen
Reopened this issue.

<detailsIn response to : looks like this shouldn't have gotten closed anyway /reopen /remove-lifecycle rotten /lifecycle frozen 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
Can't we use the similar fix given in PR .


Question: newClaimArray("claim11-1", "uid11-1", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation), // Binding will be completed in the next syncClaim newClaimArray("claim11-1", "uid11-1", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation, annStorageProvisioner), <del> noevents, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision1Success}, testSyncClaim), </del> <ins> []string{"Normal ProvisioningSucceeded"}, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision1Success}, testSyncClaim), </ins> }, { // Provision failure - plugin not found

is quite confusing when provisioning for a PVC fails and then succeeds: it shows the PVC as , i.e. everything is OK the last logged event is , i.e. something went wrong What of the above is correct? We should log also the success:
fixed by


Question: } } <ins> dataDir := getVolumeDeviceDataDir(m.specName, m.plugin.host) // remove ~/${pv}/data/vol_data.json first, then remove the other dir. volDataFile := path.Join(dataDir, volDataFileName) err = os.Remove(volDataFile) if err != nil && !os.IsNotExist(err) { return err } // remove ~/${pv}/data err = os.Remove(dataDir) if err != nil && !os.IsNotExist(err) { return err } // remove ~/${pv} pvPath := filepath.Dir(dataDir) err = os.Remove(pvPath) if err != nil && !os.IsNotExist(err) { return err } </ins> return 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: dir crated in would not be automatically removed. What you expected to happen: when a pod delete the, the dir would be removed How to reproduce it (as minimally and precisely as possible): create a pod using csi raw block volume and delete it Anything else we need to know?: ! pod using pv--6195-49a0-b262- actually has been deleted and the volume has been unmounted, but the dir still exists. ! {pv}/data still exists Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage /assign
I am afraid that the fix won't work for all volume plugins. I randomly checked where some volume plugins symlinks a device: iscsi: aws: So, iSCSI would be cleaned with this PR, but just as a coincidence, not as deliberate design. And AWS would still leave orphaned . I am not convinced that this we don't have a plugin that does not use subdirectories. I think a better approach is necessary. Perhaps of every plugin should clean up everything that created?
thanks for your advice, I would try to find a better approach
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
is being reverted because it broke CSI block volume cleanup
/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
/remove-lifecycle rotten is this still an issue?
I am adding CSI directories cleanup in
This should be fixed by /close
Closing this issue. <detailsIn response to : This should be fixed by /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


Question: "github.com/spf13/pflag" "k8s.io/kubernetes/contrib/mesos/pkg/hyperkube" "k8s.io/kubernetes/contrib/mesos/pkg/scheduler/service" <del> "k8s.io/kubernetes/pkg/util" </del> "k8s.io/kubernetes/pkg/util/flag" "k8s.io/kubernetes/pkg/util/logs" "k8s.io/kubernetes/pkg/version/verflag"

When I tried to use the following command to build kubernetes: I encountered the following errors: I'm using Ubuntu 14.04 and the code from master branch. will submit a patch then to fix this problem.
whoa, I just landed in the exact same place, I am trying to build k8s on a CentOS7 box. Tried with removing the unused utils and works like a charm !


Question: } } <del> // UntilFirstEntryFromZone is a IngestionPred that checks that at least one </del> <ins> // UntilFirstEntryFromLocation is a IngestionPred that checks that at least one </ins> // entry from the log with a given name was ingested. <del> func UntilFirstEntryFromZone(zone string) IngestionPred { </del> <ins> func UntilFirstEntryFromLocation(location string) IngestionPred { </ins> return func(_ string, entries []LogEntry) (bool, error) { for _, e := range entries { <del> if e.Location == zone { </del> <ins> if e.Location == location { </ins> return true, nil } }

This test consistently fails for GKE Regional Clusters: https://k8s- - can you please triage?
/assign
Hey, this was removed from 1.10 because it was never updated. Just want to make sure that this isn't a significant bug.
Yes, this is a significant bug in tests, sorry that it slipped our attention
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/open


Question: } glog.V(4).Infof("Update endpoints for %v/%v, ready: %d not ready: %d", service.Namespace, service.Name, totalReadyEps, totalNotReadyEps) <del> createEndpoints := len(currentEndpoints.ResourceVersion) == 0 </del> if createEndpoints { // No previous endpoints, create them _, err = e.client.Core().Endpoints(service.Namespace).Create(newEndpoints)

Currently, endpoints objects containing no subsets are decoded by the go client as subsets:[] (when requested individually) or as subsets:null (when requested in a list of endpoints). Because the endpoints controller is fed via a lister/watcher, it gets the subsets:null version fed to it. The subsets computation then returns an empty slice, which fails reflect.DeepEqual, which triggers a write attempt
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals


Question: pod, err = c.Pods(ns).Get(podName) framework.ExpectNoError(err) <del> nodeName := pod.Spec.NodeName By("Trying to apply a random label on the found node.") k := "e2e.inter-pod-affinity.kubernetes.io/zone" v := "china-e2etest" framework.AddOrUpdateLabelOnNode(c, nodeName, k, v) framework.ExpectNodeHasLabel(c, nodeName, k, v) defer framework.RemoveLabelOffNode(c, nodeName, k) By("Trying to launch the pod, now with podAffinity with same Labels.") labelPodName := "with-podaffinity-" + string(uuid.NewUUID()) </del> <ins> By("Trying to launch another pod, now with podAntiAffinity with same Labels.") labelPodName := "with-podantiaffinity-" + string(uuid.NewUUID()) </ins> _, err = c.Pods(ns).Create(&api.Pod{ TypeMeta: unversioned.TypeMeta{ Kind: "Pod",

https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Looking into this...
trying to track this flake down. It looks like the pod is launched despite AntiAffinity in . In my local setup I saw the same, but noticed that the new admission controller was not activate.

I have activate it and now get this:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates that InterPodAntiAffinity is respected if matching 2 {Kubernetes e2e suite}
Should be fixed by


Question: func (o *LogsOptions) Complete(f cmdutil.Factory, cmd *cobra.Command, args []string) error { o.ContainerNameSpecified = cmd.Flag("container").Changed <ins> o.TailSpecified = cmd.Flag("tail").Changed </ins> o.Resources = args switch len(args) {

<!-- 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: When attempting to get all log lines using only 10 lines of logs are returned What you expected to happen: All log lines should be returned How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This was introduced in in an attempt to fix another issue where selectors would ignore tail values !=-1. I think the problem here is the logic cannot tell if the was set explicitly by the command line or is simply the initial default value. Environment: Kubernetes version (use ): 1.13.3 Cloud provider or hardware configuration: Kubeadm OS (e.g: ): 18.04.2 LTS (Bionic Beaver) Kernel (e.g. ): Linux ubuntu 4.15.0-45-generic -Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: Others:
/sig cli
Maybe is not a bug. See the kubectl help. --tail=-1: Lines of recent log file to display. Defaults to -1 with no selector, showing all log lines otherwise 10, if a selector is provided. I think i mean a selector is provided the --tail should not use -1 ?
Thanks for you reply. There are some background in below tickets, --tail=-1 is one of the option. Please check.
The help indicates that the default is 10 if the selector is used. But if someone explicitly asks for -1 it should still work, at least in my opinion.
Encountering similar behaviour to this myself. Is there any chance whatever fixes get applied can also be applied to the branch? Since that also has strange behaviour around logs with label selectors and setting .

See
This ticket has two issues: First, It's said "TailLines must be greater than or equal to 0", however we can specify -1. kubectl logs -l app=test --tail=-3 error: TailLines must be greater than or equal to 0 kubectl logs -l app=test --tail=-1 : Wed Apr 10 06:51:34 UTC 2019 : Wed Apr 10 06:51:35 UTC 2019 : Wed Apr 10 06:51:36 UTC 2019 : Wed Apr 10 06:51:37 UTC 2019 : Wed Apr 10 06:51:38 UTC 2019 : Wed Apr 10 06:51:39 UTC 2019 : Wed Apr 10 06:51:40 UTC 2019 : Wed Apr 10 06:51:41 UTC 2019 : Wed Apr 10 06:51:42 UTC 2019 : Wed Apr 10 06:51:43 UTC 2019 Second, --tail=-1 is the legacy usage which show all lines, here just return 10 lines. kubectl logs -l app=test --tail=-1 The behavior after fix: Test cases ./kubectl logs -l app=test --tail=-3 ./kubectl logs -l app=test --tail=-1 ./kubectl logs -l app=test --tail=2 ./kubectl logs -l app=test --tail=0
Interesting. I think this also causes to fail: ^-- expected record ^-- some later record (there are only 2 pods running, so is not relevant) ^-- adding makes it work
A bit strange that it finds records a few seconds older as well.. but that's not a big concern, and not relevant for this issue. vs. Although that only happens when the workaround is used: :thinking: P.S.


Question: t.Fatalf("Failed to create StorageClass %q: %v", sc.Name, err) } } <del> // Create PVs </del> <ins> t.Log("Creating PVs") </ins> for _, pvConfig := range test.pvs { pv := makePV(pvConfig.name, classes[pvConfig.scName].Name, pvConfig.preboundPVC, config.ns, pvConfig.node) if _, err := config.client.CoreV1().PersistentVolumes().Create(context.TODO(), pv, metav1.CreateOptions{}); err != nil { t.Fatalf("Failed to create PersistentVolume %q: %v", pv.Name, err) } <ins> if err := waitForPVPhase(config.client, pvConfig.name, v1.VolumeAvailable); err != nil { t.Fatalf("PersistentVolume %q failed to become available: %v", pvConfig.name, err) } </ins> } <del> // Create PVCs </del> <ins> t.Log("Creating PVCs") </ins> for _, pvcConfig := range test.boundPvcs { pvc := makePVC(pvcConfig.name, config.ns, &classes[pvcConfig.scName].Name, pvcConfig.preboundPV) if _, err := config.client.CoreV1().PersistentVolumeClaims(config.ns).Create(context.TODO(), pvc, metav1.CreateOptions{}); err != nil { t.Fatalf("Failed to create PersistentVolumeClaim %q: %v", pvc.Name, err) } } <ins> t.Log("Creating unbound PVCs") </ins> for _, pvcConfig := range test.unboundPvcs { pvc := makePVC(pvcConfig.name, config.ns, &classes[pvcConfig.scName].Name, pvcConfig.preboundPV) if _, err := config.client.CoreV1().PersistentVolumeClaims(config.ns).Create(context.TODO(), pvc, metav1.CreateOptions{}); err != nil { t.Fatalf("Failed to create PersistentVolumeClaim %q: %v", pvc.Name, err) } } <ins> t.Log("Creating unbound PVCs which should be dynamically provisioned") </ins> for _, pvcConfig := range test.provisionedPvcs { pvc := makePVC(pvcConfig.name, config.ns, &classes[pvcConfig.scName].Name, pvcConfig.preboundPV) if _, err := config.client.CoreV1().PersistentVolumeClaims(config.ns).Create(context.TODO(), pvc, metav1.CreateOptions{}); err != nil {

Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestVolumeProvision Example: Since when has it been failing: Not sure, and aren't displaying any results /sig storage
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
/assign /remove-lifecycle rotten Still seeing this, although not very frequently. Could indicate a race.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
latest failures:
take as an example the test fails b/c is set to PVC , which is not expected. our volume binder tries to dynamically provision it:
as for the test fails for the same reason when the scheduler volume binder tries to find volumes for PVC , its corresponding volume is not synced to volume binder or synced version is not in Available state so the volume binder will try to dynamically provision it too
I think the root cause is that the scheduler fails to find matching PVs in PV Assume Cache for the PVC because the PV in the Assume Cache is not in Available state or does not exist due to event delay. We should wait for the PV/PVC Assume Cache to be up to date before scheduling the pod.

However, it's not possible in integration tests. I think we can wait for the PV to be available or bound. This should reduce failures.


Question: KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" <del> source "${KUBE_ROOT}/hack/lib/util.sh" </del> kube::log::status "Restoring kubernetes godeps"

Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign


Question: "strings" "time" <del> v1 "k8s.io/api/core/v1" </del> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields"

Graduate seccomp to GA, as defined on the respective . This is an umbrella issue to track all outstanding work. [x] API Server changes (MERGED) [x] Kubelet changes (MERGED) [x] Mark flag as deprecated (MERGED) [x] Update PSP to support seccomp fields (MERGED) [x] Document Kubernetes seccomp support (MERGED)[x] Add seccomp least privilege for docker sandbox (MERGED) [x] Add seccomp least privilege for kuberuntime (MERGED) ) /area kubelet /area kubelet-api /sig node /area security /assign
/cc
just a heads up that we have concluded all the core items for seccomp to go GA. There are still 2 pending PRs that ideally would also go in 1.19, but we are waiting for them to be reviewed: and
needs to be rebased apparently and isn't just waiting in the merge pool as verify is not passing.
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
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
I think the warning mechanism was blocked by a not existing API. This is now tracked in
/remove-lifecycle stale
Updated the description to given that the warning mechanism is now set to that milestone.
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
/priority backlog
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

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

/lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen What is the remaining work here?
I guess we have to follow-up on and implement: I can take care of that if we agree that we want to ship that in 1.27. /cc


Question: ## Node Status <del> Node Status is still under development. See: [#2164](https://github.com/GoogleCloudPlatform/kubernetes/issues/2164), [#2315](https://github.com/GoogleCloudPlatform/kubernetes/pull/2315). </del> <ins> Node status describes current status of a node. For now, there are three pieces of information: ### HostIP Host IP address is queried from cloudprovider and stored as part of node status. If kubernetes runs without cloudprovider, node's ID will be used. IP address can change, and there are different kind of IPs, e.g. public IP, private IP, dynamic IP, ipv6, etc. It makes more sense to save it as a status rather than spec. ### Node Phase Node Phase is the current lifecycle phase of node, one of `Pending`, `Running` and `Terminated`. Node Phase management is under development, here is a brief overview: In kubernetes, node will be created in `Pending` phase, until it is discovered and checked in by kubernetes, at which time, kubernetes will mark it as `Running`. The end of a node's lifecycle is `Terminated`. A terminated node will not receive any scheduling request, and any running pods will be removed from the node. Node with `Running` phase is necessary but not sufficient requirement for scheduling Pods. For a node to be considered a scheduling candidate, it must have appropriate conditions, see below. ### Node Condition Node Condition describes the conditions of `Running` nodes. Current valid conditions are `NodeReachable` and `NodeReady`. In the future, we plan to add more. `NodeReachable` means the node can be reached within the cluster. `NodeReady` means the kubelet returns StatusOK for HTTP health check. Different condition provides different level of understanding for node health. Kubernetes will make a comprehensive scheduling decision based on the information. Node condition is represented as a json object. For example, the following conditions mean the node is reachable from its cluster, but not ready to accept pods: ```json "conditions": [ { "kind": "Reachable", "status": "Full", }, { "kind": "Ready", "status": "None", } ] ``` </ins> ## Node Management

I'd like to get clarification on the following json sections representing a node: "spec": { "capacity": { "cpu": "1", "memory": "3Gi" } }, "status": { "hostIP": "127.0.0.1", "conditions": [ { "kind": "Ready", "status": "Full", "lastTransitionTime": null } ] } does 'spec' mean here? those are original parameters that the node was created with? not the current status? is there a section named conditions? conditions of what? there are 2 fields named status? a section named status and a field named status? does "status = Full" mean? does "kind = Ready" mean? the IP is part of the status and not a property of the node itself? if any of the above are bugs, pls split them to a separate issue or let me know and I'll split them. thanks
I'll update the docs. To answer your question: 'spec' defines the attrubutes of a node, including the original params. it's not current status 2, 'conditions' describes the condition of the node, i.e. is it ready to schedule pod, can I reach the node, etc. have different meanings, see below. 4,5. 'kind' specify the kind of condition, like Ready, Reachable, etc. and status means if the node is in that kind, e.g. {kind=Ready, status=Full} means node is ready and {kind=Ready, status=Non} means not ready. can change, and there is public ip, private ip, dynamic ip (DHCP), etc, it makes more sense to be a status other a spec.


Question: tags = ["automanaged"], deps = [ "//vendor/github.com/pborman/uuid:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured:go_default_library", "//vendor/k8s.io/apimachinery/pkg/runtime/schema:go_default_library",

Kubernetes version (use ): Kubernetes HEAD Environment: Cloud provider or hardware configuration: linux OS (e.g. from /etc/os-release): Kernel (e.g. ):NAME=Fedora25 What happened: apiserver panic What you expected to happen: No panic How to reproduce it (as minimally and precisely as possible): Testcase is going to be sent as a PR
Fixed by


Question: namespaces = createNamespaces(f, nodeCount, itArg.podsPerNode) totalPods := itArg.podsPerNode * nodeCount <del> configs = generateRCConfigs(totalPods, itArg.image, itArg.command, c, namespaces) </del> <ins> configs = generateRCConfigs(totalPods, itArg.image, itArg.command, namespaces) </ins> var services []*api.Service // Read the environment variable to see if we want to create services createServices := os.Getenv("CREATE_SERVICES")

https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We understand the problem here - I'm working on the fix.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}


Question: var timeCh <-chan time.Time doneCh := ctx.Done() <ins> // if immediate is true the condition is // guaranteed to be executed at least once, </ins> // if we haven't requested immediate execution, delay once <del> if !immediate { </del> <ins> if immediate { if ok, err := func() (bool, error) { defer runtime.HandleCrash() return condition(ctx) }(); err != nil || ok { return err } } else { </ins> timeCh = t.C() select { case <-doneCh:

Calling wait.PollUntilContextTimeout with immediate=true does not invoke the passed condition function if context has already been cancelled. wait.PollUntilContextTimeout with immediate=true should invoke the passed condition function at least once even if context has already been cancelled as wait.PollUntilContextCancel documentation says: Note that wait.PollUntilContextTimeout wraps wait.PollUntilContextCancel, so the above should be applied to wait.PollUntilContextTimeout as well. This program panics because context ctx.Err is checked before invoking the passed function. The deprecated wait.PollImmediateWithContext does not have this kind of issue. If wait.PollUntilContextTimeout is the replacement of wait.PollImmediateWithContext, it should exhibit the same behavior. k8s v1.27.2 <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
TestloopConditionUntilContextsemantic also has an issue that immediate and sliding are not tested as expected. immediate and sliding are loop variable, but they are not used in the test. The ones that are used are in testcase struct which are always false.
/assign
ok, it seems this would do it
/assign
/triage accepted