The incomplete result of mapper GetSubTree/Paths

[Patrick Williams]

On Mon, May 23, 2022 at 09:26:43AM -0700, Ed Tanous wrote:
> On Fri, May 20, 2022 at 2:13 PM Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> > On Fri, May 20, 2022 at 11:14:15AM +0800, Lei Yu wrote:

> > The issue here is around causality.  There really isn't any way to
> > correctly kick this logic out to applications no matter how complex you
> > make the implementation.
> >
> > The original mapper implementation was causally ordered but this was
> > lost in the conversion to C/C++.  We should look at getting back to
> > having mapper give causal order guarantees.
> >
> 
> I'm not really following what causality has to do with it in Leis case.
> From my read, it looks like this is a case of "introspect takes some time
> to complete, and the results for one daemon aren't expected to be added
> atomically".  

This is exactly a causality problem.

The logging daemon is creating 1000 objects _before_ advertising the
service.  It then advertises the service, which everyone hears, and then
mapper starts introspection.  If I ask mapper how many objects logging
has it should tell me 0 or 1000.  There was never a state when logger
hosted 438 objects, so I better not get that as an answer.

It is even worse than this (and a stronger demonstration of causality).
Suppose we had (and I'm making this up because it is an easy
demonstration):

    - logger starts up and projects 1000 objects.
    - inventory recognizes logger came back and instantiates an
      association.
    - power handling hears the association signal and queries mapper to
      get information on the corresponding logger entries.

In this case the paths...
    Logger -> Mapper -> Power Handling
           |
           -> Inventory -> Mapper -> Power Handling

give results as if the inventory association happens first, which breaks
the causality relationships.

> This exact same race is present any time an object is added
> or removed from dbus, so you're right, there isn't really a way to avoid
> it, aside from writing implementations that don't fail if the object count
> on a connection doesn't match what the mapper gave you, which is something
> we "learned" in bmcweb a long time ago.

Adding and removing isn't a causality breakage, so it isn't a problem.
You can't expect objects to be steady state and that is fine, but the
paths through dbus should preserve causality relationships.

> One workaround here to cover the startup case would be to simply batch
> together all objects for a given daemon in the InProgressIntrospect object
> such that all of a daemons dbus paths are added to the global object
> atomically, so we'd avoid the race in the startup case, but it would still
> exist when new objects are created, so it doesn't completely solve the
> problem, just solves it for the case above.

I don't know how this solves causality, unless mapper gives
InProgressIntrospect for every request after the signal comes in, until
introspection is complete.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220523/dbe87748/attachment.sig>