D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

On 18-10-2023 18:48, Brad Bishop wrote:
> On Wed, Oct 18, 2023 at 12:51:47PM +0530, Sunitha Harish wrote:
>>
>> On 13-10-2023 21:33, Brad Bishop wrote:
>>> On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>>>> However, there is an escape hatch for project social issues. For
>>>> example interested parties might choose to collaborate on the license
>>>> manager implementation outside of the OpenBMC org, and package it
>>>> through Yocto or OpenEmbedded.
>>>
>>> I've been thinking along similar lines lately and I like this idea.  
>>> For a license server and even in general I think less centralized 
>>> control and less tightly coupled software would be a good direction 
>>> to take.
>> I am not very clear about this. The control and processing of the 
>> license will not be in BMC scope. The host should manage it.
>
> The suggestion here is to:
>
> 1 - write your license server application
> 2 - throw it up on Github somewhere other than openbmc
> 3 - submit a recipe to meta-oe
>
Thank you for clarifying.
> It's possible the meta-oe maintainers could reject your recipe for the 
> same reasons as you've been rejected here (or any other variety of 
> reasons).  In that case you could just make a meta layer with a single 
> recipe and throw that up on github too.
>
> The downside to this approach is you shouldn't use projects like 
> phosphor-logging, sdbusplus, or phosphor-dbus-interfaces or any other 
> recipes that are provided by OpenBMC or in meta-phosphor. Certainly 
> not if you want to get a recipe into meta-oe. 

I think this would defeat the purpose of this proposal. We want to use 
the BMC as a pass through entity for the licenses. It should be handling 
the redfish commands (bmcweb) on LicenseService schema - which is 
tightly coupled with the dbus. And the communication to the host at our 
server is via PLDM/MCTP. So we can not exclude the openbmc components. 
More over this new meta-oe work will turn out to be costly.

@Ed/@Gunnar, are you interested in supporting the LicenseService schema 
at bmcweb?

> IMO this isn't necessarily a bad thing, though.  This is what I meant 
> by tightly coupled software - if you take this approach and avoid 
> OpenBMC specific frameworks...who knows - if you make a an really 
> awesome, useful piece of software - you might even get collaborators 
> from outside OpenBMC.

If the app which is planned now is processing/validating the licenses, 
then it would turn out to be an awesome piece of software. But that is 
not the intention. Lately, as per Andrew J and Manoj's review comments - 
the design is taking a direction where the objects will be hosted at 
PLDM itself and there is no need of a new application called LicenseManager.