Non-standard use of "subject" in CloudEvents Spec

[embano1]

Is your feature request related to a problem? Please describe. As of today the use of type and subject 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 in subject, e.g. VmPoweredOnEvent is not really a subject as per the meaning of the spec.

Describe the solution you'd like Instead of this:

{
  "id": "08179137-b8e0-4973-b05f-8f212bf5003b",
  "source": "https://vcenter-01:443/sdk",
  "specversion": "1.0",
  "type": "com.vmware.event.router/event ",
  "subject": "VmPoweredOnEvent",
  "time": "2020-02-11T21:29:54.9052539Z"
}

Use:

{
  "id": "08179137-b8e0-4973-b05f-8f212bf5003b",
  "source": "https://vcenter-01:443/sdk",
  "specversion": "1.0",
  "type": "com.vmware.event.router/vmware/vcenter/VmPoweredOnEvent",
  "subject": "vm-01",
  "time": "2020-02-11T21:29:54.9052539Z"
}

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).

[github-actions[bot]]

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.

[embano1]

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.

[embano1]

Comparison of CloudEvents generated by the VMware Event Router used currently in this project vs vSphere Sources for Knative:

CE Property	Type	Required	Event Router	vSphere Sources
ID	string	yes	uuidv4	VC Event Key
Type	string	yes	com.vmware.event.router/[event|eventex|extendedevent]	com.vmware.vsphere.[ReflectEventName|EventTypeID].v0
Source	string	yes	vcenter.URI()	vcenter.URI()
Subject	string	no	ReflectEventName|EventTypeID	(unused)
datacontenttype	string	no	application/json	application/xml,application/json
time	timestamp	no	GetEvent().CreatedTime	GetEvent().CreatedTime
CE transport encoding	n/a	n/a	configurable (per processor)	binary

[vaikas]

@embano1 You added the datacontenttype overrides, so at least that field could now be updated for json/xml? Also, would you mind adding a pointer or example on what ReflectEventName looks like.

[embano1]

@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

Also, would you mind adding a pointer or example on what ReflectEventName looks like.

Yeah, sorry for being too brief there. For "core" events such as VmPoweredOnEvent, i.e. those not belonging to EventEx or ExtendedEvent we use go type reflection on the BaseEvent interface to retrieve the event name. That's what I meant there.

[vaikas]

Oh no rush :) I was just playing with octobox (👍 so far) and noticed this lol :)

Ok, sweet, thanks!

[embano1]

Updated the table with the recent changes in the router to be more aligned with VSphereSources. Since the VSphereSources format correctly represents the CloudEvents spec, it makes sense to slowly transition the router event schema (metadata) to the VSphereSources approach.

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:

1. Communicate the changes upfront to prepare the user base
2. Change type to what VSphereSources uses but keep subject (as most users trigger on subject in VEBA)
3. Eventually phase out subject (hoping that most users would have migrated to the type trigger before)

This also requires changes on how the metrics stats are retrieved, e.g. currently based on subject.

[lamw]

#1075