Infeasible
Status Update
Comments
ad...@google.com <ad...@google.com> #2
+1 to this feature request, came here seeking help at https://serverfault.com/questions/987908/custom-routes-rejected-by-gke-peer-configuration/988167#988167
We will to build CD pipelines with agents running in internal on-premise network, peered with GCP network. GKE private endpoint is not reachable in this case.
We will to build CD pipelines with agents running in internal on-premise network, peered with GCP network. GKE private endpoint is not reachable in this case.
sb...@gmail.com <sb...@gmail.com> #3
+1 Could be quite a useful feature for us.
Ideally, we don't want to have public IP for K8S API at all and manage it privately inside the org with a hybrid architecture site-2-site VPN etc.
Ideally, we don't want to have public IP for K8S API at all and manage it privately inside the org with a hybrid architecture site-2-site VPN etc.
ad...@google.com <ad...@google.com> #4
I thought this would be resolved now that the VPC Peerings of private GKE will accept routes exported from the VPC. But it still doesn't seem to work for me.
sb...@gmail.com <sb...@gmail.com> #6
Does anyone has been able to make it works?
sb...@gmail.com <sb...@gmail.com> #7
I stumbled upon this issue and wanted to share some thoughts on how we fixed this. Following the documentation listed above, there is a reference to the VPC peering connection, which links here: https://cloud.google.com/vpc/docs/using-vpc-peering#update-peer-connection . After setting the "Export custom routes" bit, I was able to start connecting from my private network. The exported routes bit injects the static/dynamic routes to the peered VPC, which therefore allows responses to flow backward to the clients from the api server.
Description
The modification times of files created by Mac OS on exFAT drives are interpreted incorrectly by Android on Samsung devices.
Specifically, a file written to an exFAT drive on Mac OS reports its times correctly on Mac OS, Windows, and Linux, but is skewed 16 hours in the future on Samsung Android devices alone. Files times are correct for files created by Samsung Android on exFAT devices and used elsewhere, but files created by Mac OS (only) have incorrect times on Samsung Android (only). This hampers interoperability of exFAT drives on these mobile devices for Mac OS users, and impacts tools like incremental-backup programs.
For more details on this bug, including related screenshots and test details, please see this page:
This bug was verified to exist in Android Nougat and Oreo, and on Samsung J7, S8+, and Note 9 devices. It occurs only for files written by Mac OS (El Capitan through High Sierra). Files written to exFAT drives on Windows (7 through 10) have correct times on Samsung Android, and files written by Mac OS have correct times outside Android.
To recreate the bug: save a file to an exFAT USB drive on Mac OS, and inspect its modification time on any of the Android versions and devices noted; it will be incorrect on the latter. The bug's status on Android Pie is unknown.