Refactor phosphor-settingsd

Refactor phosphor-settingsd

[Deepak Kodihalli]

Hello All,

I'm working this sprint on refactoring the existing phosphor-settingsd 
application (https://github.com/openbmc/phosphor-settingsd). This 
application provides and implements interfaces to let the user configure 
system settings. One of the first goals is to write d-bus interfaces, in 
YAML, around various settings, and place them in the 
phosphor-dbus-interfaces repository.

With the existing settings application, there isn't a clear schema 
around each setting, they are all described by a single 
org.openbmc.settings.Host interface. We'd ideally want an interface 
clearly describing each setting. That also makes it possible to 
implement settings d-bus objects as needed by a system.

Looking for feedback on these points :

1) Where to place settings d-bus interfaces? For example let's say 
there's a "boot_media" setting which indicates the source of the host 
image (disk/network/etc). The interface could be either 
xyz/openbmc_project/Settings/Host/BootMedia.interface.yaml or 
xyz/openbmc_project/Control/Host/BootMedia.interface.yaml. Apart from 
organizational clarity, any other advantages of placing all Settings 
interfaces under a common 'Settings' namespace? Any disadvantages? Is it 
more intuitive to place the interfaces in an already existing namespace 
describing the object on which this setting applies? For instance, what 
would be the best place to house an interface describing a CPU setting? 
We already have an 'Inventory' namespace for items such as the CPU.

2) While 1) above is more of an organizational statement, the same 
problem applies to object paths of the d-bus objects implementing 
settings. An obvious advantage of having all settings d-bus objects 
under xyz/openbmc_project/settings/ would be that they are easy to find 
and enumerate. The disadvantage would be extra work to identify unique 
path names. The alternative would be to have the settings objects under 
the existing namespace of the object they are applied to, for example 
xyz/openbmc_project/inventory/system/motherboard/cpu0/some_cpu_setting. 
Any preferences here?

3) Creating system specific settings d-bus objects - this for example 
means certain settings d-bus objects nay not even be created for certain 
systems. I'm thinking this can be achieved via a policy file (in YAML), 
which states what settings interfaces to implement. If there's a 
possibility of different kind of objects implementing the same 
interface, or the same kind of objects implementing different 
interfaces, then the policy file will have to talk about objects as 
well. I guess point 2) has a bearing here.

Thanks,
Deepak

Re: Refactor phosphor-settingsd

[Deepak Kodihalli]

On 10/05/17 11:13 pm, Deepak Kodihalli wrote:
> Hello All,
>
> I'm working this sprint on refactoring the existing phosphor-settingsd
> application (https://github.com/openbmc/phosphor-settingsd). This
> application provides and implements interfaces to let the user configure
> system settings. One of the first goals is to write d-bus interfaces, in
> YAML, around various settings, and place them in the
> phosphor-dbus-interfaces repository.
>
> With the existing settings application, there isn't a clear schema
> around each setting, they are all described by a single
> org.openbmc.settings.Host interface. We'd ideally want an interface
> clearly describing each setting. That also makes it possible to
> implement settings d-bus objects as needed by a system.
>
> Looking for feedback on these points :
>
> 1) Where to place settings d-bus interfaces? For example let's say
> there's a "boot_media" setting which indicates the source of the host
> image (disk/network/etc). The interface could be either
> xyz/openbmc_project/Settings/Host/BootMedia.interface.yaml or
> xyz/openbmc_project/Control/Host/BootMedia.interface.yaml. Apart from
> organizational clarity, any other advantages of placing all Settings
> interfaces under a common 'Settings' namespace? Any disadvantages? Is it
> more intuitive to place the interfaces in an already existing namespace
> describing the object on which this setting applies? For instance, what
> would be the best place to house an interface describing a CPU setting?
> We already have an 'Inventory' namespace for items such as the CPU.
>
> 2) While 1) above is more of an organizational statement, the same
> problem applies to object paths of the d-bus objects implementing
> settings. An obvious advantage of having all settings d-bus objects
> under xyz/openbmc_project/settings/ would be that they are easy to find
> and enumerate. The disadvantage would be extra work to identify unique
> path names. The alternative would be to have the settings objects under
> the existing namespace of the object they are applied to, for example
> xyz/openbmc_project/inventory/system/motherboard/cpu0/some_cpu_setting.
> Any preferences here?
>
> 3) Creating system specific settings d-bus objects - this for example
> means certain settings d-bus objects nay not even be created for certain
> systems. I'm thinking this can be achieved via a policy file (in YAML),
> which states what settings interfaces to implement. If there's a
> possibility of different kind of objects implementing the same
> interface, or the same kind of objects implementing different
> interfaces, then the policy file will have to talk about objects as
> well. I guess point 2) has a bearing here.
>
> Thanks,
> Deepak


Based on the above I went ahead and put code for review. The d-bus 
interfaces are at https://gerrit.openbmc-project.xyz/#/c/4205/ and the 
settings manager application is at 
https://gerrit.openbmc-project.xyz/#/c/4244/. There's a README in this 
commit chain explaining some of the design.

I went the route of having a separate interface per setting, instead of 
a generic setting interface (having for example a single d-bus variant 
property) because with the latter there's no schema to define a setting. 
For instance, a setting could actually be more than one property, or be 
an enumeration.

Thanks,
Deepak