D-Bus interface to update multiple properties in one shot

[Deepak Kodihalli]

On 10/09/18 12:08 PM, Deepak Kodihalli wrote:
> 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
>>
> 

I've put this for review on Gerrit - 
https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/12861/.

Thanks,
Deepak