<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 19-10-2023 15:56, Sunitha Harish
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3fbaa94e-391d-4d3a-95fb-259503e94dd3@gmail.com">
<br>
On 18-10-2023 18:48, Brad Bishop wrote:
<br>
<blockquote type="cite">On Wed, Oct 18, 2023 at 12:51:47PM +0530,
Sunitha Harish wrote:
<br>
<blockquote type="cite">
<br>
On 13-10-2023 21:33, Brad Bishop wrote:
<br>
<blockquote type="cite">On Fri, Oct 13, 2023 at 05:04:23PM
+1030, Andrew Jeffery wrote:
<br>
<blockquote type="cite">However, there is an escape hatch
for project social issues. For
<br>
example interested parties might choose to collaborate on
the license
<br>
manager implementation outside of the OpenBMC org, and
package it
<br>
through Yocto or OpenEmbedded.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
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.
<br>
</blockquote>
<br>
The suggestion here is to:
<br>
<br>
1 - write your license server application
<br>
2 - throw it up on Github somewhere other than openbmc
<br>
3 - submit a recipe to meta-oe
<br>
<br>
</blockquote>
Thank you for clarifying.
<br>
<blockquote type="cite">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.
<br>
<br>
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. </blockquote>
<br>
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.
<br>
<br>
@Ed/@Gunnar, are you interested in supporting the LicenseService
schema at bmcweb?
<br>
<br>
</blockquote>
I see an old bmcweb commit - abandoned here <a
href="https://gerrit.openbmc.org/c/openbmc/bmcweb/+/54037">Adding
Support for License Service (I5c3625a9) · Gerrit Code Review
(openbmc.org)</a> after some initial reviews from Ed. Seems like
Intel/AMI had some features consuming the LicenseService?<br>
<blockquote type="cite"
cite="mid:3fbaa94e-391d-4d3a-95fb-259503e94dd3@gmail.com">
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
<br>
</blockquote>
</body>
</html>