-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-standard use of "subject" in CloudEvents Spec #182
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Figuring out a subject that can be easily constructed across different providers might not be easy. A intermediary solution would be to use the event ID/UUID as the subject. |
Comparison of CloudEvents generated by the VMware Event Router used currently in this project vs vSphere Sources for
|
@embano1 You added the datacontenttype overrides, so at least that field could now be updated for json/xml? |
Wow, you're fast! Once I'm back on my laptop I'll do as my iPad Github app keeps crashing when I try to edit that comment :D
Yeah, sorry for being too brief there. For "core" events such as |
Oh no rush :) I was just playing with octobox (👍 so far) and noticed this lol :) Ok, sweet, thanks! |
Updated the table with the recent changes in the This would lead to a breaking change for existing users (triggers and code if they use these fields in their functions), so we can do a slow migration:
This also requires changes on how the metrics stats are retrieved, e.g. currently based on |
Is your feature request related to a problem? Please describe.
As of today the use of
type
andsubject
in the CloudEvents structured event payload might not conform to what users expect. E.g."com.vmware.event.router/event"
can be considered an abstract event class and the corresponding event used insubject
, e.g.VmPoweredOnEvent
is not really a subject as per the meaning of the spec.Describe the solution you'd like
Instead of this:
Use:
Where the syntax for
type
can be defined as:com.vmware.event.router/<vendor>/<provider>/<event>
Additional context
Breaking change with an option to provide backward compatibility for some time (deprecation notice).
The text was updated successfully, but these errors were encountered: