Question: lastUpdate     time.Time } <ins> type vmssEntry struct { vmss       *compute.VirtualMachineScaleSet lastUpdate time.Time } func (ss *scaleSet) newVMSSCache() (*timedCache, error) { getter := func(key string) (interface{}, error) { localCache := &sync.Map{} // [vmssName]*vmssEntry allResourceGroups, err := ss.GetResourceGroups() if err != nil { return nil, err } for _, resourceGroup := range allResourceGroups.List() { allScaleSets, err := ss.VirtualMachineScaleSetsClient.List(context.Background(), resourceGroup) if err != nil { klog.Errorf("VirtualMachineScaleSetsClient.List failed: %v", err) return nil, err } for _, scaleSet := range allScaleSets { if scaleSet.Name == nil || *scaleSet.Name == "" { klog.Warning("failed to get the name of VMSS") continue } localCache.Store(*scaleSet.Name, &vmssEntry{ vmss:       &scaleSet, lastUpdate: time.Now().UTC(), }) } } return localCache, nil } return newTimedcache(vmssTTL, getter) } </ins> func extractVmssVMName(name string) (string, string, error) { split := strings.SplitAfter(name, vmssNameSeparator) if len(split) < 2 {

<!-- 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: Recently we upgraded our cluster from 1.14.4 to 1.14.7. Then we started to observe tons of following errors: I guess the cause may be related to this line which was introduced recently: As we have hundreds of services with LoadBalancer type, and we also enable cluster-autoscaler, the nodes list change very often. For each service, there will be one call to GetScaleSet. The quota will be exhausted quickly. When fails, new nodes created by cluster-autoscaler will lose connectivity to load balancer. What you expected to happen: Kubernetes should not hit VMSS throttling threshold. How to reproduce it (as minimally and precisely as possible): a cluster with aks-engine. Use VMSS. 200 services with LoadBalancer type. up VMSS to 50 nodes down VMSS to 60 nodes scaling up and down VMSS Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.7 Cloud provider or hardware configuration: Azure, VMSS OS (e.g: ): Ubuntu Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure
I create a PR to mitigate the issue.
do we have a rough num about how this PR would mitigate this issue? looks like we need to cherry-pick this PR to old releases. it's better if we have a rough estimation.
The revised version of code calls instead of azure API. The cache refreshes itself every 10 min. I believe this will solve the throttling issue.
I believe we're being affected by this. Apart from getting the - when creating our to use a pre-configured Azure Public IP, the ingress appears to be getting a different IP each time
Thank you all!
The PR is merged. Does your issue remain?

pls cherry-pick that fix to old release, thanks
Cherry picked to release 1.14-1.16
I’ll retry today and let you know Wysłane z iPhone'a
Issue returned in K8S 1.15.4 Warning UpdateLoadBalancerFailed service/nginx-ingress-controller Error updating load balancer with new hosts map[<nodes names]: [EnsureHostInPool(ingress/nginx-ingress-controller): backendPoolID(/subscriptions/<subscription/resourceGroups/<rg/providers/Microsoft.Network/loadBalancers/<rg/backendAddressPools/<rg) - failed to ensure host in pool: "azure - cloud provider rate limited(read) for operation:VMSSGet", EnsureHostInPool(ingress/nginx-ingress-controller):


Question: "fmt" "math/rand" "sync" <ins> "sync/atomic" </ins> "testing" "time"

We use a to nil out the : However on a re-sync, this results in a data race that was observed when running unit tests: The read had occurred previously during a callback. On re-sync, the retrieves every object from the cache, invokes the transform function, and re-queues them. However, the object instances are the same as those stored in the cache so mutating them outside the cache without lock protection is unsafe. It is documented that the "TransformFunc sees the object before any other actor, and it is now safe to mutate the object in place instead of making a copy" however this is not the case on a re-sync. The should make a copy of the objects retrieved from the cache store on a re-sync or perhaps elide the on a re-sync since the objects would already have been transformed. As a workaround, I changed our to only nil the if not already nil but this is a latent bug that others will likely run into.
/assign That means that and introduced possible panic regressions into kube-controller-manager and kube-scheduler /priority critical-urgent /kind regression
/transfer kubernetes
/sig api-machinery
kube-controller-manager and kube-scheduler do the same in 1.29+ and likely have the same issue
I think delete has the same problem, and replace may have the same problem: Passing the same object to the transformer after it is already in the cache is unsafe and we should not do that at all.
/assign /cc
Looking into this. I may take time to come up with a proper fix. But would like to evaluate the risk for the current situation. Not entirely sure how delete and replace would be triggered in normal settings, but resync is fortunately low frequency as the default setting for resync period is between 12h and 24h for (--min-resync-period duration Default: 12h0m0s, see ) . As for the resync function is Just think out aloud, I read a thread discussion somewhere that resync was a mechanism in the past to prevent data inconsistency due to bugs but client-go has been mature these days, resync is no-longer needed in theory but for a safe guard. So maybe disabling resync is a reasonable fix if delete/replace can be fixed.
You're mixing resync with relist - I believe relist is no longer needed. Resync is actually used.

FWIW - I opened an initial version of the fix:
I think it's resync. The thread I mentioned is
/triage accepted


Question: return 0 } if requested > capacity { <del> glog.V(4).Infof("Combined requested resources %d from existing pods exceeds capacity %d on node %s", </del> <ins> glog.V(10).Infof("Combined requested resources %d from existing pods exceeds capacity %d on node %s", </ins> requested, capacity, node) return 0 }

Problem There are at least some examples of over logging in the scheduler. Solution Go through glog.Info and make sure we are consistently managing logs. At least one example to solve in an easy PR has shared with us.. Ill confirm this is happening still in upstream kube and fix as well as audit the others.
part of
yeah lets de-dupe the tickets, we have 3+ issues on this now.. closing this one. just submit the PRs and reference one of the other tickets.


Question: <ins> # This Fluentd configuration file enables the collection of log files # that can be specified at the time of its creation in an environment # variable, assuming that the config_generator.sh script runs to generate # a configuration file for each log file to collect. # Logs collected will be sent to the Google Cloud Logging API. # # Currently the collector uses a text format rather than allowing the user # to specify how to parse each file. # # This configuration assumes the correct installation of the the Google # Fluentd plug-in, and that the VM host running this configuration is on # Google Compute Engine and has been created with the logging.write scope. # Pick up all the auto-generated input config files, one for each file # specified in the FILES_TO_COLLECT environment variable. @include files/* # All the auto-generated files should use the tag "file.<filename>". <match file.**> type google_cloud flush_interval 5s # Never wait longer than 5 minutes between retries. max_retry_wait 300 # Disable the limit on the number of retries (retry forever). disable_retry_limit </match> </ins>

We should provide a dockerfile for a pre-configured Fluentd image that can be passed file paths to collect logs from. We'll likely want one for exporting to elasticsearch and one for exporting to Google Cloud Logging, as we have today for the per-node stdout/stderr collectors. How to collect log files from within a container is a question that comes up occasionally (including ), and it provides a strong example of the usefulness of sidecar containers. cc
A controller that keeps one instance of a pod alive on each node would be useful for this. Shall I go ahead and write such a controller?
Would it be? This is intended to run as a sidecar container in a pod with the user's actual application. I think a pod-per-node controller is orthogonal (and is being discussed in and ). I'll create the actual Dockerfile, and a quick example of how to use it.
Sorry, my rush to catch up I think I mis-understood this thread.


Question: - 4.096 - 8.192 - 16.384 <ins> - name: controller_admission_duration_seconds subsystem: admission namespace: apiserver help: Admission controller latency histogram in seconds, identified by name and broken out for each operation and API resource and type (validate or admit). type: Histogram stabilityLevel: STABLE labels: - name - operation - rejected - type buckets: - 0.005 - 0.025 - 0.1 - 0.5 - 1 - 2.5 - name: step_admission_duration_seconds subsystem: admission namespace: apiserver help: Admission sub-step latency histogram in seconds, broken out for each operation and API resource and step type (validate or admit). type: Histogram stabilityLevel: STABLE labels: - operation - rejected - type buckets: - 0.005 - 0.025 - 0.1 - 0.5 - 1 - 2.5 - name: webhook_admission_duration_seconds subsystem: admission namespace: apiserver help: Admission webhook latency histogram in seconds, identified by name and broken out for each operation and API resource and type (validate or admit). type: Histogram stabilityLevel: STABLE labels: - name - operation - rejected - type buckets: - 0.005 - 0.025 - 0.1 - 0.5 - 1 - 2.5 - name: apiserver_current_inflight_requests help: Maximal number of currently used inflight request limit of this apiserver per request kind in last second. type: Gauge stabilityLevel: STABLE labels: - request_kind </ins> - name: apiserver_request_duration_seconds help: Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component.

I would like to propose the graduation of the following apiserver metrics from alpha to stable: With the exception of the metric these metrics have been stable for 2 years. The metric has been stable for 12 months.
/sig api-machinery /sig instrumentation
/assign /triage accepted
I'm okay with promoting all of these except I am hesitant about since it is relatively new. Can we omit that one?
I agree with the metric was patched a year ago as part of , so it would be best to wait a bit more until the majority of Kubernetes users catch up to the patched version and start using the new version of the metric in production.
A couple of renaming suggestions, since it is important to get it right before graduation: apiserverresponsesizes =apiserverresponsesizebytes aggregatorunavailableapiservice =aggregatorunavailableapiservices One concern regarding . It was very recently changed but the change was later reverted by In the end, the metric wasn't really changed, but it might raise the concern that some users may still need additional information from this metric so I am on the fence with this one. Side implementation note that we will need to keep in mind if we graduate is that the graduation should only affect the webhook admission metric and not the other, so we will need to pass the stability level to
Thank you and for the feedback. To clarify then, are the decisions to not graduate and final?
I'm actually okay with , the namespace addition was recent but it was a bad idea and was reverted. It has otherwise been in use for quite some time, so I'd be comfortable with promoting it.
I'm willing to make a PR for this one
+1 it wasn't a hard no from my side, just wanted to raise some concerns in case anyone had an objection.
/assign /unassign
Thank you for the feedback, and To summarize, we are in agreement to graduate all but the metric. Please correct me if I'm wrong.
/cc
since all the three metrics that are created with this function are graduating to stable, do you think I should still pass the to the function or should I just set the metrics created by this functions as stable by default? update: Seems like is designed to parse whatever's in front of . So putting a variable there (that is passed to the function) will cause the script to fail. Please correct me if I'm wrong.

update: Even setting the metrics to be stable by default will cause the script to fail and you'll get an error saying for the following line: It appears that the name of the stable metrics should be given to that object as a string and using the output of a function ( in this case) will cause the script to fail.
The PR is ready to be reviewed:


Question: if err != nil { return err } <ins> outputObj = cmdutil.AsDefaultVersionedOrOriginal(outputObj, mapping) </ins> printer, err := o.ToPrinter(operation) if err != nil {

https://k8s- This test is currently failing in sig-release master-blocking and upgrade suites since late 5/11. . This could potentially block Beta v1.11 which is due to be cut Tuesday,5/15. can you please help triage? /kind bug /priority failing-test /priority important-soon /sig cli cc /assign
Here are the failing upgrade jobs
Its all green now and I feel like crying :) thanks


Question: # This seems to matter to some tools export GO15VENDOREXPERIMENT=1 <ins> # GOMAXPROCS by default does not reflect the number of cpu(s) available # when running in a container, please see https://github.com/golang/go/issues/33803 if ! command -v ncpu >/dev/null 2>&1; then # shellcheck disable=SC2164 pushd "${KUBE_ROOT}/hack/tools" >/dev/null GO111MODULE=on go install ./ncpu # shellcheck disable=SC2164 popd >/dev/null fi GOMAXPROCS=${GOMAXPROCS:-$(ncpu)} kube::log::status "Setting GOMAXPROCS: ${GOMAXPROCS}" </ins> } # This will take binaries from $GOPATH/bin and copy them to the appropriate

<!-- Please only use this template for submitting enhancement requests --What would you like to be : should detect the appropriate GOMAXPROCS based off of the cpu limit supplied to the pod. Why is this needed: If not, test failures can occur (e.g. ) where GOMAXPROCS defaults to the number of cpus on the machine, while the cpu limit is actually far less. Too many compile/test processes launch, and any timing tests can become flaky. The end result is that running the test jobs on a node with more CPUs can make it flaky when running the test on a node with fewer CPUs cleanly passes. It's possible to set GOMAXPROCS=cpu limits in test jobs to avoid this, but it would be nicer if would autodiscover and set GOMAXPROCS appropriately.
/sig testing /sig k8s-infra
/transfer kubernetes
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign dims
xref:
This is already done, which is great, but for some more info I did some benchmarking of setting GOMAXPROCs vs not: Pretty substantially better in some cases


Question: blockingPet *pcb } <ins> // errUnhealthyPet is returned when a we either know for sure a pet is unhealthy, // or don't know its state but assume it is unhealthy. It's used as a signal to the caller for further operations like updating status.replicas. // This is not a fatal error. type errUnhealthyPet string func (e errUnhealthyPet) Error() string { return string(e) } </ins> // Sync syncs the given pet. func (p *petSyncer) Sync(pet *pcb) error { if pet == nil {

Is this a request for help? Nope What keywords did you search in Kubernetes issues before filing this one? petset replicas current desired Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: 24 cores, 64 GB RAM OS Arch Linux Kernel (e.g. ): Linux hostname 4.4.13-1-lts SMP Wed Jun 8 16:44:31 CEST 2016 x86_64 GNU/Linux Install tools: local-cluster- Others: What happened: While creating PetSet based on this tutorial: first PetSet pod was stuck in pending state due to lack of PersistentVolumes in cluster. When getting the petset info via I expected to see "CURRENT" set to 1, while the kubectl output was as follows: While clearly shows that only one pod is created: In json and yaml output, status.replicas value was also 2. What you expected to happen: I expected that CURRENT value shown by kubectl would be due to only one pod being created. How to reproduce it (as minimally and precisely as possible): Create via on empty cluster and run and . Anything else do we need to know: Nope
CURRENT is the number of pods that have been created, not that they are READY. See for example the latest api change for replica sets where we exactly for this reason. All controllers (petsets, daemonsets, deployments, etc.) should have ReadyReplicas cc:
See also
I guess it doesn't work anyway, since only one pod was created for this PetSet, but the CURRENT says that 2 were created. I will change bug description then.

Hmm, the idea is to sync every pet periodically, but only create them one at a time. The logic that counts status.replicas is wrong. This counter shouldn't be incremented in the case where we didn't update/sync or create a pet: Today we do increment it all pet creation is blocked on the first pet becoming unhealthy. Should be an easy fix if anyone wants to jump in ( fyi) otherwise I'll get to it once 1.4 is out.
I can try to fix it if that's OK. Thanks for the pointer to the source code!
Please do, co-assigned


Question: t.Errorf("unexpected error: %v", err) } if len(times) != 0 { <del> t.Errorf("expected 0 start times, got: , got: %v", times) </del> <ins> t.Errorf("expected 0 start times, got: %v", times) </ins> } } {

Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Unit test error message match the conventional Go style: For example: if got, want := set.Status.Replicas, 3; got != want { t.Errorf("set.Status.Replicas = %v; want %v", got, want) }
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig testing
/assign
/reopen


Question: flocker.DatasetName, flocker.DatasetUUID) } <ins> func printCSIVolumeSource(csi *corev1.CSIVolumeSource, w PrefixWriter) { var readOnly bool var fsType string if csi.ReadOnly != nil && *csi.ReadOnly { readOnly = true } if csi.FSType != nil { fsType = *csi.FSType } w.Write(LEVEL_2, "Type:tCSI (a Container Storage Interface (CSI) volume source)n"+ "    Driver:t%vn"+ "    FSType:t%vn"+ "    ReadOnly:t%vn", csi.Driver, fsType, readOnly) printCSIPersistentVolumeAttributesMultiline(w, "VolumeAttributes", csi.VolumeAttributes) } </ins> func printCSIPersistentVolumeSource(csi *corev1.CSIPersistentVolumeSource, w PrefixWriter) { w.Write(LEVEL_2, "Type:tCSI (a Container Storage Interface (CSI) volume source)n"+ "    Driver:t%vn"+

<!-- 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: kubectl describe pod xxx not show csi inline volume, it shows <unknow! What you expected to happen: show csi inline volume normally like this ! How to reproduce it (as minimally and precisely as possible): a pod with inline csi volume describe pod xxx not show csi inline volume Anything else we need to know?: Environment: Kubernetes version (use ): 1.14 beta2 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/assign
/sig cli


Question: containerPort: 8080 hostPort: 5000 volumeMounts: <del> - name: var-run </del> <ins> - name: varrun </ins> mountPath: /var/run readOnly: false <del> mountType: HOST - name: var-lib-docker </del> <ins> - name: varlibdocker </ins> mountPath: /var/lib/docker readOnly: true <del> mountType: HOST </del> - name: cgroups mountPath: /sys/fs/cgroup readOnly: true <del> mountType: HOST </del> volumes: <del> -name: var-run -name: var-lib-docker -name: var-cgroups </del> <ins> - name: varrun source: hostDir: path: /var/run - name: varlibdocker source: hostDir: path: /var/lib/docker - name: cgroups source: hostDir: path: /sys/fs/cgroup </ins>

With the current master HEAD, the apiserver never gets to a happy state. Here's what gets printed in many times. I think it's due to validation failure on the cadvisor manifest. Here's the relevent section of
Ryan, I haven't figured out the root cause of your issue yet, but I think I can help you rule out those validation failures on the cadvisor manifest. I saw the exact same validation errors on my , but I still can query /api/v1beta1/pods through apiserver. Both my apiserver and kubelet from yesterday afternoon, not include the latest merged PRs last night. Will try to see if I could reproduce your issue here.
I just pulled the code from HEAD, and ran into the same problem as Ryan. I need to attend a meeting now. Right after that, I will look into it if no one else are working it.
I seem to recall a cAdvisor path change in your PR? Related?
I will look
Just back from the meeting. I think the issue is caused by incompatibility between apiserver and kubelete. I noticed that there is a error msg in the initial your posed: E0722 14:55:52. ] Error synchronizing container list: &url.Error{Op:"Get", URL:"http://kubernetes-minion-", Err:(*net.OpError)(0xc2103ca2c0)} It is the same error I observed on my apiserver html page. Looks like apiserver failed to retrieve healthz/ from minions, then failed the query of /api/v1beta1/pods. To prove my hypothesis, I teared down my entire cluster and built a new one, and everything runs fine. I guess you just simply push the new kubelet binary over to some of minions in your cluster? Unfortunately I haven't figured out the exact where healthz/ failed yet.
We started validating manifests in the kubelet (using Tim's code) with my pull.
Looking into fixing the cAdvisor manifest. Assigning to myself.
Actually we started validating before with Tim's pull - I a unit test for validating manifests. We really need to get API validation in - I may try to get to that soon.


Question: args: args{}, want: list(21, "rv:20"), }, <ins> { name:   "two pages with resourceVersion", fields: fields{PageSize: 10, PageFn: (&testPager{t: t, expectPage: 10, remaining: 11, rv: "rv:20"}).PagedList}, args:   args{options: metav1.ListOptions{ResourceVersion: "rv:10"}}, want:   list(11, "rv:20"), }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {

/sig scalability Debugging below done by Failed test attempt: It failed with a number of "WaitingForPods: objects timed out" errors (46 failed objects in total). Sample failing pods: 580 nodes were not ready at 18:37: nodelifecyclecontroller said that gce-scale-cluster-minion-group-2-66d8's status hasn't been updated for 41 seconds. apiserver's logs show that kubelet was doing 'PUT ' every 10 seconds. Something weird happened to watch by 'shared-informers': One watch started at 18:36:52 and finished 9ms later. The next one started at 18:40:34. So it seems that there was a gap in lease watche between 18:36:52 and 18:40:34. Between 18:36:52 and 18:40:34 there is a number of leases LIST requests in the following pattern: a single /leases?limit=500 LIST request that finishes with 200 a single /leases/continue=XXX request that finishes with 400 The kube-controller-manager is retrying every 1 second up to 18:40:34.
/assign
Looking further at this it seems that number of LIST leases by kube-controller-manager increased significantly ~week ago in large scale tests (both gce and kubemark). GCE: ! Kubemark: ! This was caused by which as a side effect enabled pagination of LIST calls when starting/restarting watchers. In some cases we're getting 400 errors from api-server for this calls which results in the symptoms described above, i.e nodes becoming not-ready and pods stuck in running but not ready state for some time. GCE: ! Kubemark: !
There are actually two issues here: that we switched from non-paginated LIST calls to paginated the 10x increase in # calls is expected, but what is worrying is that we already had ~50 LISTs in every test. Such LIST happens only when watcher restarts which shouldn't happen in a healthy cluster This will be address in need to figure out why we're sometimes getting 400 response (BAD REQUEST).

/milestone v1.17
Logs when then 400 errors occurred api-server kube-controller-manager
So what happens here is: in reflector ends with an error different than so the doesn't get reset to next list is issued with set to page is fetched successfully, the next page is requested with the got from the first page and second page fails with due to error the doesn't get cleared anywhere so we go back to 2 and the 400 error keeps repeating until we get 410 (resourceVersionTooOld, on the next etcd compaction) and the is set to takes long enough for the NodeController to mark many nodes as not ready as it doesn't get any updates from watch about node leases This was indeed introduced by but the actual bug is in the which sets both and on the subsequent pages while it should set only . I will send a PR to fix it today.
FYI
Great finding.
Does this mean we have no tests that actually check if a reflector works with paging?
I see, it's the rare situation where "Watch in reflector ends with an error different than 410" that is untested. Can we set up a unit test that exercises this scenario by wrapping etcd3 storage to allow injecting an error in a watch attempt (similar to how we wrapped storage to test stale behavior in )?
I don't think it's the case - see . It clearly seems to be that pager wasn't properly tested. The problem seems to be that we're testing it with artifical stuff, whereas in real life etcd would return "bad request" errors.
Right, I'd like to see if we can trigger the error condition in a way that the restart/paging requests go to a real storage backend.
/milestone v1.18 (v1.17 code freeze)
- this is a regression introduced in 1.17, I actually believe we should fix that in 1.17.
/milestone v1.17 as noted above, this is a release blocking bug


Question: return nil, err } <del> oomAdjuster := oom.NewOOMAdjuster() </del> procFs := procfs.NewProcFs() // Initialize the runtime.

The type has a field called to indicate that a container must run as non-root user. The description for this field includes the sentence , which would mean that setting the field to or to (unset) have the same effect: However, the PodSecurityPolicy provider implementation handles the (unset) case differently, and thus does differentiate between unset or values: The API type documentation should be updated to clarify this behaviour and reflect the actual PodSecurityPolicy implementation. /sig node
Thanks for reporting this issue. I think that would be best able to assist with this. /sig auth /remove-sig node
The pod documentation is correct. If the field is not set or is false, the enforcement is not performed by the kubelet. However, podsecuritypolicy with a runasuser strategy of mustrunasnonroot will force a pod that has not specified a runAsNonRoot setting or a runAsUser uid to runAsNonRoot: true The documentation on the MustRunAsNonRoot strategy of podsecuritypolicy should clarify the mutation behavior of the PSP /remove-kind bug /kind documentation
Can I take this issue?
^ this is something that can be changed.
Here's a proposed change to the documentation in : Is this sufficient to solve this issue? If so, should I submit a PR there?
I'd change that to to be a little more complete.
/assign See PR for docs at
GitHub didn't allow me to assign the following users: josiahbjorgaard. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign See PR for docs at 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 would have saved me some battling today! I couldn't work out why my pod wasn't selecting my run-as-root pod security policy and ignoring my restricted pod security policy - I didn't realise I had to explicitly set to get the correct PSP to match (I thought the restrictive PSP would reject the pod and then the run-as-root PSP would match, not that the restrictive PSP would mutate the PodSpec)~ It would have had I read the actual docs better sigh.


Question: metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/validation/field" <del> "k8s.io/apiserver/pkg/features" utilfeature "k8s.io/apiserver/pkg/util/feature" featuregatetesting "k8s.io/component-base/featuregate/testing" </del> "k8s.io/kubernetes/pkg/apis/flowcontrol" "k8s.io/utils/ptr"

In 1.30, Priority and Fairness should allow a zero value, either via v1 or v1beta3 (with the roundtrip annotation) in create and update requests See:
/sig api-machinery /cc /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accpted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted


Question: func (a byCreationTime) Swap(i, j int)      { a[i], a[j] = a[j], a[i] } // Returns a list of image names based on regex and number of previous images requested. <del> func getGCEImages(imageRegex, project string, previousImages int) ([]string, error) { ilc, err := computeService.Images.List(project).Do() if err != nil { return nil, fmt.Errorf("Failed to list images in project %q: %v", project, err) } </del> <ins> func getGCEImages(imageRegex, imageFamily string, project string, previousImages int) ([]string, error) { </ins> imageObjs := []imageObj{} imageRe := regexp.MustCompile(imageRegex) <del> for _, instance := range ilc.Items { if imageRe.MatchString(instance.Name) { creationTime, err := time.Parse(time.RFC3339, instance.CreationTimestamp) if err != nil { return nil, fmt.Errorf("Failed to parse instance creation timestamp %q: %v", instance.CreationTimestamp, err) } io := imageObj{ creationTime: creationTime, name:         instance.Name, </del> <ins> if err := computeService.Images.List(project).Pages(context.Background(), func(ilc *compute.ImageList) error { for _, instance := range ilc.Items { if imageRegex != "" && !imageRe.MatchString(instance.Name) { continue } if imageFamily != "" && instance.Family != imageFamily { continue } creationTime, err := time.Parse(time.RFC3339, instance.CreationTimestamp) if err != nil { return fmt.Errorf("failed to parse instance creation timestamp %q: %v", instance.CreationTimestamp, err) } io := imageObj{ creationTime: creationTime, name:         instance.Name, } klog.V(4).Infof("Found image %q based on regex %q and family %q in project %q", io.string(), imageRegex, imageFamily, project) imageObjs = append(imageObjs, io) </ins> } <del> klog.V(4).Infof("Found image %q based on regex %q in project %q", io.string(), imageRegex, project) imageObjs = append(imageObjs, io) } </del> <ins> return nil }, ); err != nil { return nil, fmt.Errorf("failed to list images in project %q: %v", project, err) </ins> } sort.Sort(byCreationTime(imageObjs)) images := []string{}

We should support image family in node e2e image config. It makes image validation much easier on GCE.
Cool idea :) Adding a link to for anyone like me who hadn't heard of them before :)


