Question: }, }, } <del> return pvIndex.Find(pv, filterBoundVolumes) </del> <ins> return pvIndex.Find(pv, matchStorageCapacity) </ins> } // FindBestMatchForClaim is a convenience method that finds a volume by the claim's AccessModes and requests for Storage

E0513 22:55:45. 957 ] unable to sync kubernetes RO service: endpoints "kubernetes-ro" cannot be updated: the resource was updated to 266 E0513 22:55:45. 957 ] unable to sync kubernetes RO service: endpoints "kubernetes-ro" cannot be updated: the resource was updated to 266 E0513 22:55:48. 957 ] watch of api.Secret ended with: Stop requested E0513 22:55:48. 957 ] watch of api.ServiceAccount ended with: Stop requested E0513 22:55:48. 957 ] watch of api.Namespace ended with: Stop requested E0513 22:55:48. 957 ] watch of api.ServiceAccount ended with: Stop requested E0513 22:55:48. 957 ] watch of api.Secret ended with: Stop requested E0513 22:55:48. 957 ] watch of api.ServiceAccount ended with: Stop requested W0513 22:55:49. 957 ] Resetting endpoints for master service "kubernetes" to &{{ } {kubernetes default 0001-01-01 00:00:00 +0000 UTC <nilmap[] map[]} [{[{10.0.0.22 <nil}] [{ 6443 TCP}]}]} W0513 22:55:50. 957 ] Resetting endpoints for master service "kubernetes-ro" to &{{ } {kubernetes-ro default 0001-01-01 00:00:00 +0000 UTC <nilmap[] map[]} [{[{10.0.0.22 <nil}] [{ 7080 TCP}]}]} W0513 22:55:50. 957 ] Resetting endpoints for master service "kubernetes-ro" to &{{ } {kubernetes-ro default 0001-01-01 00:00:00 +0000 UTC <nilmap[] map[]} [{[{10.0.0.22 <nil}] [{ 7080 TCP}]}]} W0513 22:55:50.

957 ] Resetting endpoints for master service "kubernetes" to &{{ } {kubernetes default 0001-01-01 00:00:00 +0000 UTC <nilmap[] map[]} [{[{10.0.0.22 <nil}] [{ 6443 TCP}]}]} W0513 22:55:50. 957 ] Resetting endpoints for master service "kubernetes-ro" to &{{ } {kubernetes-ro default 0001-01-01 00:00:00 +0000 UTC <nilmap[] map[]} [{[{10.0.0.22 <nil}] [{ 7080 TCP}]}]} W0513 22:55:50. 957 ] Resetting endpoints for master service "kubernetes-ro" to &{{ } {kubernetes-ro default 0001-01-01 00:00:00 +0000 UTC <nilmap[] map[]} [{[{10.0.0.22 <nil}] [{ 7080 TCP}]}]} W0513 22:55:50. 957 ] Resetting endpoints for master service "kubernetes-ro" to &{{ } {kubernetes-ro default 0001-01-01 00:00:00 +0000 UTC <nilmap[] map[]} [{[{10.0.0.22 <nil}] [{ 7080 TCP}]}]} E0513 22:55:50. 957 ] unable to sync kubernetes service: endpoints "kubernetes" cannot be updated: the resource was updated to 279 E0513 22:55:50. 957 ] unable to sync kubernetes RO service: endpoints "kubernetes-ro" cannot be updated: the resource was updated to 280 E0513 22:55:50. 957 ] unable to sync kubernetes RO service: endpoints "kubernetes-ro" cannot be updated: the resource was updated to 280 E0513 22:55:50. 957 ] unable to sync kubernetes RO service: endpoints "kubernetes-ro" cannot be updated: the resource was updated to 280 E0513 22:55:50. 957 ] unable to sync kubernetes RO service: endpoints "kubernetes-ro" cannot be updated: the resource was updated to 280 W0513 22:55:51. 957 ] Portal net unspecified.

Defaulting to 10.0.0.0/24. I0513 22:55:51. 957 ] Will report 10.0.0.22 as public IP address. E0513 22:56:00. 957 ] Unable to authenticate the request due to an error: Token has been invalidated E0513 22:56:00. 957 ] Unable to authenticate the request due to an error: Token has been invalidated E0513 22:56:00. 957 ] Unable to authenticate the request due to an error: Token has been invalidated E0513 22:56:01. 957 ] Unable to authenticate the request due to an error: Token has been invalidated E0513 22:56:08. 957 ] watch of api.Secret ended with: Stop requested E0513 22:56:08. 957 ] watch of api.ServiceAccount ended with: Stop requested E0513 22:56:08. 957 ] watch of api.Namespace ended with: Stop requested E0513 22:56:08. 957 ] watch of api.ServiceAccount ended with: Stop requested E0513 22:56:08. 957 ] watch of api.Secret ended with: Stop requested E0513 22:56:08. 957 ] watch of api.ServiceAccount ended with: Stop requested FAIL FAIL 111.315s
Do we know which test is failing? The last messages in the log are from , but I don't actually see a test failure message printed, and I can't recreate any failures.

The "Unable to authenticate the request due to an error: Token has been invalidated" messages are expected since the test exercises attempting to use invalid tokens () Also, the "Stop requested" messages indicate that particular test completed and invoked the deferred stopFunc, which shuts down the controllers and closes the test server
Here is the failing test: --- FAIL: TestPersistentVolumeClaimBinder (3.45s) Expected claim to be bound: &{TypeMeta:{Kind: APIVersion:} ObjectMeta:{Name:claim02 GenerateName: Namespace:default SelfLink:/api/v1beta1/persistentVolumeClaims/claim02?namespace=default UID:-f9c3-11e4-96ec- ResourceVersion:172 CreationTimestamp:2015-05-13 22:54:47 +0000 UTC DeletionTimestamp:<nilLabels:map[] Annotations:map[]} Spec:{AccessModes:[ReadOnlyMany ReadWriteOnce ReadWriteMany] Resources:{Limits:map[] Requests:map[storage:{Amount: Format:BinarySI}]} VolumeName:} Status:{Phase:Pending AccessModes:[] Capacity:map[]}}
you aware of the issue with TestPersistentVolumeClaimBinder?
I ran into above issue a lot.
Sorry, hadn't seen this sooner. Lost in the flurry of email traffic. I am looking into it now.
I cannot reproduce on F20, Go 1.3.1 I'll try 1.4 next. Any other info would be appreciated.
Here is the output of docker version from my desktop. Client version: 1.6.2 Client API version: 1.18 Go version (client): go1.4.2 Git commit (client): OS/Arch (client): linux/amd64 Server version: 1.6.2 Server API version: 1.18 Go version (server): go1.4.2 Git commit (server): OS/Arch (server): linux/amd64 I started to run into this issue two days ago, and just ran into it half hour ago right after I sync-ed to HEAD again. Any more information you need here?
Thanks :)
I cannot reproduce this on F20, Go 1.4.2 Any runtime settings I might be missing? I see hack/test- is set to "-race" .


Question: func IsCriticalPodBasedOnPriority(priority int32) bool { return priority >= scheduling.SystemCriticalPriority } <ins> // IsNodeCriticalPod checks if the given pod is a system-node-critical func IsNodeCriticalPod(pod *v1.Pod) bool { return IsCriticalPod(pod) && (pod.Spec.PriorityClassName == scheduling.SystemNodeCritical) } </ins>

<!-- Feature requests are unlikely to make progress as an issue. Instead, please suggest enhancements by engaging with SIGs on slack and mailing lists. A proposal that works through the design along with the implications of the change can be opened as a KEP: --I'd like only pods to have low OOM score -997. introduced a change which ensured all the critical priority classes will have a low OOM score -997. While this helped in relating OOM score to priority of pod, it also allows containers in pods to have -997 OOM score, making them one of the last processes to be OOMKilled. By definition pods can be scheduled elsewhere if there is crunch on the node where as pods cannot be rescheduled. This was the reason for to have higher priority value than . So, I think it makes sense for only pods to have low OOM score of -997. /sig node cc
/triage accepted
i think this is reasonable since is higher priority than and this would make a distinction between the two making killable but assured to be rescheduled
Note that oomscore has nothing to do with rescheduling. Eviction looks at priority, oomscore simply controls the killer. I think that strengthens the argument - the point of node-critical is makinng sure it's killed last, but even then that should be a rare, rare case (a memory leak in kube-proxy will blow out the workload, but if we just killed kube-proxy everything would heal). We may want to go back to the original justifications for -99x oomscore in system-node-critical and make sure we're still aligning correctly.


Question: expected["bert"] = sets.NewString("one", "two") expected["elmo"] = sets.NewString("tre") expected["oscar"] = sets.NewString("two") <del> expected["elmo"] = sets.NewString() // let's just make sure we don't get anything back in this case </del> <ins> expected["elmo1"] = sets.NewString() </ins> { for k, v := range expected { found := sets.String{}

second will cancel the first set, as a result, the is checking empty list which will always be true. this test should fail.
/sig testing
A set is immutable, and by definition cannot support two of the same key name. We should have to change the data structure for this to pass, no?
/assign After read , size check would be a way to solve this problem. I try to fix this in
/sig apimachinery /remove-sig testing sig testing owns the frameworks, infrastructure, etc. SIG api-machinery owns their unit tests / client-go
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig apimachinery /remove-sig testing Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api-machinery
/triage accepted


