Status Update
Comments
kn...@google.com <kn...@google.com> #2
I'm also seeing this issue with Material Components 1.3.0 and ConstraintLayout 2.1.0-alpha2
an...@gmail.com <an...@gmail.com> #3
Fixed with 2.1.0-beta01
cz...@google.com <cz...@google.com> #4
Customer asked for feature request for this functionality, with following user case:
"
We would like to be able to permit Cloud Functions to subscribe to PubSub Topics in other GCP projects.
Background: In our project landscape we have data computation projects and api projects among others.
Intent: We would like to use a PubSub topic to notify interested parties / components in other GCP projects that an important computation has finished.
Problem: The downstream components / parties are not able to deploy cloud functions in their respective projects to consume the notification messages on the topic.
Effects: The downstream components / parties have to create PubSub topic in their projects, and the upstream component has to to know and publish into these topics. For each additional downstream party, the upstream component has to be changed.
This is adverse to good decoupling practices.
"
"
We would like to be able to permit Cloud Functions to subscribe to PubSub Topics in other GCP projects.
Background: In our project landscape we have data computation projects and api projects among others.
Intent: We would like to use a PubSub topic to notify interested parties / components in other GCP projects that an important computation has finished.
Problem: The downstream components / parties are not able to deploy cloud functions in their respective projects to consume the notification messages on the topic.
Effects: The downstream components / parties have to create PubSub topic in their projects, and the upstream component has to to know and publish into these topics. For each additional downstream party, the upstream component has to be changed.
This is adverse to good decoupling practices.
"
pm...@gmail.com <pm...@gmail.com> #5
Another good use-case for this would be to shadow production workloads in qa environments with minimal interference.
gi...@google.com <gi...@google.com> #6
Another customer showed great interest in this feature request:
"We need one core-project publishing via push, with several subscribers in different projects. These projects are managed by different child companies within the organization, so the projects are accessible by different development teams.
We wish there was a less cumbersome and more elegant way of authentication within internal network than the domain validation via public web, with projects in the same organization."
"We need one core-project publishing via push, with several subscribers in different projects. These projects are managed by different child companies within the organization, so the projects are accessible by different development teams.
We wish there was a less cumbersome and more elegant way of authentication within internal network than the domain validation via public web, with projects in the same organization."
to...@hornbach.com <to...@hornbach.com> #7
hi, a use case of mine is quite similar. I have an application pushing data from project A into a PubSub topic, and I want project A to keep data sovereignty. A possibly arbitrary amount of subscribers, housed in other projects, will subscribe to this topic.
Is this feature planned in any way?
Is this feature planned in any way?
Description
As far as I can see there is no way to connect a publisher topic in one project (A) with a cloud function in another project (B).
If I create a topic subscription in the function's project B for the topic in project A, it still won't let me add a push http url to the function because "The supplied HTTP URL is not registered in the subscription's parent project" (even though the subscription is in project B, but the topic is in project A). And I can't create a subscription in project A because the http url in project B requires a domain check on the functions endpoint.