Fixed
Status Update
Comments
tp...@gmail.com <tp...@gmail.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.
il...@google.com <il...@google.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.
du...@google.com <du...@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.
il...@google.com <il...@google.com> #6
Does anyone has been able to make it works?
fr...@gmail.com <fr...@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.
du...@google.com <du...@google.com> #8
da...@myfitnesspal.com. - this does not work with private ip , something else in your setup (like public ip, nat or something) made it work, not the export/import , this issue was verified by google support investigating all setups in our projects including export/import custom routes.
fr...@gmail.com <fr...@gmail.com> #9
yo...@gmail.com. - the only solutions are: 1. proxy/nat on the vpc where gke is (small impact) 2. refactor vpc peering to replace by vpn between vpc (big impact to customer projects)
il...@google.com <il...@google.com> #10
fr...@gmail.com <fr...@gmail.com> #11
@ko...@cb4.com Happy to talk more on my setup, but by exporting the routes, it exposed the peering connection to the cloud router, which then advertised the paths over the BGP peer.
il...@google.com <il...@google.com> #12
This is a critical issue and crucial security factor, I cannot understand how this is still an open matter
This is true also for VPCs in the same project!
This is true also for VPCs in the same project!
ap...@google.com <ap...@google.com> #13
Weird, even I set the "Control plane global access = Enabled" it´s not reachable... So, what´s this purpose? I don´t want to set a public Endpoint for security reasons :(
ap...@google.com <ap...@google.com> #14
Project: platform/frameworks/support
Branch: androidx-main
commit 0b7b59589d3722cc2c4491437f6e27fa0a8d1fc8
Author: Clara Fok <clarafok@google.com>
Date: Tue Jul 19 17:52:02 2022
Add project dependency constraint between paging-common and paging-compose
Added bi-directional project constraint between paging-common and paging-compose. This is necessary because recent features added in common and compose requires these two strict matches:
(common:3.2.0-alpha01) with (compose:1.0.0-alpha15) for b/235256201
(common:3.2.0-alpha02) with (compose:1.0.0-alpha16) for b/239868768
As such, project constraint is used to ensure that, regardless of which common version is used, the relevant ToT compose will be set as constraint.
Example: Lower compose version with higher common version
Before constraint added, paging-compose:1.0.0-alpha14 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha14
+--- androidx.paging:paging-common:3.1.0-beta01 -> 3.2.0-alpha01 (*)
After constraint, paging-compose:1.0.0-alpha14 and paging-common:3.2.0-alpha02
+--- androidx.paging:paging-compose:1.0.0-alpha14 -> 1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha02 (*)
Example: Higher compose version with lower common version
Before constraint added, paging-compose:1.0.0-alpha16 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha01
After constraint, paging-compose:1.0-0-alpha16 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha01 -> 3.2.0-alpha02
Test: n/a
Fixes: 235256201
Fixes: 239868768
Change-Id: Ifbe86432341d2d4c18fd105b713f454acdaa5b22
M paging/paging-compose/build.gradle
M paging/paging-common/build.gradle
https://android-review.googlesource.com/2160202
Branch: androidx-main
commit 0b7b59589d3722cc2c4491437f6e27fa0a8d1fc8
Author: Clara Fok <clarafok@google.com>
Date: Tue Jul 19 17:52:02 2022
Add project dependency constraint between paging-common and paging-compose
Added bi-directional project constraint between paging-common and paging-compose. This is necessary because recent features added in common and compose requires these two strict matches:
(common:3.2.0-alpha01) with (compose:1.0.0-alpha15) for
(common:3.2.0-alpha02) with (compose:1.0.0-alpha16) for
As such, project constraint is used to ensure that, regardless of which common version is used, the relevant ToT compose will be set as constraint.
Example: Lower compose version with higher common version
Before constraint added, paging-compose:1.0.0-alpha14 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha14
+--- androidx.paging:paging-common:3.1.0-beta01 -> 3.2.0-alpha01 (*)
After constraint, paging-compose:1.0.0-alpha14 and paging-common:3.2.0-alpha02
+--- androidx.paging:paging-compose:1.0.0-alpha14 -> 1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha02 (*)
Example: Higher compose version with lower common version
Before constraint added, paging-compose:1.0.0-alpha16 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha01
After constraint, paging-compose:1.0-0-alpha16 with paging-common:3.2.0-alpha01
+--- androidx.paging:paging-compose:1.0.0-alpha16
+--- androidx.paging:paging-common:3.2.0-alpha01 -> 3.2.0-alpha02
Test: n/a
Fixes: 235256201
Fixes: 239868768
Change-Id: Ifbe86432341d2d4c18fd105b713f454acdaa5b22
M paging/paging-compose/build.gradle
M paging/paging-common/build.gradle
Description
Hi, encountered java.lang.NoSuchMethodError: crash right after upgrading paging compose version to 1.0.0-alpha15
Upon inspecting the source code locally, noticed that the pagingDataDiffer in class LazyPagingItems is calling the PagingDataDiffer new constructor with mainContext as the named argument.
But the PagingDataDiffer class in the lib is having the old constructor argument mainDispatcher
Component used: Paging Compose
Version used: 1.0.0-alpha15
Devices/Android versions reproduced on: All
Build: AI-212.5712.43.2112.8609683, 202205181650,
AI-212.5712.43.2112.8609683, JRE 11.0.12+0-b1504.28-7817840x64 JetBrains s.r.o., OS Mac OS X(x86_64) v12.4, screens 2880.0x1800.0, 1920.0x1080.0; Retina
AS: Chipmunk | 2021.2.1 Patch 1; Kotlin plugin: 212-1.6.21-release-334-AS5457.46; Android Gradle Plugin: 7.2.1; Gradle: 7.4.1; Gradle JDK: version 11.0.12; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: 3.18.1-g262b901, from PATH: (not found)
IMPORTANT: Please readhttps://developer.android.com/studio/report-bugs.html carefully and supply all required information.