-
Notifications
You must be signed in to change notification settings - Fork 74
Adding basic cloudevents pubsub binding. #1
Conversation
/retest |
Presubmit tests are failing because of #7 |
/retest |
|
||
In the _binary_ content mode, the value of the event `data` attribute is placed | ||
into the Pub/Sub payload data as-is, with the `datacontenttype` | ||
attribute value declaring its media type; all other event attributes are mapped |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there limits to the number of attributes that can appear in an event? Pub/Sub does have limitations on the number and size of attributes (https://cloud.google.com/pubsub/quotas#resource_limits).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good to know! The cloudevents spec has some min-max supported size ideas and they are 64kB.
It would be good to link to this table from this bindings spec.
What's the plan here @n3wscott |
@vaikas-google I have implemented this spec in the golang sdk. I am looking for more reviews from the pubsub owners. |
I think it worth mentioning what content mode(s) we are going to use for GCP Sources. There were previous conversations about preferring Binary content mode because of more streamlined routing we can build with messages in Binary mode and we should reflect it somewhere. Do we have (or planning to have) a GCP-specific guidelines document for our bindings? |
changing api groups
Added 5 minutes resync period for topic and pullsubscriptions
Old PR. Closing it for now. We still have it around for future reference. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: n3wscott The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Is this work being continued anywhere? We're looking at publishing/consuming events over Google Pubsub in Cloudstate, and would very much like a consistent means for doing so. |
@n3wscott: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Examples: | ||
|
||
* `time` maps to `ce-time` | ||
* `id` maps to `ce-id` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something to consider, how do the time
and id
attributes specified here relate to the message_id
and publish_time
fields on the Google PubsubMessage? My thought is that they should be ignored, with the caveat that if something is receiving non cloud event messages through Google Pubsub, and they want to express these messages as cloud events, then those fields may be used to seed those values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It had been forked and already landed in this repo. Check out the docs dir
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah didn't see that. Thanks!
No description provided.