You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Even though not explicitly stated, event schemas for vSphere are tied to a particular vSphere release, i.e. could break between major releases (even minor). Currently there is no way to detect the vSphere version that generated a particular event. This could lead to decoding errors in functions if a schema breaks in a non-compatible way between vSphere releases.
Describe the solution you'd like
Ideally, vSphere events should carry a version indicating the schema version/contract consumers can rely on. Providing OpenAPI schemas would be neat to but seems not feasible as an implementation in vSphere currently.
The short-term solution would be to use custom context attributes to reflect the vSphere versions (incl. API version).
Describe alternatives you've considered
Currently, no alternatives without changes to the vSphere eventing core exist IMHO to indicate/prevent breaking schema changes.
Additional context
The text was updated successfully, but these errors were encountered:
Since vSphere events are not versioned and (somewhat loosely) tied to a
particular vSphere API version, this change introduces a new CloudEvents
context attribute `vsphereapiversion` reflecting the vSphere API version
of a particular CloudEvent produced by the `vcenter` event producer.
BREAKING: This change sets the `timestamp` in the CloudEvent to the
`CreatedTime` as set by vCenter in a vSphere event instead of
`time.Now()`.
Closes: vmware-samples#439
Signed-off-by: Michael Gasch <mgasch@vmware.com>
Is your feature request related to a problem? Please describe.
Even though not explicitly stated, event schemas for vSphere are tied to a particular vSphere release, i.e. could break between major releases (even minor). Currently there is no way to detect the vSphere version that generated a particular event. This could lead to decoding errors in functions if a schema breaks in a non-compatible way between vSphere releases.
Describe the solution you'd like
Ideally, vSphere events should carry a version indicating the schema version/contract consumers can rely on. Providing OpenAPI schemas would be neat to but seems not feasible as an implementation in vSphere currently.
The short-term solution would be to use custom context attributes to reflect the vSphere versions (incl. API version).
Describe alternatives you've considered
Currently, no alternatives without changes to the vSphere eventing core exist IMHO to indicate/prevent breaking schema changes.
Additional context
The text was updated successfully, but these errors were encountered: