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

[Sunitha Harish]

On 19-10-2023 15:56, Sunitha Harish wrote:
>
> 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?
>
I see an old bmcweb commit - abandoned here Adding Support for License 
Service (I5c3625a9) · Gerrit Code Review (openbmc.org) 
<https://gerrit.openbmc.org/c/openbmc/bmcweb/+/54037> after some initial 
reviews from Ed. Seems like Intel/AMI had some features consuming the 
LicenseService?
>> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20231019/09869898/attachment.htm>