Question: t.Errorf("unexpected fc disk found") } } <ins> func Test_ConstructVolumeSpec(t *testing.T) { fm := &mount.FakeMounter{ MountPoints: []mount.MountPoint{ {Device: "/dev/sdb", Path: "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod1"}, {Device: "/dev/sdb", Path: "/var/lib/kubelet/plugins/kubernetes.io/fc/50060e801049cfd1-lun-0"}, {Device: "/dev/sdc", Path: "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod2"}, {Device: "/dev/sdc", Path: "/var/lib/kubelet/plugins/kubernetes.io/fc/volumeDevices/3600508b400105e210000900000490000"}, }, } mountPaths := []string{ "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod1", "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod2", } for _, path := range mountPaths { refs, _ := mount.GetMountRefs(fm, path) var globalPDPath string for _, ref := range refs { if strings.Contains(ref, "kubernetes.io/fc") { globalPDPath = ref break } } if len(globalPDPath) == 0 { t.Errorf("couldn't fetch mountrefs") } arr := strings.Split(globalPDPath, "/") if len(arr) < 1 { t.Errorf("failed to retrieve volume plugin information from globalPDPath: %v", globalPDPath) } volumeInfo := arr[len(arr)-1] if strings.Contains(volumeInfo, "-lun-") { wwnLun := strings.Split(volumeInfo, "-lun-") if len(wwnLun) < 2 { t.Errorf("failed to retrieve TargetWWN and Lun. volumeInfo is invalid: %v", volumeInfo) } lun, _ := strconv.Atoi(wwnLun[1]) lun32 := int32(lun) if wwnLun[0] != "50060e801049cfd1" || lun32 != 0 { t.Errorf("failed to retrieve TargetWWN and Lun") } } else { if volumeInfo != "3600508b400105e210000900000490000" { t.Errorf("failed to retrieve WWIDs") } } } } func Test_ConstructVolumeSpecNoRefs(t *testing.T) { fm := &mount.FakeMounter{ MountPoints: []mount.MountPoint{ {Device: "/dev/sdd", Path: "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod1"}, }, } mountPaths := []string{ "/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod1", } for _, path := range mountPaths { refs, _ := mount.GetMountRefs(fm, path) var globalPDPath string for _, ref := range refs { if strings.Contains(ref, "kubernetes.io/fc") { globalPDPath = ref break } } if len(globalPDPath) != 0 { t.Errorf("invalid globalPDPath") } } } </ins>

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Currently, FC plugin returns volume name and empty FCVolumeSource during ConstrutVolumeSpec during . However, in order to recreate newMounter from volumeSpec, volume information are lacking. As a result, filesystem volume's reconstruction always fails. What you expected to happen: Filesystem volume's reconstruction works properly, then a volume is unmounted and detached from kubelet node. How to reproduce it (as minimally and precisely as possible): (1) Create filesystem volume using FC plugin (2) Restart kubelet service which a pod with FC volume is running Anything else we need to know?: cc Environment: Kubernetes version (use ):Install tools: local-cluster-
/assign
/sig storage


