Operating System: All
Platform: All

Device-Type augmentation in your use-case is protocol specific information
or rather it is device model, etc?

If it is protocol-specific information / capability I would suggest for writer to attach protocol-specific augmentation and for framework / drivers to listen for that augmentation.

The augmentation is device model not a protocol augmentation. The flow we have been discussing is that when a device plugin will register for a data change notification on a node, but they really only want to be notified when the type is a given value. For example the Ciena6500 plugin only wants to be notified when the type is set to CIENA_6500 and the the Ciena5400 plugin only wants to be notified when the type is set to CIENA_5400.

Without this level of filtering every plugin would have be notified anytime a node changes and have to check (a) if the type was changes and (b) if the new / old type is something that I care about. This will result in a lot of notification, where if there is a filtering capability there are far fewer notifications.

Additionally, as indicated above, being able to filter on the "old" value would be useful as well. So if a type changed from CIENA_5400 to CIENA_6500 the 5400 plugin would be notified that it changed from that value and the 6500 plugin would be notified that it change to that value. Both notifications could be the same notification, but calling both updates would be useful.

Where would this be useful. For a set of devices the comms to the device is session or connection based. When the value is set the controller (plugin) would verify / establish the connection and when the value is remove the controller (plugin) would terminate any existing session.

just to preempt the question, yes, i would agree that after the initial type setting it is unlikely that a device would change types that often, but it is a use case.

So essentially this is a request for a filtering expression, where the data 'comes to existence' when the expression becomes true and disappears when it becomes false.

Now if you have two independent plugins, this is problematic, as the notifications to the two of them will be inherently asynchronous so it may happen that at some point in time either no or both plugins will attempt to be active. Some sort of synchronization primitive is required.

BUG-2572 is the long-term query solution, BUG-2573 will provide the low-level API which can be user to side-step the performance overhead and provide a stop-gap utility class.

Sorry, the last two references should read BUG-2672 and BUG-2673.

(In reply to Robert Varga from comment #3)
> So essentially this is a request for a filtering expression, where the data
> 'comes to existence' when the expression becomes true and disappears when it
> becomes false.
>
> Now if you have two independent plugins, this is problematic, as the
> notifications to the two of them will be inherently asynchronous so it may
> happen that at some point in time either no or both plugins will attempt to
> be active. Some sort of synchronization primitive is required.
>
> BUG-2572 is the long-term query solution, BUG-2573 will provide the
> low-level API which can be user to side-step the performance overhead and
> provide a stop-gap utility class.

I am not following this comment. This is a request for a per registration filter expression. So when a notification is being published the code that handles the publishing iterates over all registrations, but only sends the notifications to those registrars where the filter expression is true.

I don't see how this maps to data existing or not existing or why a synchronization primitive is required.

So I read your statement as:

I have two plugins, A and B. A subscribes to "tell me when attribute foo is to CIENA_5400". B subscribes to "tell me when attribute foo is CIENA_6500". Given these are two subscribers, data change notifications are delivered to both of them concurrently.

If the attribute changes from CIENA_5400 to CIENA_6500, it is conceivable that B sees the change first. What I am saying is that if both blindly assume they are in control of the device, they will stomp on each other.

(In reply to Robert Varga from comment #6)
> So I read your statement as:
>
> I have two plugins, A and B. A subscribes to "tell me when attribute foo is
> to CIENA_5400". B subscribes to "tell me when attribute foo is CIENA_6500".
> Given these are two subscribers, data change notifications are delivered to
> both of them concurrently.
>
> If the attribute changes from CIENA_5400 to CIENA_6500, it is conceivable
> that B sees the change first. What I am saying is that if both blindly
> assume they are in control of the device, they will stomp on each other.

1. foo is not set
2. foo is set to CIENA_5400
2.1. A receives a data change notification
2.2. B does not receive a data change notification
3. foo is set to CIENA_6500
3.1 A receives a data change notification (sees the value is no longer CIENA_5400)
3.2 B receives a data change notification (sees the new value is CIENA_6500)
4. foo is unset
4.1 A does not receive a data change notification
4.2 B receives a data change notification (sees the value is no longer CIENA_6500)

David:
3.1 A receives a data change notification (sees the value is no longer CIENA_5400)
3.2 B receives a data change notification (sees the new value is CIENA_6500)

That could happen also in different order

3.1 B receives a data change notification (sees the new value is CIENA_6500)
3.2 A receives a data change notification (sees the value is no longer CIENA_5400)

Which means B already assumes device is CIENA_6500 and A may at same time assume device is CIENA_5400.

MD-SAL does not have enough information to infer ordering of delivery events between listeners, but device driver framework does.

This could be easily achieved without over-complicated already complicated implementation of MD-SAL by having following:

• Device Discovery components
• populates topology with device type
• Device Driver Manager
• listener in topology on device type changes, notifies drivers via routed RPC on devices available, unavailable - this allows you to have well defined order between drivers.

• Device Drivers - implement actual device specific functionality, implements device driver RPCs.

Device Driver Manager is critical piece which manages these transations eg.

null -> CIENA_5400 = sends device-added RPC to CIENA_5400 driver
CIENA_5400 -> CIENA_6500 - sends device-removed RPC to CIENA_5400 driver, when response returned
sends device-added RPC to CIENA_6500 driver.

These RPCs does not need to contain all data discovered from device discovery - just enough information for device drivers to retrieve inforation from MD-SAL.

With described approach you still got:

• nice separation between discovery and device drivers
• ordering between device drivers,
• better defined contract of device drivers

• you do not require following properties from MD-SAL:
• ordering of delivery of same event between different listeners
• filtering on attribute value.

I agree that MD-SAL does not determine nor control the order of data change notifications. But I am not sure that matter. What I mean is that when B (in you example) receives the "its CIENA_6500" notification it does what it needs to do and when A receives the "its not CIENA_5400" it does what it needs to do. These two actions may be completely orthogonal. The data change notification and the data it contains is the only information either handler requires. The order may not matter, where the order does matter what you have described could be used, but it doesn't have to be used it not needed.

In either case the original request was to be able to filter data change notifications so that a notification is only sent to a given handler when a given attribute is changed and better yet when a given attribute changes to a specific value. The code that implements the handlers can then determine if ordering matter and if so how to handle that or if ordering doesn't matter just do let the callbacks be called.

As part of this filter it would be nice to be able to also filter on register when A matches either value B or value C.