https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/MDSAL-282 mdsal <p>In BORON-SR3, I have found that the eventTime is missing in the generated Java POJO classes.</p> <p>Some of the issue faces are listed below:</p> <p>1) Firstly, the NETCONF notification object doesn't have the generated event time there is an issue for the NBI systems in replaying the missed events.<br/> 2) Secondly, unable to do effective event correlation.</p> <p>note: The received notification (both Alarm and event) has the &lt;eventTime&gt; but the generated notification listener doesn't seem to have reference to the eventTime leaf attribute.</p> <p>Please find the karaf log with trace level set and the generated POJO class file.</p> <p>Operating System: Linux<br/> Platform: Other</p> MDSAL-282

Notification - eventTime is missing in the generated Java POJO classes

New Feature Resolved Done Robert Varga Senthilkumar Jayakumar Tue, 1 Aug 2017 09:27:44 +0000 Tue, 25 Apr 2023 21:06:05 +0000 Tue, 30 Apr 2019 03:31:00 +0000 4.0.1 Binding API Binding runtime 1 5 <p>Attachment eventTime_logs_and_generated_pojo.zip has been added with description: Karaf logs and generated POJO classes from the yang model</p> <p>I do not believe this is either a yangtools not an mdsal codegen issue.</p> <p>To elaborate, 'notification' defines a YANG notification, which is the contents of the event, not its metadata (like eventTime, which really is NETCONF-specific metadata).</p> <p>Can you describe the specific use case?</p> <p>RFC 5277 mandates eventTime to be part of every notification content and it is not merely metadata. </p> <p>My use case was to be able to subscribe for NETCONF notifications and further process/act upon based on the severity. </p> <p>--------------------------------------------------------------------------<br/> Excerpt from RFC 5277</p> <p>2.2. Sending Event Notifications</p> <p> Once the subscription has been set up, the NETCONF server sends the<br/> event notifications asynchronously over the connection.</p> <p>2.2.1. &lt;notification&gt;</p> <p> Description:</p> <p> An event notification is sent to the client who initiated a<br/> &lt;create-subscription&gt; command asynchronously when an event of<br/> interest (i.e., meeting the specified filtering criteria) has<br/> occurred. An event notification is a complete and well-formed XML<br/> document. Note that &lt;notification&gt; is not a Remote Procedure Call<br/> (RPC) method but rather the top-level element identifying the one-<br/> way message as a notification.</p> <p> Parameters:</p> <p> eventTime</p> <p> The time the event was generated by the event source. This<br/> parameter is of type dateTime and compliant to <span class="error">&#91;RFC3339&#93;</span>.<br/> Implementations must support time zones.</p> <p> Also contains notification-specific tagged content, if any. With<br/> the exception of &lt;eventTime&gt;, the content of the notification is<br/> beyond the scope of this document.</p> <p>--------------------------------------------------------------------------</p> <p>Right, but RFC5277 is NETCONF notifications, not YANG notifications. Codegen works on top of RFC6020/7950, without access-protocol-specific metadata.</p> <p>Hi Robert,</p> <p>I was looking into the code, <br/> When ODL receives netconf notification it will be of type NetconfMessage. <br/> NetconfMessage has &lt;eventTime&gt;2017-10-26T21:41:54Z&lt;/eventTime&gt;. From NetconfMessage there will be an instance of DOMNotification will be created.</p> <p>Class NetconfMessageTransformer {<br/> static class NetconfDeviceNotification implements DOMNotification, DOMEvent </p> { private final ContainerNode content; private final SchemaPath schemaPath; private final Date eventTime; } <p>}<br/> In DOMNotification, eventTime is separated from content. The content will be delegated to corresponding NotificationListener with the help of schemaPath. EvenTime will never be delivered to listener since its not part of content. So is there any way in which eventTime is also delivered to the NotificationListener along with content? </p> <p>Right, because that is a detail is part of metadata, not the actual notification data. I am not sure how to map this &#8211; perhaps RFC7952 is part of the solution, somehow. Sorry, I do not have this problem domain loaded, so cannot really wrap my mind about end to end implications <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>After thinking about this a bit more, there are essentially two approaches we can take:<br/> 1) transport notification metadata at the NotificationBroker level, add another argument to all NotificationListener interfaces<br/> 2) transport notification metadata in-band, e.g. add DataContainer.metadata(), which exposes access to metadata</p> <p>In either case we need to generate container classes for each md:annotation use in models, such that metadata type is properly captured (yangtools.rfc7952.model.api.Annotation gives us everything we need).</p> <p>I think I like approach 2) better, as it allows for proper forwarding without losing metadata.</p> <p>Also, we need someone to define event-time annotation &#8211; I am not sure if there is an IETF RFC/draft that does that.</p> <p>Karthik, for now I'm assigning this to you.</p> <p>Please decide update who should handle this issue. </p> <p>Actually  eventTime is not metadata, nor should it be attached to the notification directly, as it is data from the "Messages" layer of NETCONF, <a href="https://tools.ietf.org/html/rfc6241#section-1.2" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc6241#section-1.2</a> , hence it is part of notification envelope.</p> <p>From that perspective option 1) is correct, as there are two distinct cases here:</p> <ol> <li>the notification is being generated, and therefore eventTime needs to be generated by the NotificationBroker</li> <li>the notification is being forwarded, and therefore eventTime needs to be propagated from the original envelope</li> </ol> <p>The envelope approach is interesting in that an envelope can actually contain more than eventTime and 2) may want to modify other things (like record forwarding).</p> <p>I think we should take a lesson from DOM world here, where DOMNotification and DOMEvent are completely separate interfaces composed by implementation. The same approach can be taken in Binding world, where we lack the equivalent of DOMEvent – which should be defined in Binding API, not binding spec, let's say EventInstantAware. The design of that interface needs to take into account the binding spec and its method must not overlap with user-generated methods (hence no 'get' method prefix!).</p> <p>binding-dom-adapter would be tagging incoming Notification instances with current time, forwarding them to DOMNotificationRouter as proper DOMEvents, by subclassing  LazySerializedDOMNotification. On the receiving end, binding-dom-codec needs to grow a subclass of LazyDataObject, which will, in addition to the normal interface, implement EventInstantAware.</p> <p>Users can then query their incoming notifications for EventInstantAware, and if it is available it will be presented to them.</p> Blocks NETCONF-483 Relates NETCONF-1001 Development External issue ID 8919 External issue URL Rank 0|i02xfr: