[SSSD] Design Discussion: D-Bus Signal: Notify Property Changed

Jakub Hrozek jhrozek at redhat.com
Tue Jun 23 08:25:43 UTC 2015


On Tue, Jun 09, 2015 at 02:17:31PM +0200, Pavel Březina wrote:
> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusSignalPropertyChanged

Sorry for the delay in review, the 1.13 Alpha release took precedence..

> 
> = D-Bus Signal: Notify Property Changed =
> 
> Related ticket(s):
>  * https://fedorahosted.org/sssd/ticket/2233
> 
> Related design page(s):
>  * https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
> 
> === Problem statement ===
> 
> This design document describes how to implement
> org.freedesktop.DBus.Properties.!PropertiesChanged signal for SSSD objects
> exported in the IFP responder.

General comment:
The problem statement should also describe why we want to implement a
feature. In this case it's because we want to enable applications to
subscribe to asynchronous notifications from domain users.

> 
> == D-Bus Interface ==
> 
> === org.freedesktop.DBus.Properties ===
> 
> ==== Signals ====
> 
> * !PropertiesChanged(s interface_name, {sv} changed_properties, as
> invalidated_properties)

It would be nice to format the interface in non-proportional font,
especially the {sv} annotation is hard to read.

>  * interface_name: name of the interface on which the properties are defined
>  * changed_properties: changed properties with new values
>  * invalidated_properties: changed properties but the new values are not
> send with them
>  * this signal is emitted for every property annotated with
> org.freedesktop.DBus.Property.!EmitsChangedSignal, this annotation may be
> also used for the whole interface meaning that every property within this
> interface emits the signal
> 
> === Overview of the solution ===
> 
> Changes in properties are detected in new LDB plugin inside a ''mod'' hook.
> The plugin writes list of changed properties in a TDB-based changelog which
> is periodically consumed by IFP responder. IFP then emits !PropertiesChanged
> signal per each modified object.

Hmm, are you sure that mod is sufficient? Especially since you say that
the annotation can be used for the whole interface, then it sounds like
we might need to catch also adds and dels?

> 
> === Implementation details ===
> 
> ==== TDB Format ====
> 
> * '''TDB Name''': ''ifp_changelog.tdb''
> * '''Key''': dn of modified object
> * '''Value''': chained list of modified properties in the form
> ''total_num\0prop1\0prop2\0...\0''

What about added and deleted properties, do we also treat them as
changed?

> 
> ==== IFP Side ====
> 
> 1. TDB database is created on IFP start and deleted on IFP termination.
>  * on IFP start:
>   * if TDB file does not exist it is created
>   * if TDB file exist (unexpected termination of IFP) it is flushed, we do
> not care about the data inside
>  * on correct IFP termination
>   * the TDB file is deleted
> 2. A periodic task ''IFP: notify properties changed'' is created, it is
> responsible for emitting the ''!PropertiesChanged'' signal
>  * Periodic task flow:
>   1. Lock TDB for read-only access

Umm, this sounds dangerous. Would the writers be blocked while the IFP
locks TDB for reading?

>   2. Traverse the TDB and remember dn and properties for all modified
> objects
>   3. Flush TDB
>   4. Release the lock
>   5. Create and emit D-Bus signal per each object that is exported on IFP
> bus and supports ''!PropertiesChanged'' signal

What would be the default period for this task?

> 
> ==== LDB Plugin Side ====
> 
> 1. If TDB file does not exist just quit

You mean gracefully terminate the plugin operation, right?

> 2. If modified object supports the signal store it in the TDB
> 
> === Configuration changes ===
> 
> In IFP section:
> * '''ifp_notification_interval''': period of ''IFP: notify properties
> changed'', disabled if 0, default 300 (5 minutes)

This sounds a bit too long, the changelog should be mostly empty and
checking it is a simple r/o operation, any reason why we shouldn't check
much more frequently?

> 
> === How To Test ===
> 
> 1. Hook onto ''!PropertiesChanged'' signal, e. g. with ''dbus-monitor'̈́'
> 2. Trigger change of user/group

It should be made clear that the change can be done using /any/ update,
ie even getent group updating a user counts. (This is mostly us bragging
about how awesome the feature is :-))

> 3. Signal should be recieved
> 
> === Questions ===
> 
> 1. Do we want to use ''changed_properties'' or ''invalidated_properties''

Hmm, both are part of the D-Bus interface itself, right? Do we have a
choice?



More information about the sssd-devel mailing list