Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Issues & Decisions


IssueNotesDecisionSioffSign-off
1

Should version of schema definition be updated (to v2) for lcm-event-schema-v1

Change is backward compatible. So new version not needed?
Can old clients read new messages?!
Typically marshalling can be configured to ignore 'new fields'

(Csaba has checked, clients are ignoring 'unknown' fields)

Keep event name (if possible)

  1. do NOT change version foe legacy event update
  2. do change version when upgradign to CloudEvent format
2

CM Handle LCM events are not a cloud events yet

2 components have to be updated, Csaba will check impacts required.
Options

  • Prepare client for Cloud Events
  • backward compatible legacy event first

CPS Team prefers convert to cloud event first  


CPS are to keep Legacy events. Till //EE are ready to take cloud event on their side- CPS-2058

3The Alternate Id will be available only in the LCM Message (body) not as a header Part of review of proposed cloud event structure
Might want to create a custom extension for 'alternate id' (to be able to filter)



4Should the alternateId be included in the Values (newValues/ oldValues) part of the event? 

In initial implementation alternateId was included in the Values part of the event, so if alternateId is changed from an empty string to some string an empty string should be present in the oldValues and some new string should be present in the newValues. But this isn't the case since the lcm event is only sent when the state is changed e.g going from ADVISED to READY.

This can be replicated with cmHandleProperties.

Topology  consumes LCM event.  We only need NEWvalues

AlternateID would appear as part of the body (Body/old/new)

It's should not appear in the old/new at all.

Should this event be sent if some propoerty changes ? - No 

It's only expected to change when the LCM statechanges

  

...