Question: t.Fatal(err) } <ins> var extenders []framework.Extender for ii := range test.extenders { extenders = append(extenders, &test.extenders[ii]) } </ins> sched := &Scheduler{ Cache:                    cache, nodeInfoSnapshot:         snapshot, percentageOfNodesToScore: schedulerapi.DefaultPercentageOfNodesToScore, <ins> Extenders:                extenders, </ins> } sched.applyDefaultHandlers()

When Extender filters out some Nodes, we don't set any unschedulable plugins at all. It means Extender is completely ignored during the requeueing process. So, what's happening is: If Extender filters out all Nodes during scheduling, this Pod is soon retried because this Pod doesn't have any plugin name in unschedulable plugins. If Extender filters out some Nodes during scheduling and plugins filter out all other Nodes, this Pod is retried based on plugins' QueueingHint. Even if any cluster events happen and it could change Extender's decision (but not any plugins' decision), this Pod won't be requeued to activeQ/backoffQ. The latter case is serious because it could make Pods being stuck in unschedulable pod pool in 5min. We should have a short-term solution for the latter case. We can requeue Pods, which were rejected by Extender, by any kind of cluster events because we cannot know which events make Pods schedulable. Eventually, this issue makes us wonder how Pods rejected by Extender should be requeued. We cannot implement QHint equivalent in Extenders because it'd be too slow to call Extender every time any cluster events happen. Probably, somehow implementing EventsToRegister equivalent in Extender? Use Extender which does something in Filter. No response master <detailsn/a </details<details</details<details</details<details</details<details</details
/assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
/reopen We'll close it when all cherry-picks are done.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/close Cherry-picks are done.


Question: // if the number of consecutive read failure equals or exceeds the failureThreshold , the // configuration is regarded as not ready. failureThreshold int <ins> // number of consecutive failures so far. failures int </ins> // if the configuration is regarded as ready. ready               bool mergedConfiguration runtime.Object

Found in I can reproduce locally using
/assign (via git blame)
cc
Thanks. I will take a look.
Got a fix locally. Testing it.


Question: return nil } <del> // addLivezChecks allows you to add a HealthCheck to livez. It will also automatically add a check to readyz, // since we want to avoid being ready when we are not live. func (s *GenericAPIServer) addLivezChecks(delay time.Duration, checks ...healthz.HealthChecker) error { </del> <ins> // AddLivezChecks allows you to add a HealthCheck to livez. func (s *GenericAPIServer) AddLivezChecks(delay time.Duration, checks ...healthz.HealthChecker) error { </ins> s.livezLock.Lock() defer s.livezLock.Unlock() if s.livezChecksInstalled {

<!-- Please only use this template for submitting enhancement requests --What would you like to be : When using GenericAPIServer you can only add new checks via function which adds them to all , , and endpoints. All other methods like are private. I would like to request those methods to be made public: Why is this needed: Developers of apiservers should be able to define their readiness probes add them to specific endpoint of their choosing. For example in case of Metrics Server we defined probes: Readiness - Metrics cache is full. As MS serves data only from cache, traffic will be only sent after cache is full. Liveness - Metric scraping loop is not deadlocked. It doesn't make sense to have those probes to both endpoints. Not ready metric cache should not cause MS being killed via liveness probe. Delayed scrape should not cause traffic not being served from cache due failing readiness probe. /assign
/sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig apimachinery Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api-machinery
/cc /triage accepted
I can see this. PR welcome.


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

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --integration test jobs TestQuotaLimitService which was recently in One example run: I suspect this is because TestQuotaLimitService runs through multiple test cases where each test case relies on state created from the previous case. However, resource quota changes take some time to get propagated on the system and the test is trying to validate acceptance of new Services before the resource quota controller applies the necessary changes. links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
cc
/sig network /sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /sig apimachinery Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api-machinery
Opened a fix here
/triage accepted


Question: concurrencyLimit:       6, evalDuration:           time.Second * 20, expectedFair:           []bool{true}, <del> expectedFairnessMargin: []float64{0.1}, </del> <ins> expectedFairnessMargin: []float64{0.16}, </ins> expectAllRequests:      true, evalInqueueMetrics:     true, evalExecutingMetrics:   true,

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --pull-kubernetes-unit TestDifferentWidths links to appreciated links to specific failures in spyglass appreciated
/sig api-machinery
/assign /cc /triage accepted
Yes, a couple of the unit tests have too stringent evaluations. See


Question: recognizers: recognizers(), } return certificates.NewCertificateController( <ins> "csrapproving", </ins> client, csrInformer, approver.handle,

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


Question: // // If the webhook is running within the cluster, then you should use `service`. // <del> // If there is only one port open for the service, that port will be // used. If there are multiple ports open, port 443 will be used if it // is open, otherwise it is an error. </del> <ins> // Port 443 will be used if it is open, otherwise it is an error. </ins> // // +optional Service *ServiceReference `json:"service" protobuf:"bytes,1,opt,name=service"`

What happened: Deployed a webhook backend and service as follows: Please note that there is only 8443 port on the service. Register the webhook as follows: Got the following error when creating pods: What you expected to happen: Based on , should be called. Not the 443 port shown in the error message. How to reproduce it (as minimally and precisely as possible): Just deploy the same setup and register webhook. Anything else we need to know?: Environment: Kubernetes version (use ): HEAD Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.0-alpha.1.97+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-01-22T20:00:24Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.470+", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-03-12T19:36:42Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): COS Kernel (e.g. ): COS
thanks for the detailed bug report!
I actually think that the API specification (or documentation) must change. Not all API servers will have access to look up the Service object and see what ports it defines. If we want to support ports other than 443, the port information must be specified in the webhook object, not discovered by direct Service object lookup
/assign
Looks like it will always use 443 no matter what ports are available, right? Should our documentation reflect this or should it behave differently? (also just sets 443 in the custom dial wrapper thing )
As a first step, I would adjust the documentation. As noted in , if we want to support ports other than 443, that information needs to be to the webhook config object


Question: return err } <del> dataDir := filepath.Dir(deviceMountPath) if err := os.MkdirAll(dataDir, 0750); err != nil { glog.Error(log("attacher.MountDevice failed to create dir %#v:  %v", dataDir, err)) </del> <ins> // Store volume metadata for UnmountDevice. Keep it around even if the // driver does not support NodeStage, UnmountDevice still needs it. if err = os.MkdirAll(deviceMountPath, 0750); err != nil { glog.Error(log("attacher.MountDevice failed to create dir %#v:  %v", deviceMountPath, err)) </ins> return err } <ins> glog.V(4).Info(log("created target path successfully [%s]", deviceMountPath)) dataDir := filepath.Dir(deviceMountPath) </ins> data := map[string]string{ volDataKey.volHandle:  csiSource.VolumeHandle, volDataKey.driverName: csiSource.Driver, } <del> if err := saveVolumeData(dataDir, volDataFileName, data); err != nil { </del> <ins> if err = saveVolumeData(dataDir, volDataFileName, data); err != nil { </ins> glog.Error(log("failed to save volume info data: %v", err)) <del> if err := os.RemoveAll(dataDir); err != nil { glog.Error(log("failed to remove dir after error [%s]: %v", dataDir, err)) return err </del> <ins> if cleanerr := os.RemoveAll(dataDir); err != nil { glog.Error(log("failed to remove dir after error [%s]: %v", dataDir, cleanerr)) </ins> } return err } <ins> defer func() { if err != nil { // clean up metadata glog.Errorf(log("attacher.MountDevice failed: %v", err)) if err := removeMountDir(c.plugin, deviceMountPath); err != nil { glog.Error(log("attacher.MountDevice failed to remove mount dir after errir [%s]: %v", deviceMountPath, err)) } } }() </ins> if c.csiClient == nil { c.csiClient = newCsiDriverClient(csiSource.Driver)

/kind bug /sig storage What happened: When using a CSI driver that does not support NODESTAGE, I can see orphan json files in that are never cleaned up. What you expected to happen: No orphan file /assign


Question: docs/user-guide/kubectl/kubectl_port-forward.md docs/user-guide/kubectl/kubectl_proxy.md docs/user-guide/kubectl/kubectl_replace.md <del> docs/user-guide/kubectl/kubectl_rolling-update.md </del> docs/user-guide/kubectl/kubectl_rollout.md docs/user-guide/kubectl/kubectl_rollout_history.md docs/user-guide/kubectl/kubectl_rollout_pause.md

Rolling-update tasks which worked since v1.0 are now getting stuck mid-way since v1.2 I'm rolling a multi-container pod from to . The target number of replicas is 4. The first 2 pods are rolled correctly, but the job hangs and times out (5min) after the first 2 iterations: Controller manager logs: Note the time it took to scale down on the second iteration, although all the pods marked new transitioned to a state in less than 10sec. My RC selector matches 3 labels. After the timeout the 2 RCs look like:
Can you please share the exact command you are running that leads to timeout? cc
I first get the current RC definition in YAML format, replace the image tag and label, and finally pass it to:
Were you able to reproduce this consistently (i.e. this always fail)?
Yes, 100%. It eventually goes through if I increase the timeout but I still have to wait a couple of minutes between each pod. I switched this deployment task to the API with the Rolling-update strategy and it's extremely fast.
Yes, we'd recommend using  since it's faster, declarative and has more features, such as you can rollback to a previous reversion even when the rollout/rolling-update is done. When you're using , is it possible that there are overlapping resources fighting with , such as replicasets, deployments, or replication controllers with the same label selector?
labels are not conflicting. I have 2 other rcs in that namespace and each of them has a different label (see my first comment). Nothing has changed in that deployment procedure since Kubernetes v1.0, and v1.2 is the first version that seems to struggle. I can post my rc definition here, just in case you can't reproduce with a generic 3-container pod.
Yes, posting the RC definition would help, since I cannot reproduce it on my end. Thanks!
The following definition times out as described above. It resembles our real definition, minus a log forwarding container which I replaced by something generic like postgres.

Secrets: Create the rc and secrets: Now delete the rc without killing the pods: In the definition, rename the rc to anything else, and recreate it: In the definition, rename the rc back to the original name "issue23276" and bump the "deployment" number in the label, then perform a rolling-update: It remains stuck in this state:
cc
Quick observations: In 1.1 and 1.2, rolling update takes pod readiness into account before proceeding. Are the pods ready? Use "kubectl get -o yaml pod ...". Cpu limits are now enforced using cpu quota and 10m is a very small limit. Specify "requests" instead.
In and specifically refererring to , it seems that this pod is never scaled down (based on the following output from . Can you inspect the container logs from the old pods for anything weird?
This limit is low on purpose, this container only starts . In our production environment we use it for log rotation with the same CPU limits. When deployed using the API everything works and the rolling update takes less than a minute. All pods are running as expected and don't show any error.
Same problem here. We don't use any limits, but simple scale down more then 3 pods is hangs. One moment about rolling-update issue: it appears only in case of renaming original rc; if use it by default all ok.
should help in identifying if the error comes from the scaler.
Must add to message, that with bigger time-out (--timeout=30m), rolling-update proceeds after 3 pods but much slower. On master I have following log for 5 pods RC: Message like appear every time before update makes progress after a ~5 minutes freeze.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig cli
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
We should consider deprecating the rolling-update command.
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close


Question: # If you want to build AND push all containers, see the 'all-push' rule. all: all-container <ins> all-push: all-push-images push-manifest push-manifest: manifest-tool manifest-tool push from-args --platforms $(call join_platforms,$(ALL_ARCH)) --template $(IMAGE)-ARCH:$(TAG) --target $(IMAGE):$(TAG) </ins> sub-container-%: $(MAKE) ARCH=$* container

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature This issue if for tracking the work related to pushing manifest list for kubernetes images(infra and test) List of images for which manifest need to be created: - [x] kubernetes to use manifest pause image - [x] dns - - - - - [ ] dashboard [x] Manifest images for k8s release images -
/assign
/cc
/sig cluster-lifecycle
/sig testing
/area test-infra /sig release
/reopen
I'd add dashboard to this as well, based off the issue at
can you provide a status update on this issue? I'd really want this fully working in v1.10... :)
I've created one more PR for pushing manifest for few more images, reference - I'll try my best to push into v1.10 release
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
/remove-lifecycle stale
/remove-lifecycle rotten
A problem related to manifests and was addressed here:
An update of this issue would be welcomed to track the status of all affected images, since I think at least some of the linked issues have progressed.
/sig testing
all the k8s core images are now fat manifest, hence closing this task. Will create a separate task for creating manifest for ecosystem images(e.g dashboard, metric-server etc...)
did you have a issue open tracking other images? I noticed today that kube-addon-manager (cluster/addons/addon-manager) is multi-arch but not using a manifest list yet.


Question: if [[ "${NETWORK_PROVIDER:-}" == "kubenet" ]] ||  [[ "${NETWORK_PROVIDER:-}" == "cni" ]]; then #TODO(andyzheng0831): We should make the cni version number as a k8s env variable. <del> local -r cni_tar="cni-07a8a28637e97b22eb8dfe710eeae1344f69d16e.tar.gz" local -r cni_sha1="19d49f7b2b99cd2493d5ae0ace896c64e289ccbb" </del> <ins> local -r cni_tar="cni-0799f5732f2a11b329d9e3d51b9c8f2e3759f2ff.tar.gz" local -r cni_sha1="1d9788b0f5420e1a219aad2cb8681823fc515e7c" </ins> download-or-bust "${cni_sha1}" "https://storage.googleapis.com/kubernetes-release/network-plugins/${cni_tar}" local -r cni_dir="${KUBE_HOME}/cni" mkdir -p "${cni_dir}"

Started as a tangent of Many CNI plugins don't properly handle a action on missing resources. The spec says, , however many improperly return an error. I see the steps moving forward to be: [x] Modify CNI plugins bundled with Kubernetes to properly support del (flannel already done; bridge, ipvlan, macvlan, and ptp in containernetworking/cni) [x] Create release of containernetworking/cni Does this make sense? cc/
SGTM - I'm working on the right now and can do the CNI release too. On the 3rd check box - why is that still a thing? Doesn't the CNI project provide the required artifacts as part of its release? Maybe not something to resolve now but I'd like to make sure the CNI project is providing the right things to projects that use it.
I just want to say thanks to everyone for jumping on this.
status tracking doc
I can test out patches as needed. I currently only have test cases for Weave and Calico, but it should not be too difficult to add others.
It would be great to get flannel tested too. You probably need a master build of the flannel CNI plugin and possibly some flannel patches to be merged. Feel free to DM on slack if you need more info.
s390x builds are missing still. If that's , we can switch to v0.5.1 in time for v1.7. However, I really don't want to bump from v0.3.0-ish to v0.5.0 one day before release. This is a v1.7 issue to ensure all CNI plugins (including the official) work as intended with Kubernetes and an issue to make sure we update to CNI v0.5.0 w/ spec v0.3.0 in time for v1.7. I think will solve the short-term solutions. Also it seems like Weave, Calico and maybe Canal has fixed this as-is. I think Flannel works with
I'm a little confused! You mean s390x builds for flanneld? And what do you mean by This is a v1.7 issue I thought this was a 1.6 issue?

CNI still needs s390x binaries to be consumable by k8s: Two other conclusions: 1) We should go with as the immediate solution 2) We should upgrade to CNI v0.5.1 (when released( officially for Kubernetes in time for v1.7 and enforce the latest spec (v0.3.0) for all network plugins
We should get the PR in (after testing), but this is not a really solution as it only avoids hitting this problem at cluster setup.
OK, that makes sense on the s390x binaries. I've just released v0.5.1 of CNI, which updates the plugins with the new del behaviour. They should all still be back compatible with the older spec versions so I recommend that K8s takes this CNI release.
I'm working on a patch for that bump now
Be aware that has just been merged. If you sync to HEAD, you won't be able to reproduce this problem at cluster setup easily.
New cni packaged tarball (based on v0.5.1) has been pushed:
-- can this be closed?
we can't close until all the consumers have been updated to point to the new tarballs
What is the ETA for resolving this?
Ok, I see that is at the top of the submit queue.


Question: streams, _, buf, _ := genericclioptions.NewTestIOStreams() cmd := NewCmdConfig(cmdutil.NewFactory(genericclioptions.NewTestConfigFlags()), clientcmd.NewDefaultPathOptions(), streams) <ins> // "context" is a global flag, inherited from base kubectl command in the real world cmd.PersistentFlags().String("context", "", "The name of the kubeconfig context to use") </ins> cmd.SetArgs(argsToUse) cmd.Execute() <del> // outBytes, _ := ioutil.ReadFile(fakeKubeFile.Name()) </del> config := clientcmd.GetConfigFromFileOrDie(fakeKubeFile.Name()) return buf.String(), *config }

/kind bug What happened: Current context was set to cluster1. Ran and got back information about cluster1 instead. What you expected to happen: I expected the output to be the cluster2 information How to reproduce it (as minimally and precisely as possible): Have two contexts in your kube config, A and B Run to set A as current context Run Anything else we need to know?: I'd like to help contribute, so if this is an easy fix, someone point me in the right direction and I'll try to get it done. Environment: Kubernetes version (use ): 1.10.2 OS (e.g. from /etc/os-release): MacOS 10.11.6 Install tools: kubectl was installed via brew
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
/assign Filed


Question: import ( "fmt" "io" <ins> "sort" </ins> "k8s.io/apimachinery/pkg/api/resource" "k8s.io/kubernetes/pkg/api"

and node should sort by namespace / name so that results don't jump around. We should consider adding sort, but only after we make a stable sort the default.
next Also, why does it sometimes lose nodes? Annoying
I did not reproduce this. I think this may be caused by the monitoring timeout of heapster. So that the data got missing.


Question: framework.ExpectError(err, "created secret %q with empty key in namespace %q", secret.Name, f.Namespace.Name) }) <del> ginkgo.It("should patch a secret", func() { </del> <ins> /* Release : v1.18 Testname: Secret patching Description: A Secret is created. Listing all Secrets MUST return an empty list. Given the patching and fetching of the Secret, the fields MUST equal the new values. The Secret is deleted by it's static Label. Secrets are listed finally, the list MUST NOT include the originally created Secret. */ framework.ConformanceIt("should patch a secret", func() { </ins> ginkgo.By("creating a secret") secretTestName := "test-secret-" + string(uuid.NewUUID())

This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to these query results from APIsnoop, we are lacking in tests for the follow endpoints related to Secrets. We chose the follow endpoints for this mock test. Test outline: a Secret in the default namespace with custom values Secrets in all namespaces search for Secret created in  the data in Secret  Secret  Secrets in all namespaces ensure that Secret  doesn't exist Discover useragents Display endpoints hit by the test Review the change in coverage If a test with these calls gets merged in, conformance will go up by 3 endpoints. /sig architecture /area conformance
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /close
Closing this issue. <detailsIn response to : Yeah! We got a test written and a promotion (and we linked them to the mock-ticket that started it all). /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: // How long pods have to become scheduled onto nodes podScheduledBeforeTimeout = PodListTimeout + (20 * time.Second) <del> podRespondingTimeout     = 2 * time.Minute </del> <ins> podRespondingTimeout     = 15 * time.Minute </ins> ServiceRespondingTimeout = 2 * time.Minute EndpointRegisterTimeout  = time.Minute

https://k8s- Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gci-gke-serial ci-kubernetes-e2e-gke-serial-release-1.5 ci-kubernetes-e2e-gke-serial Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
Builds: ci-kubernetes-e2e-gci-gke-serial-release-1.5 ci-kubernetes-e2e-gke-containervm-1.4-gci-1.5-upgrade-cluster-new ci-kubernetes-e2e-gke-serial-release-1.5 Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should recreate pods scheduled on the unreachable node AND allow scheduling of pods on a node after it rejoins the cluster {Kubernetes e2e suite}
this is currently assigned to you -- can you take a look? I guess it has not failed individually recently, only as part of large "broken test runs" so maybe we should close it? Please advise.
This has only failed once in the last couple of weeks in https://k8s- and zero times in https://k8s- so I think we should close it. WDYT?
Yes, fixed a regression in this recently. Closing this.
It seems like this test is still flaking a lot on GKE
should this block 1.6?
Re-opening until we've verified it's fixed. It seems to have just failed again
I think the serial tests haven't picked up the fix yet.
Tests are looking good, closing if I see another success.
We need to cherrypick the fix in into 1.6. I've filed a separate issue to track the hanging network calls on the GKE apiserver. /cc
I believe this was fast forwarded onto the branch by
-- can we take this off of the 1.6 release now? It seems to be a test setup issue
Yes, this is not a blocker anymore.

this can be removed from the 1.6 milestone
This Issue hasn't been active in 49 days. It will be closed in 40 days (Jun 14, 2017). cc You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days


Question: []string{"Normal ExternalProvisioning"}, noerrors, testSyncClaim, }, <ins> { // Provision a volume with a data source will fail // for in-tree plugins "11-25 - failed in-tree provision with data source", novolumes, novolumes, claimWithDataSource("test-snap", "VolumeSnapshot", "snapshot.storage.k8s.io", newClaimArray("claim11-25", "uid11-25", "1Gi", "", v1.ClaimPending, &classGold)), claimWithDataSource("test-snap", "VolumeSnapshot", "snapshot.storage.k8s.io", newClaimArray("claim11-25", "uid11-25", "1Gi", "", v1.ClaimPending, &classGold)), []string{"Warning ProvisioningFailed"}, noerrors, testSyncClaim, }, { // Provision a volume with a data source will proceed // for CSI plugins "11-26 - csi with data source", novolumes, novolumes, claimWithAnnotation(pvutil.AnnStorageProvisioner, "mydriver.csi.k8s.io", claimWithDataSource("test-snap", "VolumeSnapshot", "snapshot.storage.k8s.io", newClaimArray("claim11-26", "uid11-26", "1Gi", "", v1.ClaimPending, &classCSI))), claimWithAnnotation(pvutil.AnnStorageProvisioner, "mydriver.csi.k8s.io", claimWithDataSource("test-snap", "VolumeSnapshot", "snapshot.storage.k8s.io", newClaimArray("claim11-26", "uid11-26", "1Gi", "", v1.ClaimPending, &classCSI))), []string{"Normal ExternalProvisioning"}, noerrors, wrapTestWithProvisionCalls([]provisionCall{}, testSyncClaim), }, </ins> } runSyncTests(t, tests, storageClasses, []*v1.Pod{}) }

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In clusters that have intree drivers as the default storageclass, if you try to create a PVC with snapshot data source and forget to put the csi storageclass in it, then an empty PVC will be provisioned using the default storageclass. What you expected to happen: PVC creation should not proceed and instead have an event with an incompatible error, similar to how we check proper csi driver in the csi provisioner. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
I think similar issue exists with cloning. We'll need to think about what the behavior should be for data populators too. cc
/triage accepted
Scenario to reproduce the issue Create the nginx deployment and the PVC used by it Exec into the running container, cd into the PVC mounted path and create some files Create the following using as source the The used is the following and wait until it becomes Delete the deployment and the initial PVC Create a new PVC, using the previously created as its Set the name of the new (restored) PVC to the nginx deployment and create the again into the PVC mounted directory. It should contain the previously created files but its empty
can you modify the title of this issue and change to ? In addition to snapshot datasource, using PVC datasource and AnyVolumeDataSource should also fail for in-tree PVC.
/assign
I wasn't 100% sure on data populators. Because it shouldn't have a dependency on CSI right?
I guess even if data populators does support intree volumes, pv controller should ignore it similar to csi provisioner
It may or may not have a dependency on CSI. Design is still in progress. We can leave it out for now until we know exactly how to use it. One thing I know is that the any volume data source cannot be an in-tree k8s resource.
Yes, we can actually just ignore it in pv controller.

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
I'm getting same with longhorn, is this issue resolved on your side?


Question: ] + select({ "@io_bazel_rules_go//go/platform:linux": [ "//vendor/github.com/vishvananda/netlink:go_default_library", <ins> "//vendor/golang.org/x/sys/unix:go_default_library", </ins> ], "//conditions:default": [], }),

https://k8s- https://k8s- cc: /priority failing-test
Sorry, but I will fix it ASAP.
/assign
PR is already sent. Wating for CI report...


Question: fs.StringVar(&s.ClusterName, "cluster_name", s.ClusterName, "The instance prefix for the cluster") fs.BoolVar(&s.EnableProfiling, "profiling", false, "Enable profiling via web interface host:port/debug/pprof/") fs.StringVar(&s.ExternalHost, "external_hostname", "", "The hostname to use when generating externalized URLs for this master (e.g. Swagger API Docs.)") <ins> fs.IntVar(&s.MaxRequestsInFlight, "max_requests_inflight", 20, "The maximum number of requests in flight at a given time.  When the server exceeds this, it rejects requests.  Zero for no limit.") fs.StringVar(&s.LongRunningRequestRE, "long_running_request_regexp", "[.*/watch$][^/proxy.*]", "A regular expression matching long running requests which should be excluded from maximum inflight request handling.") </ins> } // TODO: Longer term we should read this from some config store, rather than a flag.

Related with issue , the API server should have a cap on the number of outstanding operations/requests it's handling, and return an error otherwise. A simple semaphore is an idea for this.
+1 !
The good news/bad news on this is that there is a rate limiter in the API server (), but the defaults for it seem too high: 10 qps average, 200 burst (). We could start by lowering the burst level to something smaller, like 30. It may be interesting to also differentiate between GET and PUT/POST requests.
I think that we need limits on the number of outstanding requests, not the number of QPS.
-An max outstanding would be useful. But it may force us to have separate buckets for different types of requests, i.e. a small number of long running requests causing API server to reject short requests. -Heard that you might be looking into adding support for flow control (or something like it?). We may need it soon to help avoid bugs like runaway node status updates (see issue ).
I had not - the things we were looking at were the bastion changes to apiserver which will break logs and proxying into their own rest resources so they can be granularly controlled. Being able to timebox and classify requests differently would be good. ----- Original Message -----
- Ah, np, I probably misheard.
What are our plans for handling this client side? Do we want clients to handle "you're being throttled" error themselves, or do we plan to handle it in the library? I'm asking because currently kubelet does not have a 'short' retry loop, hence it tries to report NodeStatus every X (2) seconds, whether it succeed or not. Neither we have a sidechannel for heartbeat messages. This would mean, that if API server will be under heavy load, and with not-negligible probability NodeStatus reporting will be throttled, we may incorrectly mark a Node as unreachable. Currently it's not a huge problem, because X << Y, where Y is the time we wait before we decide a Node is unreachable. But because of the effort somewhere close to it'll probably get worse.
The client library should have options for retry on client.Config which include the ability to disable the behavior. Automatic retry is probably an "opt-out" behavior.

----- Original Message -----
says there are people working on rate limiting client connections to API server.
I have in the past adjusted the rate limiter to support the creation of large clusters. I also the logic. If you adjust the rate limiter settings, please make sure it is still possible to create large clusters.
I'm closing this as fixed, given the original subject. If we want to expand client-side support for retry, please open a dedicated issue. (Also note that QPS based throttling was to the client recently too)


Question: buf.WriteByte('n') } <del> func openLocalPort(lp *utilproxy.LocalPort) (utilproxy.Closeable, error) { </del> <ins> func openLocalPort(lp *utilproxy.LocalPort, isIPv6 bool) (utilproxy.Closeable, error) { </ins> // For ports on node IPs, open the actual port and hold it, even though we // use iptables to redirect traffic. // This ensures a) that it's safe to use that port and b) that (a) stays

/kind bug What happened: When creating a node port application (in this case the example guestbook) on a host server that is dual stacked and has AAAA and A DNS entries, the node port on the v6 address is open to kube-proxy and hangs. What you expected to happen: The v6 address would refuse the connection and the client would fall back onto the v4 address which would connect correctly. How to reproduce it (as minimally and precisely as possible): kubeadm init with the above, and join in some workers. Then install the guestbook application Obtain the node port with and telnet to one of the servers on that port from a dual stacked client. The client will connect and refuse to respond to 'GET /' telnet directly to the IPv4 address of the server on the port and all works as expected. Anything else we need to know?: kube-proxy is noted as listening on the port. Environment: Kubernetes version (use ): ubuntu kubectl version Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-07-17T18:53:20Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-07-17T18:43:26Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Brightbox OS (e.g. from /etc/os-release): Ubuntu 18.04.1 LTS Kernel (e.g. ): Linux srv-jidtj 4.15.0-29-generic -Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm 1.11 Others:
/sig network
Looks like kube-proxy in ipvs mode listens on the nodeport ports to ensure they're not in use by something else. It just binds and listens, it doesn't serve requests.

It binds on both ipv4 and ipv6 but never expects to receive connections because the iptables/ipvs rules intercept them, but on ipv4 clusters there is nothing stopping ipv6 connections coming in. The comment there does admit that only a bind is necessary to do this, but doing a full listen just made e2e tests easier. /cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen This now causes conformance failure on e2e tests due to the promotion of the Nodeport test in
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Still an issue on 1.16 when running in standard IPv4 mode
As I understand this thread, I have the same problem. I thought that it is a node configuration or some kubernetes flag that I didn't set but it seems it ain't.

I ask already on SO: Environment Kubernetes version (use kubectl version): Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-10-02T16:51:36Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: On premise, on virtual machines using hyper-v OS (e.g. from /etc/os-release): NAME="Ubuntu" VERSION="18.04.3 LTS (Bionic Beaver)" Kernel (e.g. uname -a): Linux kubernetes 5.0.0-29-generic # 31~18.04.1-Ubuntu SMP Thu Sep 12 18:29:21 UTC 2019 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm version: &version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-09-18T14:34:01Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
/lifecycle frozen
/assign bowei
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry.
Looking through the comments, this looks like a bug that could have a targeted fix. /remove-triage unresolved /good-first-issue /help-wanted
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Looking through the comments, this looks like a bug that could have a targeted fix.

/good-first-issue /help-wanted </details
I will attempt to solve this issue.
any success or progress? If you left this issue I would like to give it a go as a first time contributor. Thanks, Yuval
I'm still working on this as my first issue, and planning to produce a solution by 20th.
I wasn't able to tackle the issue and will not continue trying, feel free to take it.
/assign yuvalsteuer
Still, open -- anyone actively working on this? I would like to attempt if not. :) /assign rkc007
OK, again still open, doesn't look like anyone is working on this. I'd like to try it. The fix that occurs to me is simply to only listen to IPv6 addresses if the cluster is IPv6. If the e2e tests fail in this case (from looking at I don't think they will) then maybe they need to be updated. Does that make sense? What I'm not sure about is if we should do nothing with IPv6 ports or bind (to claim the port) but not listen.
/assign michaelbeaumont


Question: var _ pflag.Value = &StringSlice{} func (s *StringSlice) String() string { <ins> if s == nil || s.value == nil { return "" } </ins> return strings.Join(*s.value, " ") } func (s *StringSlice) Set(val string) error { if s.value == nil || !s.changed { <del> *s.value = make([]string, 0) </del> <ins> v := make([]string, 0) s.value = &v </ins> } *s.value = append(*s.value, val) s.changed = true

I ran and it panicked: no panic The panic was introduced by . I submitted as an attempt to fix this, but review led to the realization that there were further bugs and I don't know what the right fix is cc
/assign
/sig testing /sig cloud-provider
/triage accepted


Question: // get the init containers in reverse order ic := pod.Spec.InitContainers[len(pod.Spec.InitContainers)-i-1] <del> to.terminated[ic.Name] = make(chan struct{}) </del> <ins> channel := make(chan struct{}) to.terminated[ic.Name] = channel // if it's not a running container, pre-close the channel so nothing // waits on it if _, isRunning := runningContainers[ic.Name]; !isRunning { close(channel) } </ins> if types.IsRestartableInitContainer(&ic) { // sidecars need to wait for all main containers to exit

In a situation where during the init phase of a , a native sidecar never becomes ready (because its is failing), then the is terminated, if there are multiple startup containers, a termination signal is never received by the init container and the Pod is stuck (until is hit). All running initContainer to receive the termination signal correctly. Create a with this bash script as an entrypoint: Create a deployment with two init containers (one normal one sidecar). Add an probe which means the startupProbe never passes Create the deployment, and it'll be stuck in Init, as you'd expect: the pod and you'll see the exit signal has been sent to : Delete the deployment / clean everything up. Now, add a third : As before, the process will be stuck on because of the bad probe: However when you delete the pod this time, no exit signal is sent to , the pod is now stuck until is reached. No response GKE v1.29.4-gke. Core OS on GCP <details</details<details</details<details</details
/sig node
/assign
/triage accepted confirmed that the scenario is reproduced. The problem is caused by the fact that the native sidecars should terminate in reverse order. I'll fix the code to ignore not-running init containers. /cc
Awesome, thank you :)
sig-node meeting notes: /triage accepted /priority important-soon
FYI: confirmed that the SITERM is sent to the containers after terminationGracePeriodSeconds (and wait for the application for 2 seconds before sending SIGKILL) will fix it anyway with


Question: return } <del> baseNamespaceObj, exist, err := nc.namespaceInformerStore.GetByKey(namespace) </del> <ins> namespaceObjFromStore, exist, err := nc.namespaceInformerStore.GetByKey(namespace) </ins> if err != nil { glog.Errorf("Failed to query main namespace store for %v: %v", namespace, err) nc.deliverNamespace(namespace, 0, true)

Unit tests on PR are failing due to data race in federation-controller/namespace unittest. More logs: https://k8s-
CC
Sent to fix this


Question: } else { for _, addr := range localAddrs { if ipnet, ok := addr.(*net.IPNet); ok { <del> if ipnet.IP.To4() != nil { </del> <ins> if !ipnet.IP.IsLinkLocalUnicast() { </ins> // Filter external IP by MAC address OUIs from vCenter and from ESX vmMACAddr := strings.ToLower(i.HardwareAddr.String()) // Making sure that the MAC address is long enough

What happened: IP addresses losing in k8s node status in a pure ipv6 vsphere environment. all interfaces of nodes in this cluster are ipv6 only The error logs in kubelet as the following: What you expected to happen: It will be very appreciated if we can get ipv6 addresses from vsphere cloud provider as ipv4 env How to reproduce it (as minimally and precisely as possible): deploy k8s cluster in vsphere pure ipv6 envirenment Anything else we need to know?: From the code we can know that while the provider retrieves VM’s IP, It uses To4() function for all ip addresses from vsphere platform, this function can’t handle ipv6 addresses as mentioned in guild: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vsphere OS (e.g: ):Kernel (e.g. ):Install tools: ansible Network plugin and version (if this is a network-related bug): calico v3.5.6 Others:
If you agree with this I can fix it.
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
/sig cloud-provider
cc /remove-sig contributor-experience
/cc
please help to review, I think I can fix the issue by PR /sig cloud-provider Thanks a lot
/assign


Question: "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm" </ins> "k8s.io/kubernetes/federation/apis/federation" "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/api/events"

used to show masters, but as of it no longer does. This is not in accordance with our deprecation policy I believe. cc
That commit/PR is not relevant as there are no supported users/deployment methods that are using label. kubeadm v1.4 or v1.5 was the last. What you're really looking for is who/what removed printing things based on the label...
No blame on you The regression is that we have stopped printing masters in . There may be more to it that a simple revert of , but we should probably start there.
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
This has been fixed in recent versions


Question: Containers: []v1.Container{ { Image:   busyboxImage, <del> Name:    logContName, Command: []string{"sh", "-c", "echo " + logString}, </del> <ins> Name:    logContainerName, Command: []string{"sh", "-c", "echo " + log}, </ins> }, }, }, } <ins> } </ins> <del> podClient.Create(logPod) err := framework.WaitForPodSuccessInNamespace(f.ClientSet, logPodName, ns) framework.ExpectNoError(err, "Failed waiting for pod: %s to enter success state", logPodName) // get containerID from created Pod createdLogPod, err := podClient.Get(logPodName, metav1.GetOptions{}) logConID := kubecontainer.ParseContainerID(createdLogPod.Status.ContainerStatuses[0].ContainerID) framework.ExpectNoError(err, "Failed to get pod: %s", logPodName) expectedlogFile := logDir + "/" + logPodName + "_" + ns + "_" + logContName + "-" + logConID.ID + ".log" </del> <ins> makeLogCheckPod := func(podName, log, expectedLogPath string) *v1.Pod { </ins> hostPathType := new(v1.HostPathType) *hostPathType = v1.HostPathType(string(v1.HostPathFileOrCreate)) <del> checkPod := &v1.Pod{ </del> <ins> return &v1.Pod{ </ins> ObjectMeta: metav1.ObjectMeta{ <del> Name: checkPodName, </del> <ins> Name: podName, </ins> }, Spec: v1.PodSpec{ // this pod is expected to exit successfully

The should be updated to check CRI log paths.
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
May I try to help with this?
GitHub didn't allow me to assign the following users: fatsheep9146. Note that only and repo collaborators can be assigned. 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


Question: <ins> apiVersion: apps/v1 kind: Deployment metadata: name: test spec: replicas: 3 selector: matchLabels: name: test template: metadata: labels: name: test spec: containers: - name: nginx image: nginx </ins>

What happened: I get a diff, when I specify a file directly, but on recursive mode, no diff is shown anymore: What you expected to happen: Recursive mode should work How to reproduce it (as minimally and precisely as possible): Have a bunch of YAML manifest, but with name collisions, e.g. Service , Deployment , etc Anything else we need to know?: I think the problem is that all objects have the same name, which should not be a problem per se. Only heapster-binding has a different name, and looking at the generated temp files, only and are present: Environment: Kubernetes version (use ): $ kubectl version --short Client Version: v1.13.0 Server Version: v1.13.0 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
I think the files are overwriting each other?
Yeah, good catch, I'll try to fix that asap
Thanks! By the way, very nice work with dry-run and diff. I was waiting for this.
Feel free to look at the PR and give your opinion!


Question: "//pkg/kubelet/container:go_default_library", "//pkg/kubelet/events:go_default_library", "//pkg/kubelet/images:go_default_library", <ins> "//pkg/kubelet/kuberuntime/logs:go_default_library", </ins> "//pkg/kubelet/lifecycle:go_default_library", "//pkg/kubelet/metrics:go_default_library", "//pkg/kubelet/prober/results:go_default_library",

We should make the CRI log parsing code in kubelet to be a library. So that container runtimes and external tools don't need to copy the whole code ( vendor it instead ). Referring
/assign
/sig node
I can help on it.
/assign
GitHub didn't allow me to assign the following users: yanxuean. Note that only can be assigned. <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
Thanks. I have a branch ready for this. Will open a PR later and ping you when it is out.
ok


Question: DialTimeout:          dialTimeout, DialKeepAliveTime:    keepaliveTime, DialKeepAliveTimeout: keepaliveTimeout, <del> Endpoints:            c.ServerList, TLS:                  tlsConfig, </del> <ins> DialOptions: []grpc.DialOption{ grpc.WithUnaryInterceptor(grpcprom.UnaryClientInterceptor), grpc.WithStreamInterceptor(grpcprom.StreamClientInterceptor), }, Endpoints: c.ServerList, TLS:       tlsConfig, </ins> } client, err := clientv3.New(cfg) return client, err

/kind feature Can we provide a way to enable etcd clientv3 prometheus metrics at the apiserver side ? The etcd.clientv3 interface is instantiated and it does not enable metrics. In file in coreos/etcd, one can see the to pass to enable metrics. It would be great if the apiserver has a command line parameter, config/environment variable to enable etcd.clientv3 metrics.
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
This issue is quite similar to
Yes, this is a good idea, in fact we just released a new version of the package required for this.
/assign
I can do it.
oh, maybe I should use the new features to implement, I will continue to modify it.
are you referring to injecting the registry to use? Yes I would very much appreciate that, even if we (for now) inject the , that will allow us to modify that more easily in the future.


Question: return p } <ins> // NominatedNodeName sets `n` as the .Status.NominatedNodeName of the inner pod. func (p *PodWrapper) NominatedNodeName(n string) *PodWrapper { p.Status.NominatedNodeName = n return p } </ins> // PodAffinityKind represents different kinds of PodAffinity. type PodAffinityKind int

What happened: When a Pod's nominated node is considered as UnschedulableAndUnresolvable in the filter stage, the scheduler doesn't consider that pod for preemption even there are pods can be preempted on another node. What you expected to happen: When the pod's nominated node is considered as 'UnschedulableAndUnresolvable ' (For example, the taint being by those conditions, ), the scheduler should try to preemption on other nodes. How to reproduce it (as minimally and precisely as possible): Create low priority pod, which schedule to nodeA Create mid priority pod, which schedule to nodeB Create high priority pod, which preempt the low priority pod on nodeA, and set high priority pod's nominated node as nodeA The nodeA's kubelet is down, the node life cycle controller taint the nodeA with '' (or taint with disk ) before low priority pod finishes the termination. The high priority pod is keeping as pending status. The scheduler doesn't try to preempt the mid-priority pod on nodeB Anything else we need to know?: Environment: Kubernetes version (use ): 18.0 Cloud provider or hardware configuration: baremetal OS (e.g: ): ubuntu1804 Kernel (e.g. ): 0-46-generic Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig scheduling
/assign
This seems to be a duplicate of .
actually, I found this case after review . I file this issue since I feel it should be another case. The want to cleanup the nomnated node for cluster autoscaler. This is case need to allow the pod to preempt on other nodes again even it has a nomanted node. But I may understand incorrectly, please mark it duplicated if I'm wrong. Thanks for help anyway. :)
If the nominatedNodeName can be cleared properly in any case, this issue will no longer exist. From this point of view, I'd say this issue is a sub-case of .
BTW: in your description, if "The nodeA is down", how it comes out "a Pod's nominated node is considered as UnschedulableAndUnresolvable in the filter stage"? nodeA should NOT have existed in the result of Filter(), right?

(if the nodeA is just being shutdown, we still treat it as a normal node)
If the NodeA is down, the node life cycle controller will add taint '' to the node, then the TaintToleration filter will return 'UnschedulableAndUnresolvable '. It also means that it isn't only about nodeA is down, there are other conditions in this ' to return 'UnschedulableAndUnresolvable'. Beyond the TaintToleration filter, other filters may return 'UnschedulableAndUnresolvable' also, as my understanding, that means that node won't be available for that pod anymore, then we should try other nodes for preemption.
then we should better describe it as "being applied with a Taint", which is more general. When you say "node is down", it usually refers to the node is deleted physically.
I got it, thanks again! let me correct it
Also it's different from . Let's not mention "node is down" in the description to avoid confusion.
thanks, done :)


Question: visibility = ["//visibility:public"], deps = [ "//pkg/scheduler/algorithm/predicates:go_default_library", <del> "//pkg/scheduler/algorithm/priorities:go_default_library", </del> "//pkg/scheduler/framework/plugins/migration:go_default_library", "//pkg/scheduler/framework/v1alpha1:go_default_library", "//pkg/scheduler/listers:go_default_library",

/sig scheduling /priority important-soon See as an example. /assign
/unassign /help
/assign
/remove-help


Question: resourceinformers "k8s.io/client-go/informers/resource/v1alpha2" "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/cache" <ins> "k8s.io/client-go/util/flowcontrol" </ins> "k8s.io/client-go/util/workqueue" "k8s.io/klog/v2" drapb "k8s.io/kubelet/pkg/apis/dra/v1alpha3"

has to retry after failures. This currently uses a fixed 5 second delay to avoid busy-looping. Exponential backoff might be better. /sig node /triage-accepted /priority important-longterm /lifecycle frozen /assign
/triage accepted
/assign


Question: PROXY_PORT=$(kube::util::get_random_port) kube::log::status "On try ${retry}, use proxy port ${PROXY_PORT} if it's free" if kube::util::test_host_port_free "127.0.0.1" "${PROXY_PORT}"; then <del> # the --www and --www-prefix are just to make something definitely show up for # wait_for_url to see. kubectl proxy -p ${PROXY_PORT} --www=. --www-prefix=/healthz "$@" 1>&2 & break </del> <ins> if [ $# -eq 0 ]; then kubectl proxy -p ${PROXY_PORT} --www=. 1>&2 & break else kubectl proxy -p ${PROXY_PORT} --www=. --api-prefix="$1" 1>&2 & break fi </ins> fi sleep 1; done PROXY_PID=$! <del> kube::util::wait_for_url "http://127.0.0.1:${PROXY_PORT}/healthz" "kubectl proxy $@" </del> <ins> if [ $# -eq 0 ]; then kube::util::wait_for_url "http://127.0.0.1:${PROXY_PORT}/healthz" "kubectl proxy" else kube::util::wait_for_url "http://127.0.0.1:${PROXY_PORT}/$1/healthz" "kubectl proxy --api-prefix=$1" fi </ins> } function cleanup()

Now that we've moved the experimental api to /apis/experimental... it's inaccessible from by default. We should fix that. who stepped on this earlier
security questions for you: this prefix was apparently in response to a security review quite some time ago. I don't understand how this adds much security. Can we just remove it? If not, is it acceptable to change the default from "/api/" to "/api", which would match both api locations? Otherwise we'll have to take a comma-separated list or something...
Ref
Oh, so this is not related to the security requests! And the original use case was just to re-root the URL path so it didn't interfere with static content. Sorry, I got confused because the last time I monkeyed with that, it was in conjunction with the allow/deny list that actually was the security request. In that case, let's see if we can change the default to "/", if that will break anything.
That change got introduced as part of to protect against XSRF in kubectl proxy. But I think the more important part of that change was that it disallows POST/PUT/PATCH by default. So as long as there is no state changing action outside of /api/ that can be triggered with a GET it should be safe to remove.


Question: fmt.Fprintf(out, "      %s:t%sn", name, quantity.String()) } <del> switch { case state.Running != nil: fmt.Fprintf(out, "    State:tRunningn") fmt.Fprintf(out, "      Started:t%vn", state.Running.StartedAt.Time.Format(time.RFC1123Z)) case state.Waiting != nil: fmt.Fprintf(out, "    State:tWaitingn") if state.Waiting.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", state.Waiting.Reason) } case state.Terminated != nil: fmt.Fprintf(out, "    State:tTerminatedn") if state.Terminated.Reason != "" { fmt.Fprintf(out, "      Reason:t%sn", state.Terminated.Reason) } if state.Terminated.Message != "" { fmt.Fprintf(out, "      Message:t%sn", state.Terminated.Message) } fmt.Fprintf(out, "      Exit Code:t%dn", state.Terminated.ExitCode) if state.Terminated.Signal > 0 { fmt.Fprintf(out, "      Signal:t%dn", state.Terminated.Signal) } fmt.Fprintf(out, "      Started:t%sn", state.Terminated.StartedAt.Time.Format(time.RFC1123Z)) fmt.Fprintf(out, "      Finished:t%sn", state.Terminated.FinishedAt.Time.Format(time.RFC1123Z)) default: fmt.Fprintf(out, "    State:tWaitingn") </del> <ins> describeStatus("State", state, out) if status.LastTerminationState.Terminated != nil { describeStatus("Last Termination State", status.LastTerminationState, out) </ins> } fmt.Fprintf(out, "    Ready:t%vn", printBool(status.Ready)) fmt.Fprintf(out, "    Restart Count:t%dn", status.RestartCount) fmt.Fprintf(out, "    Variables:n")

Problem When a container is killed and restarted because, for example, it hit memory limits, the output only shows an increasing but no reason for why the container was killed: We can find the reason by inspecting the pod object ( shows as with ): Suggested Solution Modify to print termination reason, if available.
When this merges, need to update Search for in that doc.
Solved with .


Question: "github.com/emicklei/go-restful/swagger" "k8s.io/kubernetes/pkg/api/meta" <ins> apiutil "k8s.io/kubernetes/pkg/api/util" </ins> client "k8s.io/kubernetes/pkg/client/unversioned" )

It would be nice if let me explain experimental resources to aid users ability to experiment.
It's possible this works today, but it was non-obvious how to use. Attempts:
cc
cc
No, this isn't supported, since current implementation only use v1 Client but not experimental Client.
do we need to fix this for 1.1?
How difficult do you think it would be to fix?
It has dependency on ServerAPIVersions(), for which we plan to make a clean-up PR. I guess it needs 3-4 days to get two PRs merged.
With , this can be fixed now. What's the expected behavior of ? I assume in case of , it should search hpa in both v1 and extensions/v1bata1, and determines hpa as a resource in the extensions group? BTW, the use of "api-version" flag is problematic It adds extra meaning to the generic "api-version" flag.


Question: } } <del> func TestApplySeccompVersionSkew(t *testing.T) { const containerName = "container" testProfile := "test" for _, test := range []struct { description string pod         *api.Pod validation  func(*testing.T, *api.Pod) }{ { description: "Security context nil", pod:         &api.Pod{}, validation: func(t *testing.T, pod *api.Pod) { require.NotNil(t, pod) }, }, { description: "Security context not nil", pod: &api.Pod{ Spec: api.PodSpec{SecurityContext: &api.PodSecurityContext{}}, }, validation: func(t *testing.T, pod *api.Pod) { require.NotNil(t, pod) }, }, { description: "Field set and no annotation present", pod: &api.Pod{ Spec: api.PodSpec{ SecurityContext: &api.PodSecurityContext{ SeccompProfile: &api.SeccompProfile{ Type: api.SeccompProfileTypeUnconfined, }, }, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Len(t, pod.Annotations, 0) }, }, { description: "Annotation 'unconfined' and no field present", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompPodAnnotationKey: v1.SeccompProfileNameUnconfined, }, }, Spec: api.PodSpec{}, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeUnconfined, pod.Spec.SecurityContext.SeccompProfile.Type) require.Nil(t, pod.Spec.SecurityContext.SeccompProfile.LocalhostProfile) }, }, { description: "Annotation 'runtime/default' and no field present", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompPodAnnotationKey: v1.SeccompProfileRuntimeDefault, }, }, Spec: api.PodSpec{SecurityContext: &api.PodSecurityContext{}}, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeRuntimeDefault, pod.Spec.SecurityContext.SeccompProfile.Type) require.Nil(t, pod.Spec.SecurityContext.SeccompProfile.LocalhostProfile) }, }, { description: "Annotation 'docker/default' and no field present", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompPodAnnotationKey: v1.DeprecatedSeccompProfileDockerDefault, }, }, Spec: api.PodSpec{SecurityContext: &api.PodSecurityContext{}}, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeRuntimeDefault, pod.Spec.SecurityContext.SeccompProfile.Type) require.Nil(t, pod.Spec.SecurityContext.SeccompProfile.LocalhostProfile) }, }, { description: "Annotation 'localhost/test' and no field present", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompPodAnnotationKey: v1.SeccompLocalhostProfileNamePrefix + testProfile, }, }, Spec: api.PodSpec{SecurityContext: &api.PodSecurityContext{}}, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeLocalhost, pod.Spec.SecurityContext.SeccompProfile.Type) require.Equal(t, testProfile, *pod.Spec.SecurityContext.SeccompProfile.LocalhostProfile) }, }, { description: "Annotation 'localhost/' has zero length", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompPodAnnotationKey: v1.SeccompLocalhostProfileNamePrefix, }, }, Spec: api.PodSpec{SecurityContext: &api.PodSecurityContext{}}, }, validation: func(t *testing.T, pod *api.Pod) { require.Nil(t, pod.Spec.SecurityContext.SeccompProfile) }, }, { description: "Security context nil (container)", pod: &api.Pod{ Spec: api.PodSpec{ Containers: []api.Container{{}}, }, }, validation: func(t *testing.T, pod *api.Pod) { require.NotNil(t, pod) }, }, { description: "Security context not nil (container)", pod: &api.Pod{ Spec: api.PodSpec{ Containers: []api.Container{{ SecurityContext: &api.SecurityContext{}, }}, }, }, validation: func(t *testing.T, pod *api.Pod) { require.NotNil(t, pod) }, }, { description: "Field set and no annotation present (container)", pod: &api.Pod{ Spec: api.PodSpec{ Containers: []api.Container{ { Name: containerName, SecurityContext: &api.SecurityContext{ SeccompProfile: &api.SeccompProfile{ Type: api.SeccompProfileTypeUnconfined, }, }, }, }, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Len(t, pod.Annotations, 0) }, }, { description: "Multiple containers with fields (container)", pod: &api.Pod{ Spec: api.PodSpec{ Containers: []api.Container{ { Name: containerName + "1", SecurityContext: &api.SecurityContext{ SeccompProfile: &api.SeccompProfile{ Type: api.SeccompProfileTypeUnconfined, }, }, }, { Name: containerName + "2", }, { Name: containerName + "3", SecurityContext: &api.SecurityContext{ SeccompProfile: &api.SeccompProfile{ Type: api.SeccompProfileTypeRuntimeDefault, }, }, }, }, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Len(t, pod.Annotations, 0) }, }, { description: "Annotation 'unconfined' and no field present (container)", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompContainerAnnotationKeyPrefix + containerName: v1.SeccompProfileNameUnconfined, }, }, Spec: api.PodSpec{ Containers: []api.Container{{ Name: containerName, }}, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeUnconfined, pod.Spec.Containers[0].SecurityContext.SeccompProfile.Type) require.Nil(t, pod.Spec.Containers[0].SecurityContext.SeccompProfile.LocalhostProfile) }, }, { description: "Annotation 'runtime/default' and no field present (container)", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompContainerAnnotationKeyPrefix + containerName: v1.SeccompProfileRuntimeDefault, }, }, Spec: api.PodSpec{ Containers: []api.Container{{ Name:            containerName, SecurityContext: &api.SecurityContext{}, }}, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeRuntimeDefault, pod.Spec.Containers[0].SecurityContext.SeccompProfile.Type) require.Nil(t, pod.Spec.Containers[0].SecurityContext.SeccompProfile.LocalhostProfile) }, }, { description: "Annotation 'docker/default' and no field present (container)", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompContainerAnnotationKeyPrefix + containerName: v1.DeprecatedSeccompProfileDockerDefault, }, }, Spec: api.PodSpec{ Containers: []api.Container{{ Name:            containerName, SecurityContext: &api.SecurityContext{}, }}, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeRuntimeDefault, pod.Spec.Containers[0].SecurityContext.SeccompProfile.Type) require.Nil(t, pod.Spec.Containers[0].SecurityContext.SeccompProfile.LocalhostProfile) }, }, { description: "Multiple containers by annotations (container)", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompContainerAnnotationKeyPrefix + containerName + "1": v1.SeccompLocalhostProfileNamePrefix + testProfile, v1.SeccompContainerAnnotationKeyPrefix + containerName + "3": v1.SeccompProfileRuntimeDefault, }, }, Spec: api.PodSpec{ Containers: []api.Container{ {Name: containerName + "1"}, {Name: containerName + "2"}, {Name: containerName + "3"}, }, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeLocalhost, pod.Spec.Containers[0].SecurityContext.SeccompProfile.Type) require.Equal(t, testProfile, *pod.Spec.Containers[0].SecurityContext.SeccompProfile.LocalhostProfile) require.Equal(t, api.SeccompProfileTypeRuntimeDefault, pod.Spec.Containers[2].SecurityContext.SeccompProfile.Type) }, }, { description: "Annotation 'localhost/test' and no field present (container)", pod: &api.Pod{ ObjectMeta: metav1.ObjectMeta{ Annotations: map[string]string{ v1.SeccompContainerAnnotationKeyPrefix + containerName: v1.SeccompLocalhostProfileNamePrefix + testProfile, }, }, Spec: api.PodSpec{ Containers: []api.Container{{ Name:            containerName, SecurityContext: &api.SecurityContext{}, }}, }, }, validation: func(t *testing.T, pod *api.Pod) { require.Equal(t, api.SeccompProfileTypeLocalhost, pod.Spec.Containers[0].SecurityContext.SeccompProfile.Type) require.Equal(t, testProfile, *pod.Spec.Containers[0].SecurityContext.SeccompProfile.LocalhostProfile) }, }, } { output := &api.Pod{ ObjectMeta: metav1.ObjectMeta{Annotations: map[string]string{}}, } for i, ctr := range test.pod.Spec.Containers { output.Spec.Containers = append(output.Spec.Containers, api.Container{}) if ctr.SecurityContext != nil && ctr.SecurityContext.SeccompProfile != nil { output.Spec.Containers[i].SecurityContext = &api.SecurityContext{ SeccompProfile: &api.SeccompProfile{ Type:             api.SeccompProfileType(ctr.SecurityContext.SeccompProfile.Type), LocalhostProfile: ctr.SecurityContext.SeccompProfile.LocalhostProfile, }, } } } applySeccompVersionSkew(test.pod) test.validation(t, test.pod) } } </del> func newPodWithHugePageValue(resourceName api.ResourceName, value resource.Quantity) *api.Pod { return &api.Pod{

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: def := ing.Spec.DefaultBackend ns := ing.Namespace if def == nil { <del> // Ingresses that don't specify a default backend inherit the // default backend in the kube-system namespace. def = &networkingv1.IngressBackend{ Service: &networkingv1.IngressServiceBackend{ Name: "default-http-backend", Port: networkingv1.ServiceBackendPort{ Number: 80, }, }, } ns = metav1.NamespaceSystem </del> <ins> w.Write(LEVEL_0, "Default backend:t<default>n") } else { w.Write(LEVEL_0, "Default backend:t%sn", i.describeBackendV1(ns, def)) </ins> } <del> w.Write(LEVEL_0, "Default backend:t%sn", i.describeBackendV1(ns, def)) </del> if len(ing.Spec.TLS) != 0 { describeIngressTLSV1(w, ing.Spec.TLS) }

I ran on a fresh minikube with no other services in it and saw this output. Which suggests there is a service in the cluster called (there isn't), and further suggests there is something wrong (there isn't) because there are no endpoints found. I expected to provide me with an accurate description of my Ingress object. This behaviour appears to be hardcoded into the kubectl describe command. Which contains a comment suggesting that this is default behaviour, but no logic to check if the service actually exists before attempting to default to it. <details</details<details</details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cli
See also do you know the history here?
not beyond what shows: Looks like an (incorrect) assumption in the describer that the only implementation would behave in this way
/assign
work in progress...
when you get the PR up please link this issue and in it and ping me directly on slack to get a fast review. I agree with what was stated here and in the other issue, that this seems like an unnecessary assumption that should've not been there, we probably should just leave it empty or per print as the value.


Question: if preemptor.Spec.NodeName != test.runnningNode { t.Errorf("Expect pod running on %v, got %v.", test.runnningNode, preemptor.Spec.NodeName) } <del> pods = append(pods, preemptor) // cleanup defer testutils.CleanupPods(cs, t, pods) cs.CoreV1().Nodes().DeleteCollection(context.TODO(), metav1.DeleteOptions{}, metav1.ListOptions{}) </del> }) } }

<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Integration tests are sometimes flaking locally: PreferNominatedNode Once the node gets deleted, the nodelifecycle controller is racing to update pod status and the pod deletion logic is failing causing tests to flake. Ultimately, we call testCtx.CleanUp() which cleans the nodes and the pods involved the test namespace so we are not going to leak any resources. links to appreciated links to specific failures in spyglass appreciated <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --/sig scheduling <!-- Please see the deflaking doc () for more guidance! --/assign
cc Tried addressing it via
/triage accepted thanks!


Question: return instances, nil } <del> func (gce *GCECloud) GetZone() (string, error) { return gce.zone, nil </del> <ins> func (gce *GCECloud) GetZone() (Zone, error) { region, err := getGceRegion(gce.zone) if err != nil { return Zone{}, err } return Zone{ FailureDomain: gce.zone, Region:        region, }, nil } // gce zone names are of the form: ${region-name}-${ix}. // For example "us-central1-b" has a region of "us-central1". // So we look for the last '-' and trim to just before that. func getGceRegion(zone string) (string, error) { ix := strings.LastIndex(zone, "-") if ix == -1 { return "", fmt.Errorf("unexpected zone: %s", zone) } return zone[:ix], nil </ins> }

Comments that the PR bot adds solely to trigger email notification of a label change, should be immediately deleted by the bot after it adds them. I have no idea what team to assign this to... cc/
, David Oppenheimer wrote:
(Motivation, of course, is to avoid having PR threads that are 90% bot comments...)
should really be an issue over in that's where (some of) the bots live. Lets make a list of which comments we want deleted immediately. [x] Label size. [x] Needs rebase. [x] test this stale CI [x] test this pending CI [x] PR changed after LGTM, removing LGTM. [x] Comment about blocking based on the paths touched (old docs) [x] unapproved cherrypick comment [x] cherrypicks must set a milestone [x] ok to test from bot I don't want to make it all comments. There are way too many times people have asked me "Why did the bot add 'do-not-merge'?" and I can just link them the comment 2 lines above which tells exactly why....
"Test this" with an issue is also useful, isn't it? On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
OK to test Add to whitelist On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
I was envisioning deleting the by the bot. (every 48 hours after LGTM, when retesting right before merge) not those by users (with an issue) After LGTM the bot will add , that one I can remove. The request to comes from the jenkins bot. And in that I am clueless...
any interest in a review (I'm trying to not just self merge all my own bot changes). This deleted hundreds and hundreds of comments.
Looks like reviewed it since your last message:

The contains instructions for downloading kubectl. The doesn't contain these instructions but it should if it's now the recommended way of running Kubernetes locally.
+1 Just ran into this.
cc
By the way, we encourage anyone to propose improvements/fixes to docs. You can do so pretty easily by clicking the pencil icon in the top right corner of every page of
kubectl download instructions to the guide in


Question: "//staging/src/k8s.io/apimachinery/pkg/util/uuid:go_default_library", "//staging/src/k8s.io/legacy-cloud-providers/azure:go_default_library", "//test/e2e/framework:go_default_library", <ins> "//vendor/github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2019-07-01/compute:go_default_library", </ins> ], )

I am trying to run Azure e2e tests: The test creates a volume in the cloud + runs a pod with the volume as in-line. The pod never starts: The test creates a "blob" disk, while the Azure machine expects "managed" disk. Does anyone run storage e2e tests on Azure regularly? Was it ever working? Managed disks are provisioned . Should the test suite create "managed" disks by default too? Environment: Kubernetes version (use ): v1.17.0-alpha.0.1089+-dirty
/sig azure
/sig cloud-provider
managed disk should be the default, the azure disk storage class in the test case may have
The volume is created outside of kubernetes dynamic provisioning to test pre-provisioned and inline volumes: I wonder if anyone actually runs the tests.


Question: } return false, err }) <del> if err != nil { framework.DescribeSvc(namespace) framework.Failf("Error in deleting service %s: %v", serviceName, err) } </del> <ins> return err </ins> } func cleanupServiceShardsAndProviderResources(namespace string, service *v1.Service, clusters fedframework.ClusterSlice) {

In order to support running tests in parallel, we randomized NodePort selection. There appears to be some evidence that this is not sufficient and is causing e2e test flakes: https://k8s-
Hi, As a need contributor, I'm interesting of solving this issue. I already check the current code, and propose to retry the service creation until success or all possible ports (between FederatedSvcNodePortFirst and FederatedSvcNodePortLast) have been tried. If this approach is fine for you, I can submit a PR soon.
How do you plan to check if the NodePorts are available? In our presubmit test environment, tests run across many instances of federation control planes in parallel, but share the same underlying clusters. So this approach might be viable depending on how and where you plan to check for these used NodePorts.
my approach for getting an available port is a "Dummy" approach: create a list of possible available port, get one of them randomly, then try to create the Service. If Service creation failed. try to use another possible available port, until service creation success or all possible available ports have been tested.
Sounds reasonable to me. Go for it. A couple of caveats: need to create a real list, you could just use the range boundaries. careful about service creation failure. You need to check if the service shard creation failed in the underlying clusters and rollback all those shards before retrying.
thanks for the caveats, I will do soon a PR.
Hi, what is the state of this issue? Is working in this issues with the others issues related to e2e tests?
has a PR to fix this issue -