D-Bus interface to update multiple properties in one shot

[Deepak Kodihalli]

On 07/09/18 8:14 PM, Tanous, Ed wrote:
>>
>> A proposal we discussed in a meet recently is to implement a new
>> xyz.openbmc_project.Object.Properties D-Bus interface with a method
>> called 'Update', which accepts a dictionary of property-value pairs.
> 
> I'm not really following what problem this is trying to solve.  Does the timer in networkd not work as designed?  Are we trying to remove it?  In which use cases are we seeing performance problems with multiple set calls?  Have we measured these performance impacts?

The problem I'm trying to solve is with D-Bus apps (currently 
implementing org.freedesktop.DBus.Properties) that want to take a 
specific action after all or a subset of a D-Bus properties that they 
expose have been set. The typical action in these cases is restarting a 
service (because say on each set, you update a config file). It's the 
restart that's causing performance problems - because there could be too 
many of them, if you were updating a lot of properties. I don't think 
the timer is intuitive to a user of the API, because in scenarios where 
only a subset of the properties are updated, the additional wait time to 
get served is unexpected to the user of the API.

> What worries me about the proposed interface is consistency.  Will we be adding the xyz.openbmc_project.Object.Properties interface as a specification to certain paths in phosphor? all paths? All object manager paths?

Specific (not object manager) paths. For eg I don't think we'd need to 
add this to objects implementing inventory interfaces (those are a bunch 
of properties as well). I view implementing this interface as an 
(optional) improvement over org.freedesktop.DBus.Properties, in some 
cases, but this is not a replacement for the 
org.freedesktop.DBus.Properties interface. So objects implementing this 
proposed interface must implement org.freedesktop.DBus.Properties as well.

> How will one know which paths require use of the org.freedesktop.DBus.Properties interface, and which can use the interface you've proposed?  Yes, we could do a mapper call to find out, but I'm going to negate any performance improvement we've gained.

This can be described in the documentation of the D-Bus API. For eg, how 
does one know they have to implement org.freedesktop.DBus.ObjectManager 
(this is not a mandatory interface to implement)? This is typically 
documented in the D-Bus API.

> When calling the update method, if one of the property update fails, what then?  Does the property update get partially applied, does it roll back to the old values?  I don't think there are any good catchall answers here.

Good point. I think the caller must be able to resort to using the 
org.freedesktop.DBus.Properties interface. The update method of the 
proposed interface can fail on the first set that fails, and return back 
the properties that were successfully updated.

Thanks,
Deepak

> This idea intrigues me, but I think in many of these cases, consistency is more important than performance.  If there's a way to keep consistency with the proposed interface _and_ get performance, then I think that this could be workable, I'm just not sure how to accomplish both.
> 
> -Ed
>