Question: {Name: "container1"}, {Name: "container2"}, }, <ins> InitContainers: []api.Container{ {Name: "initcontainer1"}, }, }, Status: api.PodStatus{}, }, opts:        &api.PodLogOptions{}, expectedErr: errors.NewBadRequest("a container name must be specified for pod test, choose one of: [container1 container2] or one of the init containers: [initcontainer1]"), }, { in: &api.Pod{ Spec: api.PodSpec{ Containers: []api.Container{ {Name: "container1"}, {Name: "container2"}, }, </ins> }, Status: api.PodStatus{}, },

Im extracting logs part from The current behavior is as follow: when pod has one container return logs for this one container when pod has more than one container returns error: Error from server: a container name must be specified for pod kube-dns-v14-z0ho6, choose one of: [kubedns dnsmasq healthz] As you can see in both cases init containers are ignored. The question are: in first case should we return error and list all containers including init containers? in second case should we also list init containers?
first case is designed on purpose that way for the usability, especially the users who switch from docker single container to Kubernetes pod. But what you suggested above for the second case are great, we should do it. Mind to send pr fixing it? Thanks!
sure, I will prepare pr. I'm wondering if we should somehow distinguish init containers and normal containers. we can add to init container name but this may be misleading. we can also add second list with init containers. Something like these: Or just show all in one list without any changes. What do you think?
I prefer not introducing a prefix "init:" here. I like the second option better. cc/ WDYT?
I like the second option as well. We generally avoid prefixes or special syntax except in rare cases.
since I know you are also looking at code in these places.
+1 for the second option.


Question: <del> /* Copyright 2014 Google Inc. All rights reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ // Reads the configuration from the file. Example file for two services [nodejs & mysql] //{"Services": [ //   { //      "Name":"nodejs", //      "Port":10000, //      "Endpoints":["10.240.180.168:8000", "10.240.254.199:8000", "10.240.62.150:8000"] //   }, //   { //      "Name":"mysql", //      "Port":10001, //      "Endpoints":["10.240.180.168:9000", "10.240.254.199:9000", "10.240.62.150:9000"] //   } //] //} package config import ( "bytes" "encoding/json" "fmt" "io/ioutil" "reflect" "time" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/golang/glog" ) // serviceConfig is a deserialized form of the config file format which ConfigSourceFile accepts. // TODO: this is apparently untested; is it used? type serviceConfig struct { Services []struct { Name      string   `json: "name"` Port      int      `json: "port"` Endpoints []string `json: "endpoints"` } `json:"service"` } // ConfigSourceFile periodically reads service configurations in JSON from a file, and sends the services and endpoints defined in the file to the specified channels. type ConfigSourceFile struct { serviceChannel   chan ServiceUpdate endpointsChannel chan EndpointsUpdate filename         string } // NewConfigSourceFile creates a new ConfigSourceFile and let it immediately runs the created ConfigSourceFile in a goroutine. func NewConfigSourceFile(filename string, serviceChannel chan ServiceUpdate, endpointsChannel chan EndpointsUpdate) ConfigSourceFile { config := ConfigSourceFile{ filename:         filename, serviceChannel:   serviceChannel, endpointsChannel: endpointsChannel, } go config.Run() return config } // Run begins watching the config file. func (s ConfigSourceFile) Run() { glog.V(1).Infof("Watching file %s", s.filename) var lastData []byte var lastServices []api.Service var lastEndpoints []api.Endpoints sleep := 5 * time.Second // Used to avoid spamming the error log file, makes error logging edge triggered. hadSuccess := true for { data, err := ioutil.ReadFile(s.filename) if err != nil { msg := fmt.Sprintf("Couldn't read file: %s : %v", s.filename, err) if hadSuccess { glog.Error(msg) } else { glog.V(1).Info(msg) } hadSuccess = false time.Sleep(sleep) continue } hadSuccess = true if bytes.Equal(lastData, data) { time.Sleep(sleep) continue } lastData = data config := &serviceConfig{} if err = json.Unmarshal(data, config); err != nil { glog.Errorf("Couldn't unmarshal configuration from file : %s %v", data, err) continue } // Ok, we have a valid configuration, send to channel for // rejiggering. newServices := make([]api.Service, len(config.Services)) newEndpoints := make([]api.Endpoints, len(config.Services)) for i, service := range config.Services { newServices[i] = api.Service{TypeMeta: api.TypeMeta{ID: service.Name}, Port: service.Port} newEndpoints[i] = api.Endpoints{TypeMeta: api.TypeMeta{ID: service.Name}, Endpoints: service.Endpoints} } if !reflect.DeepEqual(lastServices, newServices) { serviceUpdate := ServiceUpdate{Op: SET, Services: newServices} s.serviceChannel <- serviceUpdate lastServices = newServices } if !reflect.DeepEqual(lastEndpoints, newEndpoints) { endpointsUpdate := EndpointsUpdate{Op: SET, Endpoints: newEndpoints} s.endpointsChannel <- endpointsUpdate lastEndpoints = newEndpoints } time.Sleep(sleep) } } </del>

It's not well tested nor widely used; so it should either be removed or have tests and uses .


Question: podutil.DropDisabledPodFields(pod, nil) <del> applySeccompVersionSkew(pod) </del> applyWaitingForSchedulingGatesCondition(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: nodes := framework.GetReadySchedulableNodesOrDie(f.ClientSet).Items maxPodCount := 10 <del> jobDuration := 1 * time.Hour </del> <ins> jobDuration := 30 * time.Minute </ins> linesPerPodPerSecond := 100 <del> testDuration := 21 * time.Hour </del> <ins> // TODO(crassirostris): Increase to 21 hrs testDuration := 3 * time.Hour </ins> ingestionTimeout := testDuration + 30*time.Minute allowedRestarts := int(math.Ceil(float64(testDuration) / float64(time.Hour) * maxAllowedRestartsPerHour))

There's a problem b/c pods are created to run on all nodes, but run sequentially, effectively multiplying testing time


Question: BeforeEach(func() { framework.SkipUnlessFederated(f.Client) // create backend pod <del> createBackendPodsOrFail(clusters, f.Namespace.Name, FederatedIngressServicePodName) </del> <ins> createBackendPodsOrFail(clusters, ns, FederatedIngressServicePodName) </ins> // create backend service <del> service = createServiceOrFail(f.FederationClientset_1_4, f.Namespace.Name, FederatedIngressServiceName) </del> <ins> service = createServiceOrFail(f.FederationClientset_1_4, ns, FederatedIngressServiceName) </ins> // create ingress object <del> jig.ing = createIngressOrFail(f.FederationClientset_1_4, f.Namespace.Name) </del> <ins> jig.ing = createIngressOrFail(f.FederationClientset_1_4, ns) </ins> // wait for services objects sync <del> waitForServiceShardsOrFail(f.Namespace.Name, service, clusters) </del> <ins> waitForServiceShardsOrFail(ns, service, clusters) </ins> // wait for ingress objects sync <del> waitForIngressShardsOrFail(f.Namespace.Name, jig.ing, clusters) </del> <ins> waitForIngressShardsOrFail(ns, jig.ing, clusters) </ins> }) AfterEach(func() { <del> deleteBackendPodsOrFail(clusters, f.Namespace.Name) </del> <ins> deleteBackendPodsOrFail(clusters, ns) </ins> if service != nil { <del> deleteServiceOrFail(f.FederationClientset_1_4, f.Namespace.Name, service.Name) </del> <ins> deleteServiceOrFail(f.FederationClientset_1_4, ns, service.Name) </ins> service = nil } else { By("No service to delete. Service is nil") } if jig.ing != nil { <del> deleteIngressOrFail(f.FederationClientset_1_4, f.Namespace.Name, jig.ing.Name) </del> <ins> deleteIngressOrFail(f.FederationClientset_1_4, ns, jig.ing.Name) </ins> jig.ing = nil } else { By("No ingress to delete. Ingress is nil")

The addition of the federated namespace adminssion controllers broke this test. It's an easy fix. e2e test needs to create the required namespace before trying to create things in it. FYI. has volunteered to fix this. https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e

suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: []

Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
is fejta@ the right owner?
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated

ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated

Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in

underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e suite}
https://k8s- Failed: [] Federated ingresses [Feature:Federation] Federated Ingresses should create and update matching ingresses in underlying clusters {Kubernetes e2e


Question: <ins> apiVersion: v1beta3 kind: ReplicationController metadata: labels: name: openshift name: openshift spec: replicas: 1 selector: name: openshift template: metadata: labels: name: openshift spec: containers: - args: - start - master - --config=/config/master-config.yaml image: "openshift/origin" name: origin ports: - containerPort: 8443 name: openshift volumeMounts: - mountPath: /config name: config readOnly: true volumes: - name: config secret: secretName: openshift-config </ins>  No newline at end of file

This PR was prematurely merged: Need to update the PR based on the actual steps that were needed to get what was demonstrated at the public Kubernetes meet-up last week.
Any chance you can get rid of the hostPort from the example?
- depending on the Kubernetes provider, yes. For Vagrant based provider, I think I still need the hostPort because I do not have routes. For the GCE provider, I should be able to get rid of it because I have routes. In both providers, there were a number of setup steps that did not make the merged PR. For those that are tracking this issue (which I know folks have pinged me on separately) needs to be configured to allow privelaged containers needs to be configured to allow pushing to an insecure registry (this is point in time) Ideally, I could use a ReplicationController in the example to load balance OpenShift, but until we can provide a pattern to run etcd as a pod, I am unable to do this and need to use the embedded etcd we end up running.
Note: I will resolve this issue in 2 phases. Vagrant (which was demonstrated) to document using GCE (which has some additional steps on firewall rules)
Turns out OpenShift Origin is too secure now ;-) This is blocked until OpenShift Origin allows you to mint certs on the client, and then supply the certs on startup as a secret to the pod. This feature is coming soon. /cc
I now have all the required pieces to get this to work. I hope to get a PR submitted to fix this issue by end of this week.


Question: func setOwnerReference(src metav1.OwnerReference) map[string]interface{} { ret := make(map[string]interface{}) <del> controllerPtr := src.Controller if controllerPtr != nil { controller := *controllerPtr controllerPtr = &controller } blockOwnerDeletionPtr := src.BlockOwnerDeletion if blockOwnerDeletionPtr != nil { blockOwnerDeletion := *blockOwnerDeletionPtr blockOwnerDeletionPtr = &blockOwnerDeletion } </del> setNestedField(ret, src.Kind, "kind") setNestedField(ret, src.Name, "name") setNestedField(ret, src.APIVersion, "apiVersion") setNestedField(ret, string(src.UID), "uid") <del> setNestedField(ret, controllerPtr, "controller") setNestedField(ret, blockOwnerDeletionPtr, "blockOwnerDeletion") </del> <ins> // json.Unmarshal() extracts boolean json fields as bool, not as *bool and hence extractOwnerReference() // expects bool or a missing field, not *bool. So if pointer is nil, fields are omitted from the ret object. // If pointer is non-nil, they are set to the referenced value. if src.Controller != nil { setNestedField(ret, *src.Controller, "controller") } if src.BlockOwnerDeletion != nil { setNestedField(ret, *src.BlockOwnerDeletion, "blockOwnerDeletion") } </ins> return ret }

Kubernetes version Code from master. What happened: does not return and fields after they are set to non-nil values using . How to reproduce it (as minimally and precisely as possible): See PR
/sig api-machinery
This is a good find and I don't think I saw the notification come through :(


Question: func NewAuthenticator() authenticator.Request { return authenticator.RequestFunc(func(req *http.Request) (*authenticator.Response, bool, error) { <ins> auds, _ := request.AudiencesFrom(req.Context()) </ins> return &authenticator.Response{ User: &user.DefaultInfo{ Name:   anonymousUser, Groups: []string{unauthenticatedGroup}, }, <ins> Audiences: auds, </ins> }, true, nil }) }

Semantics are going to vary. We need to cross off these authenticators: [x] if ctx has an audience limitation, verify the token audience and echo in the response [x] take implicit audiences at WebhookTokenAuthenticator construction time if ctx is audience-limited, add into the tokenreview object if the tokenreview returns with an audience set that matches the ctx, copy into the response and return success if the tokenreview returns without an audience set, ensure the ctx audiences intersect with the implicit audiences taken at WebhookTokenAuthenticator construction time, and pick one to add into the response [x] echo audience in response if present in ctx [x] echo audience in response if present in ctx [x] check that the the order of (audience in the context) ∩ ( (implicit api audiences) ∪ (clientids) ) 0 Take implicit audiences at Authenticator construction time, and if ctx is audience-limited, ensure it intersects with the implicit audiences, and echo an audience in the response. [x] [x] [x] [x] [x] [x] Do nothing? [x] [x] [x] [x] [x] [x] [x] note: we already keyed the cache with the audience. [x]
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
/close
Closing this issue. <detailsIn response to : /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: hook should execute poststart http hook properly [NodeConformance] [Conformance]' description: When a post start handler is specified in the container lifecycle using a HttpGet action, then the handler MUST be invoked after the start of the container. <del> A server pod is created that will serve http requests, create a second pod with a container lifecycle specifying a post start that invokes the server pod to validate that the post start is executed. </del> <ins> A server pod is created that will serve http requests, create a second pod on the same node with a container lifecycle specifying a post start that invokes the server pod to validate that the post start is executed. </ins> release: v1.9 file: test/e2e/common/node/lifecycle_hook.go - testname: Pod Lifecycle, prestop exec hook

<!-- 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 --k8s-e2e-ltsc2019-containerd-flannel-sdnoverlay-master [] Container Lifecycle Hook when create a pod with lifecycle hook should execute prestart http hook properly [NodeConformance] [Conformance] [] Container Lifecycle Hook when create a pod with lifecycle hook should execute poststart http hook properly [NodeConformance] [Conformance] Note: the tests have been excluded until they are fixed. In the case of multinode clusters, the http server pod and the test cluster can spawn on different nodes, which can be problematic for poststart / prestop hooks, as they are executed by the kubelet itself, and the cross-node lifecycle hook might fail (according to the [Kubernetes network model], it is not mandatory for kubelet to be able to access pods on a different node). However, that is not always the case, different Networking setups allow cross-node communication between kubelet and pods, which means that the above tests are passing properly (for example: ), which begs the question if this behaviour should be universal or not, especially since the tests are marked as , which would imply that it should work in all cases. [Kubernetes network model]: links to appreciated links to specific failures in spyglass appreciated Slack: /sig testing /sig networking /sig windows <!-- Please see the deflaking doc () for more guidance! --
/sig network /sig node /area conformance /assign /priority critical-urgent /cc This is important since affects conformance and defines the networking behaviour for the poststart/ prestop hooks
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /sig node /sig conformance /assign /priority critical-urgent /cc Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
i'd personally let folks have first dibs on what we need to do here. Though from the name of the test itself, it seems like the test is NOT a sig-network test :)
Indeed, it does not have any tag in its name, but the tests rely on networking and on how CNIs work.

As I've stated above, it's not a problem for flannel sdnbridge, but it is for flannel sdnoverlay; other CNIs might have a similar issue too.
because the network is not a thing :) let´s tag the sig owner then /sig node I think that the key here is to decide if kubelet should be able to access pod in other nodes, and based on the link Claudiu is part of the Kubernetes networking model. I saw users that doesn't want kubelet to access even the pods on same host, so I think that is legit to say kubelet MAY reach pods in other nodes but not MUST ... but I'm not familiar with the to fully understand the context. If kubelet "may" reach pods in the other nodes, the test must only test lifecycle hooks for pods in the same node as the kubelet under test, right?
This is correct. The model also says: "For those platforms that support Pods running in the host network (e.g. Linux): pods in the host network of a node can communicate with all pods on all nodes without NAT" I believe that Windows host network is not supported, right?
Right, and there are specific tests that checks that exact scenario you've mentioned: However, the flaky tests I've mentioned in the issue require kubelet to be able to dial-in into a webserver pod for a different pod's poststart / prestop HTTP lifecycle hooks. There are couple of things regarding this: of all, in order to ensure kubelet would be able to run the HTTP lifecycle hooks, we'd have to make sure both pods are on the same node, as that is a supported scenario, according to the Kubernetes Network Model. I have sent a PR for this above. Alternatively, a Cluster IP could probably work as well, but IMO, ensuring that both pods end up on the same node is simpler and easier to clean up. , it's interesting that those HTTP lifecycle hook tests work on different networking setups, without any pods having HostNetwork enabled, even though you've mentioned they should (e.g.: Linux / Windows with flannel l2bridge, and even Linux with flannel overlay). Now, my question is: is this behaviour a feature, or a bug, especially since the tests are marked as `?

oh, I missed that part, so in Linux kubelet must be able to communicate with pods on all nodes (becuase it is running in the hostnetwork) If that is correct, it seems that one solution is to keep the test for Linux and tag it as LinuxOnly, and a new test for WindowsOnly that only spawn the pods under test in the same node EDIT Discussed in sig-net meeting , no clear answer... can be kubelet considered as a hostnetwork pod?
For the purposes of testing, I don't mind forcing the pods onto the same node., but let's document the heck out of that at the code-site?
correct but it will be supported once HostProcess containers are merged in 1.22: Only in Overlay networks (ie Flannel where these tests are flaking) does the pod have to be on the same node. It doesn't require host network mode and these tests are . I would be more inclined to disable this test for Windows Overlay test setups and have a sig-windows test for the overlay functionality. I would also question if the lifecycle hooks only running on the same node is useful and if it should just be documented that it doesn't work in the Windows Overlay setup.
is looking at test PRs from SIG Node. I will let sig-net triage this issue
Next steps on this?
/triage accepted
We still haven't merged this: I also had this, but it has been decided to be blocked:
requires conformance approval, at this point I think that has to be postponed to 1.23 right, since that behavior is not required, we shouldn't test it, because is legit to fail and having a test for something that can fail can create confusion :smile:


Question: } } <ins> func TestAzureTokenSourceScenarios(t *testing.T) { configMode := configModeDefault expiredToken := newFakeAzureToken("expired token", time.Now().Add(-time.Second)) extendedToken := newFakeAzureToken("extend token", time.Now().Add(1000*time.Second)) fakeToken := newFakeAzureToken("fake token", time.Now().Add(1000*time.Second)) wrongToken := newFakeAzureToken("wrong token", time.Now().Add(1000*time.Second)) tests := []struct { name         string sourceToken  *azureToken refreshToken *azureToken cachedToken  *azureToken configToken  *azureToken expectToken  *azureToken tokenErr     error refreshErr   error expectErr    string tokenCalls   uint refreshCalls uint persistCalls uint }{ { name:         "new config", sourceToken:  fakeToken, expectToken:  fakeToken, tokenCalls:   1, persistCalls: 1, }, { name:        "load token from cache", sourceToken: wrongToken, cachedToken: fakeToken, configToken: wrongToken, expectToken: fakeToken, }, { name:        "load token from config", sourceToken: wrongToken, configToken: fakeToken, expectToken: fakeToken, }, { name:         "cached token timeout, extend success, config token should never load", cachedToken:  expiredToken, refreshToken: extendedToken, configToken:  wrongToken, expectToken:  extendedToken, refreshCalls: 1, persistCalls: 1, }, { name:         "config token timeout, extend failure, acquire new token", configToken:  expiredToken, refreshErr:   fakeTokenRefreshError{message: "FakeError happened when refreshing"}, sourceToken:  fakeToken, expectToken:  fakeToken, refreshCalls: 1, tokenCalls:   1, persistCalls: 1, }, { name:         "unexpected error when extend", configToken:  expiredToken, refreshErr:   errors.New("unexpected refresh error"), sourceToken:  fakeToken, expectErr:    "unexpected refresh error", refreshCalls: 1, }, { name:       "token error", tokenErr:   errors.New("tokenerr"), expectErr:  "tokenerr", tokenCalls: 1, }, { name:        "Token() got expired token", sourceToken: expiredToken, expectErr:   "newly acquired token is expired", tokenCalls:  1, }, { name:        "Token() got nil but no error", sourceToken: nil, expectErr:   "unable to acquire token", tokenCalls:  1, }, } for _, tc := range tests { t.Run(tc.name, func(t *testing.T) { persister := newFakePersister() cfg := map[string]string{} if tc.configToken != nil { cfg = token2Cfg(tc.configToken) } tokenCache := newAzureTokenCache() if tc.cachedToken != nil { tokenCache.setToken(azureTokenKey, tc.cachedToken) } fakeSource := fakeTokenSource{ token:        tc.sourceToken, tokenErr:     tc.tokenErr, refreshToken: tc.refreshToken, refreshErr:   tc.refreshErr, } tokenSource := newAzureTokenSource(&fakeSource, tokenCache, cfg, configMode, &persister) token, err := tokenSource.Token() if fakeSource.tokenCalls != tc.tokenCalls { t.Errorf("expecting tokenCalls: %v, got: %v", tc.tokenCalls, fakeSource.tokenCalls) } if fakeSource.refreshCalls != tc.refreshCalls { t.Errorf("expecting refreshCalls: %v, got: %v", tc.refreshCalls, fakeSource.refreshCalls) } if persister.calls != tc.persistCalls { t.Errorf("expecting persister calls: %v, got: %v", tc.persistCalls, persister.calls) } if tc.expectErr != "" { if !strings.Contains(err.Error(), tc.expectErr) { t.Errorf("expecting error %v, got %v", tc.expectErr, err) } if token != nil { t.Errorf("token should be nil in err situation, got %v", token) } } else { if err != nil { t.Fatalf("error should be nil, got %v", err) } if token.token.AccessToken != tc.expectToken.token.AccessToken { t.Errorf("token should have accessToken %v, got %v", token.token.AccessToken, tc.expectToken.token.AccessToken) } } }) } } </ins> type fakePersister struct { lock  sync.Mutex cache map[string]string <ins> calls uint } func newFakePersister() fakePersister { return fakePersister{cache: make(map[string]string), calls: 0} </ins> } func (p *fakePersister) Persist(cache map[string]string) error { p.lock.Lock() defer p.lock.Unlock() <ins> p.calls++ </ins> p.cache = map[string]string{} for k, v := range cache { p.cache[k] = v

<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, when AAD login is configured, refresh token timeout would make kubectl print an error, not able to re-login without manually remove the tokens. Expect kubectl to promote user to login again. Why is this needed: Configure refresh-token timeout from Azure is a way to force re-login after inactivity. kubectl doesn't promote re-login makes users harder to apply timeout policy.
/sig azure
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig azure 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
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/area provider/azure
the root cause of this issue is in this first gets the cached token (result of device code flow) at it's trying to refresh an expired token at and failed. An error is returned. Since the expired token is still in the cache, it will always hit this path until user removes the token from kubeconfig. the fix should be: the token from cache a retry to re-initiate the device code flow in
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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 cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry.
I'm working on it.
are you working on it? I will grab it if I dont hear it from you :)
have the code ready will try PR this weekend Best, Ping
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Closing as merged


Question: kernelCompat:    true, expected:        proxyModeIPTables, }, <del> { // annotation says userspace flag:          "", annotationKey: "net.experimental.kubernetes.io/proxy-mode", annotationVal: "userspace", expected:      proxyModeUserspace, }, { // annotation says iptables, error detecting flag:          "", annotationKey: "net.experimental.kubernetes.io/proxy-mode", annotationVal: "iptables", iptablesError: fmt.Errorf("oops!"), expected:      proxyModeUserspace, }, { // annotation says iptables, version too low flag:            "", annotationKey:   "net.experimental.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: "0.0.0", expected:        proxyModeUserspace, }, { // annotation says iptables, version ok, kernel not compatible flag:            "", annotationKey:   "net.experimental.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    false, expected:        proxyModeUserspace, }, { // annotation says iptables, version ok, kernel is compatible flag:            "", annotationKey:   "net.experimental.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, { // annotation says something else, version ok flag:            "", annotationKey:   "net.experimental.kubernetes.io/proxy-mode", annotationVal:   "other", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, { // annotation says nothing, version ok flag:            "", annotationKey:   "net.experimental.kubernetes.io/proxy-mode", annotationVal:   "", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, { // annotation says userspace flag:          "", annotationKey: "net.beta.kubernetes.io/proxy-mode", annotationVal: "userspace", expected:      proxyModeUserspace, }, { // annotation says iptables, error detecting flag:          "", annotationKey: "net.beta.kubernetes.io/proxy-mode", annotationVal: "iptables", iptablesError: fmt.Errorf("oops!"), expected:      proxyModeUserspace, }, { // annotation says iptables, version too low flag:            "", annotationKey:   "net.beta.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: "0.0.0", expected:        proxyModeUserspace, }, { // annotation says iptables, version ok, kernel not compatible flag:            "", annotationKey:   "net.beta.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    false, expected:        proxyModeUserspace, }, { // annotation says iptables, version ok, kernel is compatible flag:            "", annotationKey:   "net.beta.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, { // annotation says something else, version ok flag:            "", annotationKey:   "net.beta.kubernetes.io/proxy-mode", annotationVal:   "other", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, { // annotation says nothing, version ok flag:            "", annotationKey:   "net.beta.kubernetes.io/proxy-mode", annotationVal:   "", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, { // flag says userspace, annotation disagrees flag:            "userspace", annotationKey:   "net.experimental.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: iptables.MinCheckVersion, expected:        proxyModeUserspace, }, { // flag says iptables, annotation disagrees flag:            "iptables", annotationKey:   "net.experimental.kubernetes.io/proxy-mode", annotationVal:   "userspace", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, { // flag says userspace, annotation disagrees flag:            "userspace", annotationKey:   "net.beta.kubernetes.io/proxy-mode", annotationVal:   "iptables", iptablesVersion: iptables.MinCheckVersion, expected:        proxyModeUserspace, }, { // flag says iptables, annotation disagrees flag:            "iptables", annotationKey:   "net.beta.kubernetes.io/proxy-mode", annotationVal:   "userspace", iptablesVersion: iptables.MinCheckVersion, kernelCompat:    true, expected:        proxyModeIPTables, }, </del> } for i, c := range cases { getter := &fakeNodeInterface{}

This annotation dates back almost a year. This is a relatively easy project for someone to contribute.
I'll work on getting a pull request in tomorrow for this. Ive been looking at contributing and think this would be a great place to start
nevermind. Looks like a pull request already exists. Overlooked the mention due to being on mobile. Cheers
We'll file more :)


Question: return nil }, timeout, interval).Should(gomega.BeNil()) } <ins> func updateShowHiddenMetricsForVersion(cfg *kubeletconfig.KubeletConfiguration, version string) *kubeletconfig.KubeletConfiguration { if cfg == nil { return &kubeletconfig.KubeletConfiguration{ ShowHiddenMetricsForVersion: version, } } cfg.ShowHiddenMetricsForVersion = version return cfg } </ins>

This shipped in 1.22 as deprecated in 1.22. As a hacky fix to unbreak tests on 1.23 dev, I bumped the deprecation policy one release: We will need to revert that before 1.23 ships and figure out a better solution. /kind cleanup /milestone v1.23 /sig node
/triage accepted
I want to try it. Can I take this issue?
I have explained how to fix this on PR:
/reopen reverted in as fix did not work
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
/cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi, Im the bug triage shadow. Since we're in 1.23 milestone code freeze, could we move this issue to milestone 1.24?
this is critical for 1.23 and I think it just got forgotten... we need to get this fixed before test freeze
/priority important-soon


Question: func (podPresetStrategy) PrepareForCreate(ctx genericapirequest.Context, obj runtime.Object) { pip := obj.(*settings.PodPreset) pip.Generation = 1 <ins> pod.DropDisabledVolumeMountsAlphaFields(pip.Spec.VolumeMounts) </ins> } // PrepareForUpdate clears fields that are not allowed to be set by end users on update.

says "Before persisting the object to storage, clear disabled alpha fields". There is that actually implements it but there are some discussions about it. This issues is a reminder that introduced by needs to be cleared too when the discussion in settles down. /assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
kind/cleanup priority/important-soon
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details


Question: "type": "object" }, "io.k8s.api.flowcontrol.v1beta1.ResourcePolicyRule": { <del> "description": "ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) least one member of namespaces matches the request.", </del> <ins> "description": "ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) either (d1) the request does not specify a namespace (i.e., `Namespace==""`) and clusterScope is true or (d2) the request specifies a namespace and least one member of namespaces matches the request's namespace.", </ins> "properties": { "apiGroups": { "description": "`apiGroups` is a list of matching API groups and may not be empty. "*" matches all API groups and, if present, must be the only entry. Required.",

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --I looked at the comment on ResourcePolicyRule to understand exactly what its ClusterScope field means, and was dismayed to find an outdated precise description that does not mention that field. I expected that comment to be up to date. Kubernetes version (use ): current 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:
/cc /cc /cc /cc
/triage accepted