mapper: should it add "default interfaces" and is it valid to implement no interfaces on an object?

[Lei Yu]

This email is to discuss and ask the following questions:
1. Should mapper add "default interfaces" for all the objects and their parents?
2. Is it valid for a D-Bus service to implement no interfaces on an object?

TL;DR

# Background
* We noticed error logs "Bad dbus request error: Invalid request
descriptor [generic:53]" in bmcweb
* In https://gerrit.openbmc.org/c/openbmc/bmcweb/+/74593, it tries to
fix the above issue by filtering the "default" interfaces
* In the gerrit review, it's asked if the "default interfaces" are
really needed?
* Then https://gerrit.openbmc.org/c/openbmc/phosphor-objmgr/+/74832 is
submitted trying to remove the "default interfaces" in mapper, and
results in some regression in bmcweb.
And it leads to this discussion email.

# Details
## mapper
In mapper's introspect, it adds the "default interfaces" to all the
parent objects that implements the "Association" interface, For
example:
   * xyz.openbmc_project.Software.BMC.Updater implements
`/xyz/openbmc_project/software/c172a378` object with Association
interface;
   * After introspect, mapper will add 3 default interfaces to the
object and its parent objects
```
# busctl -j call xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper
GetObject sas /xyz/openbmc_project/software/c172a378 0
{
        "type" : "a{sas}",
        "data" : [
                {
                        "xyz.openbmc_project.ObjectMapper" : [
                                "org.freedesktop.DBus.Introspectable",
                                "org.freedesktop.DBus.Peer",
                                "org.freedesktop.DBus.Properties"
                        ],
                        "xyz.openbmc_project.Software.BMC.Updater" : [
                                "org.freedesktop.DBus.Introspectable",
                                "org.freedesktop.DBus.Peer",
                                "org.freedesktop.DBus.Properties",
                                "xyz.openbmc_project.Association.Definitions",
                                ...
                        ]
                }
        ]
}
```

If we introduce the change in
https://gerrit.openbmc.org/c/openbmc/phosphor-objmgr/+/74832, the
above command will get this result:
```
# busctl -j call xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper
GetObject sas /xyz/openbmc_project/software/c172a378 0
{
        "type" : "a{sas}",
        "data" : [
                {
                        "xyz.openbmc_project.ObjectMapper" : [],
                        "xyz.openbmc_project.Software.BMC.Updater" : [
                                "org.freedesktop.DBus.Introspectable",
                                "org.freedesktop.DBus.Peer",
                                "org.freedesktop.DBus.Properties",
                                "xyz.openbmc_project.Association.Definitions",
                                ...
                        ]
                }
        ]
}
```

Note that it indicates that `xyz.openbmc_project.ObjectMapper` service
implements **NO** interface on the object.

## D-Bus calls on "default" interfaces
Additional tests shows some inconsistent behavior on calling the
"default" interfaces' methods.
1. It shall be OK to call `GetAll` method on all the interfaces, for example:
```
busctl call xyz.openbmc_project.Software.BMC.Updater
/xyz/openbmc_project/software/c172a378 org.freedesktop.DBus.Properties
GetAll s org.freedesktop.DBus.Properties
a{sv} 0
```
2. It fails to call `GetAll` method to the `mapper` service on the
same object, which "indicates" that the interface
`org.freedesktop.DBus.Properties` is not really implemented on the
object.
```
busctl call xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/software/c172a378 org.freedesktop.DBus.Properties
GetAll s org.freedesktop.DBus.Properties
Call failed: Unknown object '/xyz/openbmc_project/software/c172a378'.
```
3. However, `GetMachineId ` method works OK on both services, which
"indicates" that the interface `org.freedesktop.DBus.Peer` is
implemented by both services on the object.
```
# busctl call xyz.openbmc_project.Software.BMC.Updater
/xyz/openbmc_project/software/c172a378 org.freedesktop.DBus.Peer
GetMachineId
s "a9af6f883ddf45289683c9583541a5ba"
# busctl call xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/software/c172a378 org.freedesktop.DBus.Peer
GetMachineId
s "a9af6f883ddf45289683c9583541a5ba"
```

## Some conclusion
>From the above behavior, we could make some conclusions:
* It seems wrong for `mapper` to add the default interface
`org.freedesktop.DBus.Properties` for all the objects, because it can
not be called as above example 2.
* It is also wrong for `mapper` to not add default interfaces at all,
because at least `org.freedesktop.DBus.Peer` works OK as above example
3.

## Workaround
1. The bmcweb patch
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/74593 is the workaround
to skip calling the "default interfaces".
2. The proposed comment in the above review is
https://gerrit.openbmc.org/c/openbmc/phosphor-objmgr/+/74832, which
will break the existing code.

So I would prefer workaround 1.

# Discussions
So here are the questions:
1. How to explain the above behavior of "D-Bus calls on default
interfaces", especially for 2 & 3?
2. Should mapper add "default interfaces" for all the objects and
their parents? If yes, it adds extra interfaces that are not
implemented; If no, it misses some interfaces that an object really
implements.
3. Is it valid for a D-Bus service to implement no interfaces on an object?

-- 
BRs,
Lei YU